X Pixel Setup: Base Code, GTM, Shopify and Events

Which conversions to count in the first place, why X credits conversions after a like as well as a click, and how the Pixel fits together with the Conversions API and your CRM, is in the X Ads conversion tracking guide. This one is the installation.

Everything starts in X Ads Manager. Open Tools, then Events Manager, and select Add event source. The event source ID X shows you is your Pixel ID, and it is the ID in every snippet below. If you cannot see a Tools tab at all, X says the usual reason is that the ad account has no credit card on file yet, so add a payment method first. You also need the right to edit your site's head, your GTM container or your shop's apps.

Then pick one install method per page. The Pixel Helper warns when a pixel fires more than once, and the usual way to get there is two methods at once: the base code in the theme plus a GTM tag, or X's Shopify app on a store that already had the code pasted in.

The manual install gives you the most control and needs somebody who can edit the site's template. X says the base code "should be implemented across all pages", pasted before the closing </head> tag, and that event code "requires the base code". On a CMS or shop system, that means the header template, so every page carries it, including the ad's landing page.

<!-- X Pixel base code -->
<script>
!function(e,t,n,s,u,a){e.twq||(s=e.twq=function(){
s.exe?s.exe.apply(s,arguments):s.queue.push(arguments);
},s.version='1.1',s.queue=[],u=t.createElement(n),u.async=!0,
u.src='https://static.ads-twitter.com/uwt.js',
a=t.getElementsByTagName(n)[0],a.parentNode.insertBefore(u,a))
}(window,document,'script');
twq('config','<PIXEL_ID>');
</script>
<!-- End X Pixel base code -->

Copy your own code from Events Manager rather than retyping this one: your ID is filled in. The part you work with is the last line. twq('config') starts the Pixel with your ID, and every conversion you add later is a twq('event') call after it. If one page has to report to several pixels, say two ad accounts, X's answer is one twq('config') line per Pixel ID under the same loader, not a second copy of the whole snippet.

As soon as the base code runs, X creates two events for you: Site Visit and Landing Page View. You do not write code for either. They are what Events Manager shows first when the install worked.

Each conversion is an event you create in Events Manager first, and then fire from the page. When you create one, X asks for its type, and today's list has six.

Events Manager then gives each event its ID, and the event code fires it by that ID. The ID takes the form tw- plus your Pixel ID plus the event's own ID:

// After the base code, on the page or state that confirms the lead.
// conversion_id is the key X deduplicates on when the
// Conversions API sends the same event.
twq('event', 'tw-<PIXEL_ID>-<EVENT_ID>', {
  value: <LEAD_VALUE>,
  currency: '<CURRENCY>',
  conversion_id: '<LEAD_ID>',
  email_address: '<EMAIL>'
});

Two rules from X keep the events meaningful. "In almost all cases, a particular conversion type ... should only be used once on your website": decide whether the Lead is the demo request or the newsletter, not both. And if an older account still runs legacy event types, X says they can still be optimised on, and advises re-creating them with the new types if reporting shows no metrics for them. A campaign on the Sales objective needs at least one conversion event before you can build it, so fire the event for real first.

Parameters are the object after the event ID. X notes they only work for events defined with code; an event set up with a URL rule in Events Manager carries none. These are the ones X documents:

On twclid X is specific: "The X Pixel already automatically passes twclid from URL or first-party cookie. This parameter can be optionally used to force attribution to a certain ad click." You do not need it in a normal install.

User parameters: email and phone

Two user parameters improve matching: email_address and phone_number, the phone in the format +11234567890. You pass them in plain text, and X says the Pixel hashes them itself with SHA-256, so no unhashed data is shared with X. Pass them where you know them, typically on the event that fires after a form. A Restricted Data Use parameter also exists for visitors whose data must be limited; X sets it up only through a support ticket.

X does not ask you to build GTM tags by hand. Events Manager connects to your Google account and sets the container up for you, client side for the Pixel, server side for the Conversions API, or both. Pick this route or the base code, not both, or every event fires twice.

1. In Events Manager, open Install Pixel, then Partner Integrations, and choose Google Tag Manager.
2. Sign in to Google with OAuth and allow X access to your Tag Manager account.
3. Choose client side (the Pixel), server side (the Conversions API) or both, and select the container.
4. For events past the page view, switch on "Track Google Tag Manager dataLayer Standard Events", and make sure your site pushes those events, with triggers set up with gtag.js.
5. Open GTM's preview, trigger each conversion and watch it in the X Pixel Helper before you publish the container.

The server side half runs on X's official template, "X Ads Conversion API (Official)" in the Community Template Gallery, which works in server containers only. It maps GA4 events onto X events (an event without an Event ID set becomes gtm_ plus the event name), hashes a plain email after trimming and lowercasing it, and hashes the phone without reformatting it, so send the phone in E.164 already. It authenticates with a Conversion API access token you generate in Events Manager (Install Pixel, Manual, Conversion API, Generate access token), and X says no OAuth 1.0a or Ads API application is needed on this route. With its first-party cookie setting on, which is the default, the server tag also keeps the twclid in a cookie of its own for about 390 days. The full server setup belongs to the X Conversions API guide.

X's app for Shopify

X publishes a free app called X in the Shopify App Store, supported by X, which promises to "Track performance with a 1-click X Pixel installation." It has been listed since May 2022 and was rated 3.7 from 82 reviews when we read it on 7 October 2026. Install it, connect your X Ads account, and the Pixel goes onto the store without code. Remove any X base code pasted into the theme first, or the store carries the Pixel twice.

