Debug Twitter/X in Chrome DevTools

What Twitter/X traffic looks like

The X Pixel, still widely called the Twitter pixel and still served from Twitter-branded hosts, fires each event to two collection endpoints. One conversion produces two requests, which is the single most misread thing about it.

Endpoint pattern

The Universal Website Tag loads from static.ads-twitter.com; events are collected at analytics.twitter.com/i/adsct and at t.co/i/adsct. Both carry the same event, so a page view typically shows as a pair

Transport

GET requests with the event data in the query string, plus form-encoded or JSON bodies on some calls. Event Watcher's parser merges body parameters into the query parameters before decoding

Key parameters

txn_id is the pixel id · p_id the partner · event or ev the event name, defaulting to PageView when absent · the tw_* family carries the conversion payload (tw_sale_amount, tw_order_quantity, tw_order_id, tw_currency, tw_value, tw_num_items, tw_content_type, tw_content_id) · contents carries an ecommerce items array · tw_document_href the page URL

A purchase event, as Event Watcher decodes it:

event=Purchase  txn_id=o1abc  p_id=Twitter
tw_sale_amount=499  tw_currency=DKK  tw_order_id=ORD-10482
contents=[{"content_id":"SKU-77","content_name":"…","num_items":1}]

Debugging Twitter/X with Event Watcher

• One of the platforms with a dedicated parser, so events are decoded rather than shown raw.
• The Overview card names the event and surfaces the pixel id, partner, sale amount, and quantity without opening anything.
• A Custom Data section groups the conversion fields under Conversion Data with readable labels alongside the raw tw_* parameter names, so a mistyped parameter is visible rather than silently absent.
• The contents array is parsed into an E-Commerce items section when present.
• Parsed Data groups the rest into Identity (txn_id, p_id, tw_user), Page Context (tw_document_href, iframe status, redirect), and Request (conversion id, callback, tw_gclid).
• The parser reports which pattern matched, so you can tell an analytics.twitter.com hit from its t.co twin at a glance.

Twitter/X and consent

Event Watcher checks Twitter/X against the marketing consent category.

The pixel's default behaviour is to fire a PageView as soon as uwt.js initializes, and because that event goes to both collection hosts, an ungated pixel produces two pre-consent violations per page rather than one. When auditing, count events rather than requests. A pixel correctly held behind a marketing gate should show no adsct traffic on either host until consent is granted, and the reload after granting is where you confirm it.

Common debugging scenarios

• Every event appears twice. Expected. analytics.twitter.com and t.co both receive it. Check the pixel id on each before concluding there are two pixels.
• Conversions report a value of zero. Open the Conversion Data section and check tw_sale_amount and tw_currency are present and numeric. A missing parameter is the usual cause.
• An event does not appear in X Ads. Read the decoded event name. It has to match the event configured in the X Ads events manager exactly.
• Two pixels installed. Compare txn_id across events. Two ids means two tags, usually one hardcoded and one from a tag manager.
• The pixel fires before consent. Filter to Twitter/X with the consent filter on violations only, then use the pixel audit workflow to check it alongside the other ad platforms on the page.