Twitter Conversion Tracking: Pixel + Conversion API Setup

Why Your Twitter Conversion Tracking Is Probably Lying to You

Last month I audited an X Ads account for a B2B fintech running EUR 8,000 per month in promoted posts. Their Events Manager reported 14 conversions in May. Salesforce had 31 demo requests with twclid in the URL. That is a 55 percent gap -- more than half of conversions invisible to the platform's optimization algorithm.

The pixel was installed. It was firing. The Twitter Pixel Helper showed green checkmarks. But Safari's ITP was capping the first-party cookie at seven days, ad blockers were stripping the JavaScript before it could execute, and every conversion that happened more than a week after the click was lost.

This is not an edge case. If you rely on the pixel alone for conversion tracking on Twitter, you are almost certainly under-reporting. The fix is a dual setup: the X pixel for real-time browser-side signals plus the Conversion API for server-confirmed events that no browser restriction can block.

Here is exactly how to build that setup, step by step.

What You Need Before You Start

Before touching any code, get these pieces in place:

Requirement	Where to find it
X Ads account with billing enabled	ads.x.com
X Pixel ID	Events Manager > Add Event Source
Event IDs for each conversion action	Events Manager > Add Event
X Developer account with Ads API access	developer.x.com
OAuth credentials (Consumer Key, Consumer Secret, OAuth Token, OAuth Token Secret)	Developer Dashboard > Project App
Google Tag Manager container (optional but recommended)	tagmanager.google.com

The developer account is the piece most teams skip. You need it for the Conversion API. Apply using your company's official X handle -- credentials tied to a personal developer account cannot be transferred later, per X's own documentation.

Step 1: Install the X Pixel

The pixel has two parts: a base code that loads on every page and event codes that fire on specific actions.

Direct installation

Copy the base pixel snippet from Events Manager and paste it before the closing </head> tag on every page. This initializes the pixel and starts collecting page-view data.

Then create conversion events in Events Manager (Purchase, Lead, Sign Up, or a custom event) and grab each event's ID. Add the event code snippet to the pages or interactions where those conversions happen.

Twitter conversion tracking with Google Tag Manager

For most setups, I prefer GTM. It keeps the twitter conversion tracking code out of your codebase and lets marketing update events without a deploy cycle.

1. In your GTM web container, go to Templates > Search Gallery and find the Twitter Base Pixel template. (The older "Twitter Universal Website Tag" template is deprecated.)
2. Create a new tag using that template. Paste your Pixel ID. Set the trigger to All Pages.
3. For each conversion event, create a separate tag using the Twitter Event Pixel template. Enter the event ID from Events Manager. Attach a trigger that matches the interaction -- a form submission, a purchase confirmation page view, a custom dataLayer.push event.
4. Publish the container.

If you are working with a platform like Webflow or Squarespace, you will need GTM in place first. I have written separate guides for adding GTM to Webflow and GTM on Squarespace that cover the platform-specific quirks.

Verify the pixel

Install the Twitter Pixel Helper Chrome extension. Load your site, click the extension icon, and confirm you see "Twitter website tag fired successfully" for both the base code and your event tags. Allow up to 24 hours for data to appear in Events Manager, though it usually shows within minutes.

Step 2: Set Up the Conversion API

The pixel catches conversions that happen in the browser. The Conversion API catches everything else -- and there is a lot of "everything else."

Safari blocks all third-party cookies outright and caps first-party JavaScript cookies at seven days. Brave and Firefox strip tracking parameters. Ad blockers prevent the pixel script from loading entirely. According to Adjust's 2025 ATT report, only around 35 percent of iOS users opt in to app tracking globally. The browser-side signal is structurally incomplete.

The Conversion API bypasses all of that. It sends conversion data server-to-server, from your backend directly to X's endpoint. No JavaScript, no cookies, no browser in the loop.

How it works

Your server sends a POST request to the X Conversions API endpoint with:

• The event ID (same one you use for the pixel -- this matters for deduplication)
• A conversion_id -- a unique string you generate per event, used to deduplicate against the pixel fire
• At least one user identifier: the twclid (Twitter click ID) from the landing page URL, a SHA256-hashed email, or a SHA256-hashed phone number
• Conversion time, value, currency, and any item-level data

The more identifiers you send, the higher your match rate. Always capture and forward the twclid -- it gives X a deterministic match and is the strongest signal available.

Server-side GTM route (recommended)