Know the limit before you rely on it: the listing does not say whether the app also sends server-side events, and we found no X page that does. If you need the Conversions API on Shopify, plan another route for it, such as a server GTM container or a partner. The order side of store tracking is in Shopify conversion tracking.

Ensighten, Tealium and the partners

On Ensighten, use the "Twitter Pixel" app; X marks the older "Conversion Tracking (UWT)" app as deprecated. On Tealium iQ, use the "Twitter Pixel" tag. For the server side, X lists Conversions API partners: Adobe, Tealium, MetaRouter, Datahash and RudderStack. For WordPress, WooCommerce or another shop system X documents no integration of its own: use the base code in the theme's header, or GTM.

The Pixel's matching rests on what it can keep in the browser, and X's documentation says a little about how.

• The click IDA click from an X ad appends twclid to the landing page URL. The Pixel reads it from the URL or from a first-party cookie. X does not document that cookie's name for the browser Pixel.
• First-party cookiesX documents a cookie called _twpid that is usually set by the X Pixel. The server-side GTM tag can write its own _twclid cookie for about 390 days.
• No iframesX says not to put the Pixel inside an iframe or inside other tags: it may then fire from another domain and lose the first-party cookies it depends on.
• ConsentX tells advertisers to get consent under the ePrivacy Directive before setting non-essential cookies, and to filter out events of users who opted out. Restricted Data Use goes through a support ticket.

Two consequences for the setup. Keep redirects out of the ad's URL: X says they strip the twclid off the URL before the Pixel ever sees it. And remember the Pixel is a browser tag that reports only what the browser lets it see, which is why the server side exists. How consent tools interact with lead tracking is covered in Consent Mode v2 for lead generation.

The X Pixel Helper

The X Pixel Helper is a free Chrome extension; in the Chrome Web Store it is still listed under its old name, Twitter Pixel Helper. Open any page with the Pixel and the extension's badge counts the pixels that successfully sent data. Open it to inspect each event and its parameter values, and read its warnings, such as a pixel firing more than once on the same page. Pin it and walk the funnel: the landing page, a form, a test purchase.

Event statuses and the Recent Activity Log

The Recent Activity Log under each event shows sample hits with their parameters and the host name they came from, which is how you catch a Lead arriving without its value, or a staging domain firing into the live Pixel. Give the reports time after that: X finalises them within 24 to 48 hours, in a batch process that removes duplicate tag fires and adjusts attributions, so a count can move after you first see it. Last, click your own ad and check that the landing page opens with twclid in the URL.

A Pixel on its own is a browser measurement: ad blockers and privacy settings take a share of its events, and it never sees what happens after the website, such as a qualified lead or a won deal in your CRM. X documents the Conversions API for exactly that, conversions that start online and finish offline, sent from a server with the twclid, the hashed email and phone, the IP address and the user agent as identifiers.

Three things carry over from the Pixel setup. Give every event both sources send the same event and the same conversion_id, so X counts it once. Keep the twclid from the landing page, because the Pixel passes it on its own and your server does not, and X recommends always including it. And keep one meaning per event, so a Lead from the browser and a Lead from the CRM are never two different things. The server setup (token, payload, identifiers, errors) is in the X Conversions API guide, and how it all fits with the CRM is in the X Ads conversion tracking guide.

LeadJourney does not replace the X Pixel, and you do not need to remove it. It is one script on your site or in your GTM container, live in about 21 minutes without a developer, running server-side and first-party on your own domain at 95%+ tracking accuracy. On the first visit it issues the LeadJourney Click ID, our own visitor identifier kept in local storage and a first-party cookie for months, and stores every session under it, with the ad platforms' click IDs (gclid, gbraid and wbraid, fbclid, msclkid, li_fat_id, rdt_cid and X's twclid) as properties of the session. The twclid is captured server-side on every X click, which is exactly the identifier a Conversions API setup has to keep for itself.

The X Ads integration connects your X Ads account by signing in, imports campaigns, ad groups, ads and daily spend, and follows each lead through your CRM, or each order through Shopify or Stripe. The CRM stages you map, for example a qualified lead and a won deal with its value, go back through X's Conversions API as the stage changes, with the value, the currency, the twclid, hashed email and phone, and a conversion_id that deduplicates against the Pixel you keep running. The Pixel keeps doing the browser half; the server half comes from the system that knows how the lead ended.

In LeadJourney's own reports the X click sits in the full journey next to every other channel, with no attribution window, under first click, last click, linear, position based, time decay and other models. It does not do view-through or engagement attribution, so the conversions X credits to a like or a view stay an X number. Processing runs in Frankfurt under a GDPR data processing agreement.

Read verified reviews on Trustpilot, G2 and leadjourney.io/testimonials.

• X Ads conversion tracking: what to count, the engagement windows, CRM events and which number to trust.
• The X Conversions API: the server side, from the token to deduplication and CRM events.
• X Ads UTM parameters: tagging the ads so GA4 and your CRM see the campaign.
• X lead generation ads: native lead forms, which the Pixel never sees.
• For stores: Shopify conversion tracking.
• On the product side: the X Ads integration, server-side tracking, UTM and click ID tracking and the Shopify integration.
• In the glossary: conversion tracking, click ID and first-party data.