What is twclid?

The only identifier X takes raw and alone

X's Conversion API requires at least one identifier on every conversion event — but the accepted identifiers are not interchangeable, and the differences decide how you build:

So twclid is the only one that needs neither hashing nor a second identifier alongside it. Email and phone can stand alone but only after you've hashed them correctly; IP and user agent are never sufficient by themselves no matter how many of them you send.

X's own guidance follows directly from that: "It's recommended to always include Click ID in the conversion request." If you're going to get one thing right on this platform, it's capturing twclid.

conversion_id is a deduplication key, not a conversion ID

This one catches people because the field name actively misleads. conversion_id is not your internal identifier for the conversion — your order number, your transaction reference. It is the deduplication key.

X's instruction is to use the same deduplication key in both the Pixel code snippet and the Conversion API request, passed as conversion_id, so the two paths for the same event collapse into one conversion instead of two.

The failure mode is quiet and expensive: populate conversion_id with an order number server-side while the Pixel sends something else — or nothing — and the values never match. Both events are accepted, neither errors, and every conversion is counted twice. Your reported ROAS doubles and your bidding optimises against fiction.

Rule: generate one value per event, and make sure the browser and the server both send that same value. Same principle as Meta's event_id, covered in Conversion API vs Pixel.

The window X doesn't publish

Every other major platform names a number. Google states it retains gclid for 90 days; Microsoft caps msclkid offline imports at 90; Meta recommends a 90-day _fbc expiry.

X's public web-conversions API documentation states no equivalent limit — no retention period for twclid, no maximum age for conversion_time.

You will see "30-day click-through, 1-day view-through" quoted confidently in third-party guides and connector docs. Those figures do not appear in X's own API reference, so treat them as reported defaults rather than documented guarantees, and check the attribution settings on your actual ad account. This is the same trap as the widely-repeated "ttclid lasts 7 days" claim that TikTok's documentation never makes.

Practical takeaway: in the absence of a published number, store twclid for at least as long as your longest plausible conversion path, and don't design a workflow that depends on an undocumented window holding.

Capturing twclid

1. On landing. Parse twclid from the query string as soon as the visitor arrives and store it first-party. X's phrasing is to parse it out "when it is available" — it won't be there on organic or direct visits, so handle its absence rather than assuming it.
2. Alongside the record. X suggests storing the value with the relevant form fields or conversion event information, which is what makes batching and bulk uploads possible later.
3. At conversion. Send twclid raw in the Conversion API payload, together with a conversion_id that matches what the Pixel sends for the same event.

Common twclid failure modes

• Mismatched conversion_id. Silent double-counting. The single most damaging mistake here.
• Hashing it. twclid goes raw. Hashing it makes it unmatchable, and nothing will tell you.
• Leaning on IP plus user agent. Neither can stand alone; sending only those two is a weak, fingerprint-style match and X's rules require pairing for a reason.
• Assuming a 30-day window. Undocumented. Don't build a workflow that depends on it.
• A redirect stripping it. The universal click-ID failure — capture before any hop.
• Brave. Strips twclid by default for every user — see the Click ID Survival Matrix.

For the wider landscape, see the click ID explainer; for the full build, the tracking-setup playbook.