Twitter / X Pixel audit

One or more active X Pixel conversion events on this site are firing without a `conversion_id` value in the parameters object. The event still reaches X, but X has no key to use when it later tries to merge that hit with a matching server-side event or a duplicate browser hit. The first time the page reloads, or the first time your Conversions API integration sends the same Purchase, you start double-counting.

The active events on this X Pixel are all Tweet engagement style metrics (Tweet engagements, Retweets, Likes, Replies) rather than website conversion events. Engagement metrics measure activity on X itself. They do not measure what people do on the site after the click. With no website conversion event configured, campaigns cannot optimise toward Purchase, Lead, SignUp, or any business outcome.

One or more X Pixel events on this site are firing with an event ID that does not match the `tw-XXXXX-XXXXX` shape X expects. The pixel still loads. The request still goes out. But the event ID is the routing key X uses to decide which configured conversion the hit belongs to. A malformed ID routes nowhere, so the Purchase you can see in the network tab never lands against the Purchase event you set up in Events Manager.

This X Pixel has no active website conversion events. The pixel itself may load fine, but Events Manager has nothing configured that maps to a business outcome (Purchase, Lead, SignUp, Subscribe, CheckoutInitiated, AddToCart, AddToWishlist, ContentView, Search). Campaigns running against this account have no conversion signal to optimise toward and no way to report ROAS or cost per acquisition.

Your X Pixel Purchase or CheckoutInitiated events are firing with no `value` parameter (or a value of zero) while the event count is non-zero. The conversions land in Events Manager, but X has no revenue to attach to them, so the ROAS column reads zero and value-based bidding has nothing to optimise toward.

One or more X Pixel events on this account are reporting on a conversion window that does not line up with the window set at the campaign level, or the window is shorter than the sales cycle you actually run. The result is reporting that cuts off valid conversions, which then feeds back into optimisation and makes campaigns look worse than they are.

Your X Pixel events either ship without a `conversion_id`, or they ship with `conversion_id` values that repeat across distinct orders. Either pattern breaks the dedupe contract. Missing IDs let the same Purchase get counted twice when the browser tag and the Conversions API both fire. Repeated IDs collapse two different orders into one event. Both directions break your reported Purchase count and the value attached to it.

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.

One or more X Pixel event tags on this account are marked active in Events Manager but have recorded zero events over the reporting window. Either the tag is wired but the trigger never fires on the site, the tag is being blocked, the tag is firing with a malformed event ID, or the underlying user activity does not actually exist. None of these are good states for a tag that campaigns may be optimising against.

Two or more X Pixel events on this account have names that look like minor variations of each other (Purchase and Purchases, SignUp and Sign Up, Lead and Leads). Each is a distinct event in Events Manager with its own `tw-XXXXX-XXXXX` ID, but they likely describe the same business action and split volume between them. Reporting and optimisation both suffer when the same conversion is reported under two near-identical labels.