If you already run a server-side GTM container, the cleanest path is the X Conversion API tag by Stape. Add the template from the Community Gallery in your server container, enter your OAuth credentials and Pixel ID, map the event parameters, and set a trigger for the relevant events forwarded from your web container.

This avoids writing custom API integration code and keeps the setup manageable for non-developers.

Direct API route

If you do not use server-side GTM, your engineering team sends the POST request from your backend after the conversion happens. The authentication uses OAuth 1.0a with your Consumer Key, Consumer Secret, OAuth Token, and OAuth Token Secret. The official API reference documents the full payload schema.

Either way, the critical step is capturing the twclid from the URL when the user lands and persisting it -- in your database, your CRM, or your session store -- so it is available when the conversion fires server-side, potentially days later.

Step 3: Deduplicate Pixel + API Events

Running both the pixel and the Conversion API means the same conversion can be reported twice. X handles this with the conversion_id parameter.

The rule is simple: generate a unique conversion_id for each conversion event. Pass that same ID to both the pixel (via the event tag) and the Conversion API payload. When X receives two events with the same conversion_id and the same event ID, it counts them once.

A few details to get right:

• Deduplication works within a 48-hour window for most event types. If the CAPI event arrives more than 48 hours after the pixel fire, X may count both.
• Page View events (including the auto-created Site Visit and Landing Page View) have a shorter 30-minute deduplication window.
• Use a stable identifier like a transaction ID or form-submission UUID. Do not use timestamps -- they will differ by milliseconds between the client and server fire.

If you have implemented Meta's Conversions API or LinkedIn's server-side tracking, this pattern will feel familiar. The deduplication logic is nearly identical across platforms.

Step 4: Configure Attribution Windows

X defaults to a 30-day post-engagement, 1-day post-view attribution window. That is aggressive compared to most B2B sales cycles.

You can customize both windows:

Window type	Options
Post-engagement (click)	1, 2, 3, 5, 7, 14, or 30 days
Post-view (impression)	Off, 1, 2, 3, 5, 7, 14, or 30 days

For B2B, I typically recommend a 14-day post-click window and turning post-view off entirely. Post-view attribution on X inflates numbers without much signal -- an impression in a fast-moving timeline is not the same as an impression in a LinkedIn feed. For ecommerce with shorter consideration cycles, the 30/1 default is reasonable.

Changing the window retroactively recalculates historical data, so test the setting before making budget decisions off the new numbers.

Common Failures I See in Audits

After auditing dozens of X Ads accounts, the same twitter ads conversion tracking mistakes come up repeatedly.

Pixel installed, CAPI not. The pixel alone misses a growing share of conversions. This is the single most common gap. If your reported ROAS on X feels low and you only have the pixel, the data is the problem, not the channel.

twclid not persisted. The click ID lives in the URL query string on the landing page. If your site strips query parameters on redirect, or your SPA router drops them on navigation, the twclid is gone. Your Conversion API calls then fall back to hashed email only, cutting match rates.

Deduplication skipped. I see setups where both pixel and CAPI fire without a shared conversion_id. Every conversion gets double-counted. The dashboard looks great, the CFO approves a budget increase, and then reality catches up.

Wrong event type. X has predefined event types (Purchase, Lead, Add to Cart, etc.) and custom events. Using a Purchase event for a lead-gen form, or tracking everything as a custom event, confuses the optimization algorithm. Match the event type to the actual conversion.

No data layer. Without a proper data layer, GTM tags fire on unreliable triggers. A page-URL trigger that matches /thank-you will break the moment someone changes the confirmation page path. Push structured events to the data layer and trigger off those.

If any of this sounds like your setup, I can audit it and tell you exactly what needs fixing.

Pixel vs Conversion API: What Each Covers

Capability	X Pixel	Conversion API
Fires in browser	Yes	No
Works with ad blockers active	No	Yes
Works after ITP cookie expiry	No	Yes
Supports retargeting audiences	Yes	No
Server-to-server (no JS needed)	No	Yes
Requires developer resources	No	Yes
Deduplication support	Via conversion_id	Via conversion_id

The answer is always both. The pixel gives you retargeting audiences and real-time event signals. The Conversion API fills in the conversions the pixel misses. Together, they give X's algorithm a more complete picture of who converts -- which means better optimization and lower cost per acquisition.

This is the same pattern I walk through in my guide on Conversions API vs Meta Pixel. The principle is platform-agnostic: browser tracking degrades, server-side tracking compensates, and deduplication keeps the numbers honest.

FAQ

Not sure your X conversion tracking is actually working? Let me audit it -- I will tell you exactly where the gaps are and how to close them.