Fix guide · Any website · advanced · about 60 min

OpenAI Conversions API deduplication: match the pixel event_id

For the findings “OpenAI server events have no event ID” and “OpenAI server events carry a different event ID”.

What this means

Your site sends its OpenAI events twice, on purpose: once from the browser through the OpenAI Pixel, and once more to your own server, which forwards them to OpenAI through the Conversions API. OpenAI suggests using both, to combine browser activity with conversions your backend confirms, as long as both copies can be recognized as one.

The server copy we saw does not carry the browser event’s ID:

  • No event ID: the request to your server has the event name but no ID at all.
  • A different event ID: the request carries an ID, but not the one the browser event had.

OpenAI treats two events as the same conversion only when the Pixel ID, the event name and the event ID all match: event_id in the pixel, id in the Conversions API. Without that, each conversion may be counted twice.

We report this as possible: we can see the request from the browser to your server, but never the request from your server to OpenAI, so check the server side yourself.

Why it costs you money:

  • Purchases and leads count twice in ChatGPT Ads, so reported results and return on ad spend look better than they are.
  • Conversion-optimized campaigns learn from inflated numbers and optimize toward the wrong results.
  • When someone later “fixes” the double counting by switching one side off, you lose the reason you added the server copy.

How to confirm it yourself

  1. Open your page in a private (incognito) window, open developer tools (F12) and go to the Network tab. Accept cookies and trigger the conversion (for example, submit a test lead).
  2. Filter by bzr.openai.com, open the pixel request and note the event’s type and id in the payload.
  3. Clear the filter and find the request your site sends to its own server at the same moment: a form submission, an /api/... call, or a request to your server-side tag manager address. Open its payload.
  4. Compare: does it contain the same ID as the pixel event? If there is no ID, or a different one, the two copies cannot be matched.
  5. Check your server code (or your server-side tag) for what it sends to bzr.openai.com/v1/events as each event’s id.

A frequent surprise: the browser id is a random UUID that nobody chose. That means your code calls oaiq("measure", ...) without an event_id, and the pixel filled in a value of its own (current SDK behaviour; OpenAI’s docs only describe the event_id you set). The server cannot know it, so the copies will never match until the browser sends an ID of yours (see “OpenAI events have no event ID”).

How to fix

The rule: one action, one ID, created in one place and used by both copies.

  1. Pick where the ID is created.

    • For purchases, the order number is ideal: the confirmation page can use it in the browser, and your backend already has it.
    • For leads, page views and clicks, create a random ID in the browser when the action happens (for example crypto.randomUUID()), or create it on your server when it renders the page or processes the form, and hand it to the browser.

  2. Pass it to the pixel in the fourth argument:

    const eventId = crypto.randomUUID();
oaiq("measure", "lead_created", { type: "customer_action" }, { event_id: eventId });

  3. Send the same value to your server with the request it already receives: a hidden form field, a property in your /api/... call, or an event parameter in your server-side tag manager feed.

  4. Use it as id in the Conversions API event, with the same event type and the same Pixel ID (pid) as the browser event:

    {
  "events": [{
    "id": "4b1f0c6e-2f7d-4f6b-9a51-2d3c8e7f9a10",
    "type": "lead_created",
    "timestamp_ms": 1792771200000,
    "action_source": "web",
    "source_url": "https://example.com/contact",
    "data": { "type": "customer_action" }
  }]
}

    For custom events, both copies also need the same custom_event_name.

  5. Do not create a second ID on the server. A server that makes its own random ID, prefixes it (srv-…), or uses a different value (for example the database row ID while the browser used the order number) produces a mismatch even though both copies “have an ID”.

  6. With server-side Google Tag Manager: generate the ID once with a variable such as Stape’s Unique Event ID, put it into the web tag’s server-side tracking settings, and map the same value to Event ID in the server tag (Stape’s OpenAI Ads Events API tag). Check both containers in Preview mode: the web tag and the server tag must show the same value for the same event.

  7. Forward the click and browser references too. While you are in the server code: OpenAI asks you to pass the ad click ID as oppref and the __obref cookie value as user.obref, unchanged, when available and allowed by the visitor’s consent. They improve attribution but do not replace the event ID.

  8. Publish and run a test conversion.

Common causes

  • The browser calls measure without event_id, so the pixel uses a random ID the server never sees.
  • The server-side code was added later and never received the ID from the browser.
  • Browser and server each generate their own random ID.
  • The server sends a different identifier (database ID, a prefixed value, the order number while the browser used a random value).
  • The server event uses another event name (for example purchase or a custom name) than the browser’s order_created.
  • In server-side GTM, the web tag and the server tag read different variables.

How to verify the fix

  1. For one test conversion, the pixel event’s id, the ID in the request to your server and the id your server sends to OpenAI are identical, and so are the event names.
  2. With access to the Advertiser API, OpenAI’s recent-events endpoint (GET /v1/conversions/events?pid=<PIXEL-ID>) shows a sample of the last roughly 15 minutes, with pixel_sdk for browser events and server_to_server for server events.
  3. Re-run the check on IsPixelWorking. The finding should be gone.

Sources

More OpenAI guides