Twitter/X Duplicate Event Names
Two or more X Pixel event tags on this account share the same name. Each tag is a separate event in Events Manager with its own event tag ID, but they all report against the same label. Volume splits across them, optimisation cannot tell which one to learn from, and the reporting view aggregates two distinct configurations into one row.
Why It Matters
Event names in X Ads Events Manager are display labels. The actual routing key is the `tw-XXXXX-XXXXX` event tag ID, and X is happy to issue multiple IDs that share a label. That makes accidental duplication easy: someone creates a new Purchase event for a redesigned checkout, the old Purchase event stays active, and traffic now splits between two tags that both call themselves Purchase. The consequence is that Events Manager and the campaign reporting view aggregate by name, which hides the split. The two tags each look healthy on their own, but neither carries the full conversion volume. Optimisation runs against one tag and ignores the other, so the bidder learns from half the signal. If the two tags have slightly different parameter shapes (one passes `value`, the other does not), reported revenue lurches based on which tag the request happened to hit. The second variant is two different teams instrumenting the same action: the agency wires a Purchase tag through GTM, the engineering team wires another through the server. Both fire on the same checkout. Both call themselves Purchase. Volume doubles in the merged view.
How To Fix It
- List every active event in Ads Events Manager and group by event name.
- For each duplicated name, decide which event tag ID is the canonical one and which should be retired. Prefer the tag with cleaner parameters and the integration you trust.
- Remove the duplicate tag from the source where it is wired (GTM, hardcoded snippet, server template). Do not just pause the event in Events Manager; the tag will keep firing and producing zero-volume noise.
- Update any campaign that optimises against the retired tag to point at the canonical one.
- Verify in Events Manager that volume on the canonical tag now reflects the full real conversion count and the retired tag drops to zero.
Example
Active events:
Purchase (tw-o1234-abcde): 412 events
Purchase (tw-o5678-fghij): 388 events
Real order count in commerce platform: 800
Reporting view: 800 Purchases (correct in aggregate, wrong for optimisation)Your X Pixel account has multiple active event tags sharing the same event name. Per X Ads Help Center documentation on the website tag and conversion tracking for websites, each event in Events Manager is uniquely identified by its `tw-XXXXX-XXXXX` event tag ID, while the event name is only a display label, which allows distinct tags to share a label and split traffic between them. The reporting view aggregates by name, so the split hides until you inspect Events Manager directly, and optimisation can only learn from one tag at a time, which means the bidder is trained on roughly half the conversion signal. If parameter shapes differ between the duplicates, reported value also lurches between them. Fix: pick a canonical event tag per business action, remove the duplicate tag at its source rather than only pausing it in Events Manager, point every campaign at the canonical tag, and confirm full conversion volume now lands against one event. Source: business.twitter.com/en/help/campaign-measurement-and-analytics/conversion-tracking-for-websites.html.
Drop this paragraph into your client deliverable. Sources back to the canonical platform documentation linked below.
References
Audit your own files for this check
AdLint runs this check (and 177 others) against your GTM, Google Ads, Meta, TikTok, LinkedIn, Pinterest, Twitter/X, and Snapchat exports. Everything stays in your browser. No uploads, no accounts.
Run a free audit