X Ads Conversion API: GTM Setup and Deduplication Checks
The X Ads Conversion API sends website outcomes, such as purchases or inquiries, to X through a server. A successful request is only part of setup: you also need to avoid counting the same outcome twice when the browser's X Pixel sends it. X web conversions documentation
X's September 17, 2026 changelog announced an official Google Tag Manager server-side template. This updates the GTM integration option rather than introducing the Conversion API itself. X changelog
This guide provides a preparation worksheet and deduplication checks based on official documentation. It does not describe changes applied to a live advertising account.
A web container alone is insufficient
The template is named “X Ads Conversion API (Official).” It runs in a server container and uses a Pixel access token generated in Events Manager. X GTM guide
A server container needs a tagging server. Installing a web container does not provide that infrastructure. Google's server-side GTM overview
Assign an infrastructure owner, someone to review operating costs, and an error contact alongside the request to add a tag.
Define the outcome first
This worksheet describes a fictional inquiry website. It contains no performance measurements.
| Decision | Example | Owner to consult |
|---|---|---|
| When the outcome occurs | Successful form submission | Website developer |
| Actions excluded | Validation errors and button clicks alone | Advertising and website owners |
| Event to send | Completed inquiry | Advertising owner |
| How to distinguish occurrences | An identifier issued for each completion | Developer |
| When measurement is not permitted | Conditions matching the user's choices under your policy | Measurement owner |
| Test data | Clearly recognizable test inquiries | Support team |
A button click before submission can include failed attempts. Align the outcome definition before choosing a transmission method.
Keep Event ID and Conversion ID separate
For Pixel and API deduplication, use the same conversion event's Event ID and a shared conversion_id. Creating a separate event solely for the API undermines that matching design. Existing events and deduplication
| Identifier | Meaning | Fictional example of its use |
|---|---|---|
| Pixel ID | X event source | Select the intended account's source |
| Event ID | Conversion event created in Events Manager | Select the inquiry-completion event |
| Conversion ID | Identifier distinguishing individual occurrences | Inquiry A: lead-example-a; inquiry B: lead-example-b |
These values are illustrative. Both transmission routes should receive A's identifier for inquiry A. Inquiry B gets a different identifier. Generating identifiers independently for each route prevents them from identifying the same inquiry.
Also distinguish a person's identity from the occurrence's identity. One person may submit different inquiries; do not collapse them into a single outcome.
Prepare the implementation request
A Client receives requests reaching the server container and turns them into events. Verify reception first when using a GA4-based route. Google's event-routing guide
Add the official template from the server container's gallery, configure the Pixel ID, token, and event, and check both web and server previews. If GA4 traffic is rerouted through the server, preserve onward GA4 delivery with a tag there. X setup and testing guide
The following is an original handoff sequence:
- Document the actions currently counted by X Pixel and GA4.
- Select the intended outcome without mixing in other events or page views.
- Confirm how both routes share an occurrence identifier.
- Prepare test evidence and a way to restore the prior setup.
- Assign post-release checks and record the change.
Choose account-specific settings from the official instructions and your current architecture.
Test deduplication and surrounding behavior
Transmission records in multiple tools are not necessarily duplicates in the final advertising report. Separate evidence that both routes sent an outcome from evidence of how it was counted.
| Test | What to check | Where to investigate a mismatch |
|---|---|---|
| Submit test inquiry A successfully | Both routes receive the same A identifier | Completion condition and identifier handoff |
| Revisit A's completion page | No false new outcome is sent | Page-view-dependent triggers |
| Submit a different inquiry B | B is distinguishable from A | Accidentally fixed identifiers |
| Fail form validation | No completed inquiry is sent | Click versus successful submission |
| Choose not to permit measurement | Behavior matches your transmission policy | Web and server conditions |
| Inspect the relevant GA4 event | Existing analytics delivery continues | Onward GA4 configuration |
An API success response is not proof that an outcome was attributed to an ad and reported. Check sending, reception, deduplication, and reporting separately to locate the mismatch.
Use AI to organize outstanding checks
Once measurement is consistent, decide which advertising data to share with AI. See checks for connecting marketing data through MCP for that next step.
Do not provide credentials or customer data to the model. This original prompt works with an anonymized design.
Review this X advertising measurement design for unresolved checks.
Do not change settings or publish anything.
Outcome definition: [what counts as success]
Existing measurement: [X Pixel and GA4 overview]
New route: [server-to-X overview]
Shared identifiers: [explanation without personal information]
Test results: [anonymized worksheet]
For outcome definition, duplicates, retries, GA4 continuity, and user choices,
classify items as confirmed / unconfirmed / question for the owner.
Do not infer missing settings or results.
Begin by confirming the current outcome definition and occurrence identifier with your developer. Shoryaku AI's chat can draft text using business information and your request. Use it to organize the worksheet and implementation request, while the responsible person configures GTM.