What this is, and what it is not
OpenAI runs an advertising product called ChatGPT Ads, and like every advertising platform, it needs to know whether the traffic it sent converted. That measurement layer is a browser pixel plus a server-side conversions API - the same architecture Meta, Google, and TikTok settled on years ago, applied to a much newer platform.
This is not the same thing as ChatGPT's Instant Checkout, the in-chat "buy it in ChatGPT" flow built on the Agentic Commerce Protocol (ACP) that OpenAI and Stripe co-developed. Instant Checkout is a session-less agent-driven purchase - there is frequently no browser session for a traditional pixel to fire from at all, which is a distinct measurement problem covered on our conversion pixels landscape page. Conflating the two is the single most common mistake we see in early write-ups of this space.
The two requests, from the wire
This is a FACT record: captured first-party from a HAR (HTTP Archive) capture of a live checkout, Webclat audit, 2026-09-02. Specific values - the live pixel ID, cookie contents, payload bodies - are deliberately omitted below; the mechanism is what matters and it holds regardless of whose site you observe it on.
1. The config fetch (fires on page load)
-> 200 OK, application/json - the pixel's own configuration
2. The event beacon (fires on tracked actions, e.g. checkout)
-> 202 Accepted, text/plain body (opaque/encoded, not form params)
Query parameters observed: pid (the pixel ID), st, sv, t, ec. Their exact meanings were not confirmed from the wire capture alone - see the hypothesis note below.
The host split is the tell. A CDN-style config host (bzrcdn.openai.com) separate from the event-collection host (bzr.openai.com) is the same pattern Meta uses (connect.facebook.net for the SDK, graph.facebook.com/.../events for collection). If you know how to read that split on one vendor's pixel, you already know how to read OpenAI's.
Corroborating this against OpenAI's own documentation
OpenAI's public developer documentation (developers.openai.com/ads), reviewed 2026-09, describes a Measurement Pixel and a server-side Conversions API for ChatGPT Ads, consistent with what the HAR capture shows: a Conversions API endpoint at bzr.openai.com/v1/events authenticated with a bearer token, a pixel ID issued in the format oai-px-XXXXXXXXXX from the OpenAI Ads Manager's Events Manager, and a first-party attribution cookie (__oppref) the JavaScript pixel sets from a landing-page query parameter. The documentation names eleven standard events across four data shapes (contents, customer_action, plan_enrollment, custom). This is sourced from OpenAI's public docs, not re-verified by us on the wire beyond the two requests above - stated as sourced, not as our own first-party fact.
Hypothesis: what st, sv, t, and ec likely mean
Not confirmed from the wire capture, and not found stated plainly in the public documentation we reviewed. Our working inference, to be treated as a hypothesis until an engineer confirms it against a live OpenAI Ads Manager account: sv probably identifies the SDK version, t the event type, ec an event count or sequence number within the session, and st a session or site-type flag. Do not build a reporting layer on this guess without confirming it first.
Installing it
- Shopify merchants: the platform's built-in custom-pixel system can load the OpenAI pixel without an app or theme edit - the lowest-friction path, and the one to prefer for a first install.
- Tag-manager route: a server or web GTM container tag (community and vendor-built tags exist for this) keeps the pixel inside the same governance as every other tag on the container - our default recommendation once a site already runs GTM.
- Manual snippet: loading the SDK directly is the fallback for platforms with neither - highest control, highest responsibility to consent-gate it yourself.
- Server-side (Conversions API): point of the exercise is that the browser pixel alone under-reports - ad blockers and cookie restrictions clip it the same way they clip every other browser-based pixel. Pair it with the Conversions API call from your own server for the events that matter (purchase, above all).
See installing AI pixels for the consent-gating and staging steps we apply regardless of which install path a given site uses.
How to verify it worked
This is the step vendor docs skip and the step that actually catches a broken install. Open your browser's network panel (DevTools → Network), filter for bzr.openai.com, and reload the page you expect the pixel on.
| What you see | What it means |
|---|---|
| Config GET on load, 200 status | Pixel is present and loaded correctly |
| Events POST on a tracked action, 202 status | The event was accepted - not necessarily attributed, just accepted |
| No config GET at all | Pixel is not installed, or is being blocked (consent tool, ad blocker, CSP) |
| Events POST with no prior config GET | Misconfiguration - the SDK is firing without having loaded its config first |
| Config GET present, no events POST on a real conversion | The event trigger is wired wrong - the pixel loaded but nothing tells it a conversion happened |
A 202 response is not proof of attribution - it only means OpenAI's collector accepted the beacon. Full verification, including confirming the event shows up correctly inside the OpenAI Ads Manager, is the second half of the check and belongs in the verification guide, which applies the same runtime-check discipline across every platform in this cluster, not just OpenAI's.
We are not an SEO or AI-optimization agency, and this page is not selling you traffic to ChatGPT. It documents a measurement mechanism and how we install and verify it - the same install-review-verify discipline we apply to any vendor tag, extended to a platform new enough that most teams have not built the habit for it yet.