The OpenAI conversion pixel, documented from the wire

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 three requests, from the wire

This is a FACT record: captured first-party from HAR (HTTP Archive) files taken across four cold browser sessions on a live production ecommerce site (three homepage, one product page), Webclat engineering audit 2026-08-25 09:53-09:55 UTC, and re-verified against the same evidence 2026-08-26. 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 SDK load (fires on page load)

2. The config fetch (the SDK's own first call)

3. The event beacon (fires on tracked actions)

Query parameters observed: pid (the pixel ID), st, sv, t, ec. The observed values narrow most of them down - see the parameters section below.

One detail worth carrying into your own audits: on the site we captured, the pixel was installed as a merchant-defined Shopify custom web pixel and every OpenAI request initiated from that sandbox frame, not from theme code, GTM, or an app embed. The page HTML contained no reference to the SDK at all. If you are looking for the tag in the source and not finding it, that is why.

Corroborating this against OpenAI's own documentation

OpenAI's public developer documentation (developers.openai.com/ads), read 2026-09-02, describes a Measurement Pixel and a server-side Conversions API for ChatGPT Ads, consistent with what the HAR capture shows. Sourced from those docs on that date: the Conversions API posts to https://bzr.openai.com/v1/events?pid=<PIXEL-ID> authenticated with an Authorization: Bearer API key; the pixel stores the oppref click identifier taken from the landing-page URL in a first-party __oppref cookie so later page views can reuse it; and the taxonomy lists thirteen standard conversion events (page_viewed, items_added, checkout_started, order_created, lead_created, registration_completed, subscription_created, trial_started, contents_viewed, appointment_scheduled, app_installed, app_opened, custom) across four data shapes (contents, customer_action, plan_enrollment, custom). Stated as sourced from the vendor's docs, not as our own first-party measurement.

One correction worth making explicitly, because early write-ups of this pixel repeat it: the documentation does not state a pixel-ID format. It says only to create a Pixel ID in the conversions tab of Ads Manager, and the IDs we saw on the wire were opaque 22-character tokens with no vendor prefix. Do not pattern-match an ID to decide whether an install is real - look for the requests.

What st, sv, t, and ec are

The observed values do most of the work here. Across the captured sessions: st=oaiq-web, sv=0.1.31, ec=3 on a homepage load and 4 on a product page, and t a millisecond epoch value that decodes to the exact second of each capture. On that evidence sv is the SDK version, t a per-request timestamp, and ec the count of events in the batched payload - which matches the three events the captured homepage body actually carried. That st tags the SDK surface rather than something session-specific is our inference, labeled a hypothesis: it held one constant value in every session we saw, and OpenAI's public docs do not define these parameters at all. Confirm against your own account before a report depends on any of them.

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 openai.com - not bzr.openai.com on its own, which misses the bzrcdn config host - and reload the page you expect the pixel on.

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.