To make ChatGPT Ads conversion events consistent, document what happened, which system confirms it, how value is defined and which identifier represents that occurrence. Coordinate browser and server producers before testing duplicates, retries and repeat actions. GPTAd recommends an event contract and repeatable test matrix so reporting begins with trustworthy business definitions.
Reviewed October 15, 2026. This is an independent GPTAd implementation playbook. All examples are hypothetical; no customer records or platform performance claims are used.
An event contract prevents these differences from becoming invisible reporting errors. It describes the business action first and the transport second.
Write the event contract
Create one row per meaningful action, with these fields:
- Business definition: the exact condition that has become true.
- Platform event: the documented event type that fits that condition.
- Source of truth: the system authorized to establish completion.
- Identifier: how this occurrence is distinguished from another.
- Value policy: what is included, excluded, and denominated.
- Transport: browser, server, or an intentional combination.
- Owner: who approves changes and investigates failures.
The supported-events reference distinguishes a page load from a specific content interaction and provides different payload shapes for different event families. Select the schema after defining the action; do not force every funnel step into a purchase-shaped object.
For a hypothetical software company, “form accepted” and “sales-qualified inquiry” should remain distinct internal milestones. Marketing may need both, but redefining the first to mean the second halfway through a test destroys comparability.
Define money before encoding it
OpenAI's event documentation uses currency minor units. Item amount is the per-unit amount, quantity is separate, and event amount represents the whole event. This differs from bidding micros. Verify the current amount fields for the selected event shape.
Hypothetical arithmetic: two items at USD 24.50 each produce a merchandise subtotal of USD 49.00. With a two-decimal minor unit, the per-item value is 2450, quantity is 2, and the subtotal is 4900. These numbers illustrate representation, not a platform price or suggested transaction value.
Whether shipping, tax, discounts, or later refunds belong in your business value definition requires a separate decision. Document it; do not let the frontend and backend make independent assumptions. Check the currency's actual minor-unit convention instead of universally multiplying by 100.
Add two defensive tests: a missing currency must fail your internal validation, and an implausibly large amount must trigger investigation. Silent “helpful” conversions can disguise upstream mistakes.
Treat the occurrence ID as shared infrastructure
As checked October 15, CAPI deduplication requires matching Pixel ID, event name, and event ID across browser and server; custom event names must match too. The first matching event wins.
Generate the occurrence identifier once in the application flow and carry it to the intended producers. A fresh random ID created separately by each producer cannot establish that two records represent the same occurrence. Conversely, reusing one ID for every purchase cannot distinguish separate outcomes.
Because arrival order should not determine business value, prepare compatible payloads before either route sends. Do not design the later route as a correction mechanism for the earlier one.
Run a repeatable test matrix
Use an isolated environment or documented validation facilities where appropriate. Never submit fictitious production sales. Record fixture ID, expected behavior, observed requests, redacted fields, and the person who checked the result.
- Single route: trigger one approved fixture and confirm one intended dispatch.
- Two routes: trace the same occurrence from application creation to both outbound records; compare every shared identity field.
- Browser refresh: reopen the completion screen and inspect whether your application creates a new occurrence accidentally.
- Network retry: simulate an interrupted delivery and verify that retry logic preserves the occurrence identity.
- Genuine repeat action: create a second valid occurrence and confirm it receives a different identity.
- Arrival reversal: delay each route in turn and compare business fields before evaluating downstream behavior.
- Invalid payload: remove a required field and verify that your alert includes enough context to repair the producer without exposing personal data.
- Currency regression: repeat the monetary test after changing discounts or checkout software.
CAPI offers validation without saving; its documentation also warns that one invalid event can fail a batch. Include batch-failure isolation in the backend release checklist rather than assuming all neighboring events succeeded.
Close the loop on routing
The multiple-pixels guide supports broadcast and single-pixel routing. If your site uses multiple data sources, test the destination explicitly; do not introduce additional pixels simply to troubleshoot uncertainty.
Your final artifact should let a new engineer answer three questions without guessing: What happened? Which occurrence was it? Where was the approved record supposed to go? That is a stronger foundation than a dashboard total that merely looks plausible.
