ChatGPT Ads conversion tracking: OpenAI pixel, Conversions API and consent

What changed for advertisers in 2026

OpenAI opened conversion measurement in May 2026, with two building blocks released together: a measurement pixel running in the browser, and a Conversions API receiving events from your server. June 2026 brought conversion-optimised campaigns (oCPC, described as an open beta in the documentation): you still pay per click, but delivery is steered towards people likely to complete the chosen conversion event.

On 18 August 2026, OpenAI announced that ChatGPT ads would expand to 31 European countries, France included. Delivery started on 24 August, first through partners (OpenAI’s sales team, agencies, technology partners), followed by self-serve access in Ads Manager. Ads are only shown to users on the Free and Go plans; Plus, Pro and Enterprise subscribers do not see them.

The practical consequence for a PrestaShop or WooCommerce shop: an oCPC campaign requires conversion tracking already in place and one active conversion event, chosen at creation and not editable afterwards. Without reliable measurement, you buy clicks without knowing which ones sell, and the algorithm has nothing to learn from.

The OpenAI measurement pixel: what it does in the browser

The pixel is a JavaScript SDK, oaiq.min.js, initialised with your Pixel ID. It sends events through oaiq("measure", name, data, options). When a visitor arrives from an ad, the landing page URL carries an oppref parameter: the pixel reads it and stores it in a first-party __oppref cookie, valid for 30 days from the last write. It also sets an __obref cookie, a random browser identifier kept for 365 days.

The documentation also covers advanced matching: email, phone, customer ID, first and last name can be sent as SHA-256 hashes after precise normalisation (lower-case email without spaces, phone reduced to digits, and so on). An automatic mode detects this information on the page without raw data ever reaching OpenAI.

Finally, there is a JavaScript-free image tag, useful as a noscript fallback or for a page-load conversion. It is limited: one event per request, no user object, and it does not capture oppref by itself. For a shop, it is a complement, never the main setup.

The Conversions API: the same sale, sent from the server

The Conversions API accepts POST requests on the /v1/events?pid=<PIXEL-ID> endpoint of OpenAI’s collection domain, authenticated with a separate API key, also obtained from the conversions tab in Ads Manager. One request can batch up to 1,000 events; if a single event is invalid, the whole batch is rejected. Each event carries an id, a type (order_created, items_added…), a timestamp_ms that must reflect when the conversion actually happened and be no more than seven days old, the source URL and, inside a data object, the order amount, currency and contents.

Two details matter a lot. The amount is an integer in the currency’s minor unit: €59.90 is sent as 5990. And the validate_only field lets you test a call without saving anything: this is validation mode, to be used before going live.

Why double up on the pixel? Because some browser events never arrive: blockers, private browsing, a confirmation page closed too early, a payment completed at the provider without returning to the shop. The server, on the other hand, knows an order was confirmed. OpenAI explicitly recommends using both together.

Deduplication: one sale, not two

When the same order is sent from both the browser and the server, OpenAI treats it as a single event if three things match: the same Pixel ID, the same event name and the same identifier, called event_id in the pixel options and id in the Conversions API. The first one received wins; later ones are ignored.

The difficulty is practical: the identifier must be known on both sides. I generate it when the order is created, store it with the order, and inject it into the confirmation page for the pixel as well as into the server call. I avoid using the plain order number: an opaque identifier is enough and exposes nothing.

Consent and GDPR: what to settle before the first sale

The OpenAI pixel sets advertising cookies and sends browsing data to a third party: in France and the rest of the EU, that requires the visitor’s prior consent, just like the Meta pixel or Google Ads. One point specific to this pixel: according to the documentation, its consent defaults to true until you set it to false. So you must either call oaiq("consent", false) before initialisation, or only load the script after acceptance. I do both: the script is not loaded before consent, and the state is set to false as a safeguard.

With tarteaucitron.js, the pixel is declared as a custom service that only runs once accepted. With Axeptio, Cookiebot, Didomi, CookieYes or Complianz, loading is tied to the marketing purpose or to a vendor declared in the tool. When the banner publishes Google Consent Mode signals, the ad storage state can be used as the trigger.

The same rule applies on the server: I store the consent state with the order, and the Conversions API sends nothing for a visitor who refused. Emails and phone numbers never leave in clear text, only as SHA-256 hashes. The documentation also provides an opt_out field per event, and states that OpenAI does not currently use pixel data for individual personalisation. Finally, the processing must appear in your privacy policy and records: choosing the legal basis is up to you or your DPO; I provide the exact technical description of what is sent.

What about a tag manager?

Going through Google Tag Manager in the browser or a server-side container is possible, and sometimes the right choice when a shop already centralises all its measurement there. But on PrestaShop and WooCommerce, the reliable information, the confirmed order with its amount and consent state, lives in the shop itself. Sending the server conversion from the order confirmation hook removes a layer, and therefore a source of mismatch. I decide based on what is already in place: the goal is a single source of truth, not a pile of tools.

For principles shared by every ad platform, the pages on the ecommerce events that matter and on the Meta pixel and Conversions API explain the same pixel-plus-server logic. The official sources used here are the measurement pixel documentation, the Conversions API documentation, the list of supported events and the image tag documentation.