Advanced measurement in ChatGPT Ads: sending the conversion from your server without losing the trail

The ChatGPT Ads pixel is the short route to measurement, and on many websites it's enough. But it goes blind in a very common case: a conversion that doesn't finish on the page where it's installed.

It happened to us: our sign-up is completed in the client dashboard, not on the website, so we send it from the server. This is what we learnt, traps included — without going into how it is coded, which is a job for whoever handles your development. No pixel yet? Start with "Measuring from day one", in the Intermediate module.

When the pixel isn't enough

Then it is time to send the conversion from your server. OpenAI publishes a route for exactly that, set up by whoever handles your development (it is in the sources at the foot). You want it when:

• The conversion finishes on another domain with no pixel: a payment gateway, a booking system, a client dashboard.
• The conversion happens on the server: a sign-up confirmed later, a lead your CRM marks as good.
• You want more reliability: OpenAI describes server-side sending as more reliable than the pixel on its own, which depends on the browser, the ad blocker of the day and consent.

The usual approach is to combine both and deduplicate.

The thread you can't lose: the oppref

Whoever clicks your ad arrives with a click identifier in the URL: the oppref. The pixel captures it and stores it in a first-party cookie, __oppref. On the server nobody does that for you: collect it and send it with the event exactly as it came.

The challenge is carrying it through to the conversion, perhaps on another domain and days later: a hidden form field, a parameter in the link or your database will do. We store it on the website on arrival and retrieve it on the server.

Deduplication: one conversion, one count

If the same conversion arrives through the pixel and from your server, OpenAI counts it once when the pixel, the event name and the event identifier all match.

⚠️ Pitfall: that identifier is named differently on each side, so it is easy to send two different values and count the sale twice. Decide it yourself, once — the order number, for example — and insist the same one is used on the website and on the server.

The data type of each event

Each standard event has to come with specific data and, if it doesn't match, the whole send is rejected: it isn't just that conversion that fails, it is every one travelling with it. It happened to us for copying an official purchase example to send a sign-up. These are the events the platform accepts today:

Two more rules, so you can brief the work properly: amount and currency always travel together (one without the other is no good), and the custom event carries a name you choose that cannot clash with any standard one.

💡 Ninja trick: ask for the first test to be sent with OpenAI's dry-run check, the one that validates the send without recording anything. Errors then show up before they pollute your history.

The hashed email: better attribution, still personal data

You can add the customer's email hashed with SHA-256 to improve attribution. Normalise it first (no stray spaces, all lowercase): "Ana@Example.com" and "ana@example.com" produce different hashes.

⚠️ Pitfall: hashing isn't anonymising. A hashed email is still personal data: we declared it in our privacy policy before sending it. This isn't legal advice; check it with whoever handles your data protection.

The pixel's automatic advanced matching does something similar on its own: it detects customer information on your website (such as form entries) and hashes it with SHA-256 in the browser. The documentation doesn't explain how to switch it off, so mention it in your privacy policy too.

Attribution: which window counts

• Click-through: set in each event's configuration; the official examples use 30 days.
• View-through: a fixed 1-day window, for reporting only. Optimisation and billing run on clicks.

Line up the windows before comparing with Google Ads or your analytics.

Conversion campaigns: a single standard event

You need exactly one active standard event as the goal; custom events can't be used for optimisation. And it needs volume: if you sell little, optimising towards leads or sign-ups may suit you better. The objective and the event can't be changed later: you'd have to create another campaign. And since bidding by value doesn't exist, choosing THAT event well is the only way to ask the bidding for quality.

Consent, on the server too

The pixel starts measuring unless told otherwise: in Europe it has to be left switched off before it is initialised and turned on only when the person accepts advertising (anything blocked isn't resent afterwards). On the server the filter is yours: apply your cookie banner's criteria before forwarding the oppref or the email, and stop if someone withdraws consent. We checked it in September 2026: server-side sending carries no consent field at all, so nobody will filter for you.

Two keys that get mixed up

Ads Manager has two different keys, and we mixed them up:

• The conversions key, in Conversions (behind the key icon): for sending events from your server.
• The account management key, in Ads Manager settings: it is for something else and no good here.

Both live on your server, never in your website's code: anyone holding one can spend your money or fake your data.

What to remember

• No pixel where the conversion finishes? Send it from the server with the oppref exactly as it came.
• Deduplicate with the same pixel, the same event and an identifier you decide.
• Each event requires the data that goes with it; if it doesn't match, the whole send fails, not just that conversion.
• The hashed email improves attribution, but it's still personal data.
• View-through (1 day) is for reporting only; optimisation and billing run on clicks.
• Conversion campaigns: a single standard event, with volume and no going back.