If you add server-side conversion tracking to X Ads, I would not start by ripping out the browser pixel.

The X Pixel and Conversion API can work together. The pixel records the action in the browser. The Conversion API sends the action directly from your server or another system. Using both can give you more ways to send the information needed for measurement.

But there is a basic issue to solve: if the same form submission reaches X from both sources, it should still count as one conversion.

X handles that through a deduplication key called conversion_id. The setup is not complicated in theory. The harder part is making sure both systems agree on what the event means and which real action produced it.

Start with the business event

Before deciding how to send the data, define the action you are trying to measure.

For a lead-generation campaign, I would separate at least three stages:

  • Landing-page view: the page loaded after the ad click.
  • Lead: the form was submitted successfully and a lead record was created.
  • Qualified lead: the business later confirmed that the lead met its qualification criteria.

Those are different events. Reaching the thank-you page does not automatically tell you that the lead was qualified. A CRM status change does not need to replace the original form submission. It can become a later event with its own definition.

I would start with one high-value action that is easy to verify. Get that event working from end to end, then add more stages if they will change how you optimize or evaluate the campaign.

Use one event and one conversion ID

X’s current guidance says that if you want to deduplicate Pixel and Conversion API events, use the existing event created for the Pixel. Then send the same conversion_id with the browser event and the server request.

Think of the conversion ID as the receipt number for the real action.

For example, a successful form submission creates lead record lead_48291. The browser pixel sends a Lead event with conversion_id: lead_48291. The server sends the same Lead event with the same conversion ID. X can recognize that the two signals describe one event.

A timestamp alone is not a reliable substitute. Two people can submit a form at nearly the same time, and one person can trigger more than one request. Generate or retrieve a stable ID tied to the underlying transaction, lead, signup, or other business record.

X strongly recommends the deduplication parameter when both tracking methods are used. Its website conversion tracking guide lists conversion_id as the unique identifier for this purpose.

Keep the browser and server payloads aligned

The two systems do not need to be identical in every implementation detail, but they should agree on the essentials:

  • The X Pixel ID and conversion event
  • The event type
  • The conversion time
  • The shared conversion_id
  • The value and currency, when they are meaningful
  • The source URL or page context

I would document that mapping in plain language. If a developer calls the action form_completed, the tag manager calls it generate_lead, and the CRM calls it new_contact, write down exactly when they all represent the same business event.

That mapping also makes QA easier. When a number looks wrong, you can trace one test record across the browser, server log, CRM, and X Events Manager without guessing which event is which.

Preserve the X click ID when it is available

When someone clicks an X ad, the destination URL can include an X click ID in the twclid parameter.

X recommends parsing and storing that value when it is present, then passing it with the related conversion request. This helps connect the later action to the ad click.

A practical lead flow could look like this:

  1. A visitor lands on the site with twclid in the URL.
  2. The site stores that value in a first-party cookie, session, or hidden form field, based on the approved technical and privacy approach.
  3. The lead record retains the value when the form is submitted.
  4. The server includes it with the Conversion API event.

X’s web conversions documentation says each Conversion API event needs at least one supported identifier, such as twclid, a hashed email address, or a hashed phone number. If IP address or user agent is used, it must be paired with another identifier.

Email addresses and phone numbers must be normalized and hashed with SHA-256 before they are sent. Only collect and send data your business is permitted to use. Review X’s conversion tracking and custom audiences policy and your own consent, privacy, and retention requirements before implementation.

Do not treat every event as a primary outcome

Better event coverage does not automatically mean better optimization.

If page views, button clicks, form starts, form submissions, and qualified leads are all treated as equally important, the account can look busy without producing useful business results.

I would choose the event that gets closest to the actual campaign goal while still producing enough reliable activity to use. For a new account, that may be a completed lead form. For an established account with a dependable CRM process, a later qualified-lead event may be more useful.

The event definition should stay visible in reporting. “19 conversions” is incomplete. Did 19 people load a page, submit a form, reach the end of a flow, or become qualified leads? The label should answer that question.

Test the setup one record at a time

I would run a controlled test before relying on the numbers.

  • Create one test lead or transaction with a recognizable record ID.
  • Confirm that the browser pixel fired on the intended action.
  • Confirm that the server request returned a successful response.
  • Check that both payloads used the same event and conversion_id.
  • Use the Recent Activity Log in X Events Manager to inspect the event and parameters received.
  • Verify that the single business action did not become two reported conversions.

X’s pixel troubleshooting guide explains how to validate the base and event tags. The website conversion guide also points to Events Manager’s Recent Activity Log for checking recent event data and parameters.

Keep a basic server log for rejected or retried requests. If the API call fails and the integration retries, the same conversion ID should remain attached to that original event.

Compare X reporting with the source of truth

After the implementation is live, compare X with the system that owns the outcome.

For leads, that might be your CRM. For purchases, it might be the order database. The totals will not always match perfectly because attribution windows, processing, consent, and identity matching can differ. The goal is to understand the gap and catch obvious problems.

I would check:

  • Are events firing on the correct action?
  • Are Pixel and Conversion API events being deduplicated?
  • Are click IDs and other permitted identifiers arriving?
  • Are values and currencies accurate?
  • Are test, internal, duplicate, or spam records excluded where appropriate?
  • Do reported conversions become useful business outcomes?

Do this before changing bids or increasing budget. A campaign cannot optimize toward the right result if the event is not defined or counted correctly.

A practical starting setup

My starting plan would be:

  1. Choose one meaningful conversion event.
  2. Verify the X Pixel is firing correctly.
  3. Add the Conversion API to the same event.
  4. Generate one stable conversion ID per real business action.
  5. Pass that same ID through both event sources.
  6. Store and send twclid when it is available and permitted.
  7. Test one record from the website through X Events Manager and the source system.
  8. Compare reported conversions with lead quality, revenue, or the next useful business outcome.

The Conversion API is not valuable just because it is server-side. It is valuable when it sends a clearly defined event, improves the information available for measurement, and still lets you trust the total.

Send the event from the systems that make sense. Give both copies the same receipt number. Then make sure the conversion represents something the business actually cares about.

Sources

Platform documentation checked October 22, 2026. Confirm current requirements in X Events Manager and the X Ads API documentation before implementation.