Twitter/X conversion_id Required
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.
Why It Matters
Every X Pixel conversion call (Purchase, Lead, SignUp, Subscribe, CheckoutInitiated, AddToCart, AddToWishlist) accepts a `conversion_id` parameter. X uses it as the deduplication key. The contract is simple: if two events arrive on the same configured event tag with the same `conversion_id`, X keeps one. If `conversion_id` is missing, X has nothing to compare against and treats every hit as a fresh conversion. For browser-only setups this still bites. A user reloads the confirmation page and your Purchase fires twice. A SPA route change triggers the tag a second time. Your reported Purchase count drifts above truth and the value attached drifts with it. For accounts that also run a server-side Conversions API integration, the impact is larger: every successful merge depends on `conversion_id` being present on both legs. Without it, the browser Purchase and the server Purchase both land in Events Manager as separate records. The symptom you see in Ads Events Manager is a Purchase count that runs ahead of the order count in your commerce platform, often by a clean 1.5x to 2x multiple. The cause is almost always a tag that was wired up before `conversion_id` got added to the spec.
How To Fix It
- Pick a stable per-event identifier you already have on the page: order ID for Purchase, lead ID for Lead, subscription ID for Subscribe.
- Update every active conversion tag so the parameters object includes `conversion_id`, for example `twq('event', 'tw-XXXXX-XXXXX', { conversion_id: orderId, value: 129.00, currency: 'USD' })`.
- Confirm GTM variables, hardcoded snippets, and any server-side tag template all read from the same source.
- Fire a test conversion and inspect the outgoing request payload in the Network tab to confirm `conversion_id` is populated.
- After 30 to 60 minutes, check Ads Events Manager and verify the event count tracks your real order count rather than running ahead of it.
Example
Broken:
twq('event', 'tw-o1234-abcde', { value: 129.00, currency: 'USD' })
Fixed:
twq('event', 'tw-o1234-abcde', { conversion_id: '10492', value: 129.00, currency: 'USD' })Your active X Pixel conversion events are firing without `conversion_id` in the parameters payload. Per X Ads Help Center documentation on conversion tracking for websites and the web event tags reference, `conversion_id` is the key X uses to deduplicate matching events across browser reloads, SPA re-fires, and any parallel Conversions API path. When the field is absent, X treats every hit as a distinct conversion, which inflates Purchase or Lead counts and pushes reported value above the real order book. The drift typically appears as a clean multiple over the commerce-platform truth, and it feeds directly into bidding once optimisation runs against the same event. Fix: pass a stable per-event identifier such as order ID as `conversion_id` on every X Pixel conversion call, mirror the same value on any server-side path for the same event, and verify in Ads Events Manager that the deduped count tracks your real order count. 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