Valentius Kryptix

Last updated and last verified against OpenAI’s current advertising and developer documentation: September 2026. This guide generalizes what we learned implementing conversion tracking for a real first ChatGPT Ads campaign, combined with OpenAI’s current documentation. It’s an independent guide, not published or endorsed by OpenAI. Ads Manager and its measurement APIs are still in beta — exact field names, event names, and endpoint shapes can change, so treat OpenAI’s current developer documentation as the final word over anything written here.

Clicks and impressions tell you your ad got attention. They don’t tell you whether anyone actually became a customer, a lead, or a signup. That gap is what conversion tracking closes, and it’s also the part of ChatGPT Ads that most existing guides stop short of — they’ll walk you through creating a campaign and leave measurement as an afterthought. This guide is aimed at the part that comes after that: wiring up the Pixel, the Conversions API, and getting the conversion event to fire at the right moment, including on the messier real-world cases — multi-step forms and single-page applications — where it’s easy to get subtly wrong in a way that quietly corrupts your data for weeks before anyone notices.

What Is ChatGPT Ads Conversion Tracking?

ChatGPT Ads conversion tracking is the system OpenAI provides for measuring what happens after an ad click, beyond the click itself — using a browser-side Pixel, a server-side Conversions API, or both, tied together by a click reference called oppref that lets a later action be attributed back to the specific ad that produced it.

What Counts as a Conversion

A conversion is a specific, defined action that represents real business value — a completed signup, a submitted lead, a finished purchase — not a page view, and not a click, both of which Ads Manager already reports on their own. The distinction matters because it’s tempting to treat an earlier, easier-to-detect action as a stand-in for the real outcome, and that substitution is where most conversion-tracking setups quietly go wrong, covered in detail further down.

Why Clicks Alone Aren’t Enough

CPC and CTR describe traffic quality — whether people are clicking, and roughly what that’s costing you. Neither tells you what happened after the click. Picture two campaigns that look identical on click data alone: both get 1,000 clicks, but one produces 100 completed signups and the other produces 20. A dashboard that only shows clicks and CPC would rate them the same. A conversion report makes the actual difference impossible to miss. Conversion tracking is what turns “people are clicking” into “people are converting,” which is the only version of that sentence a business actually cares about.

How ChatGPT Ads Attribution Works

The sequence, at a conceptual level: someone clicks your ad, OpenAI appends a click reference to your landing-page URL, your site captures that reference, time passes while the person does whatever they’re going to do on your site, and — if they complete the action you’ve defined as a conversion — an event fires that OpenAI matches back to the original click. OpenAI’s documentation describes this matching as happening within an attribution window; check current documentation for the exact window length, since that’s precisely the kind of parameter a beta product can adjust.

It’s worth separating this into distinct stages rather than treating “did conversion tracking work” as one question, because each stage can succeed or fail independently. Did your code actually send the event (tracking)? Does that event match the conversion you configured for the campaign (matching)? Can OpenAI connect it to an eligible ad click within the attribution window (attribution)? And has enough time passed for it to show up (reporting)? A setup can be genuinely sending events correctly while still showing fewer attributed conversions than you’d expect, simply because the matching or attribution stage didn’t connect them — which is a different problem than “the code is broken,” and worth diagnosing as such rather than assuming the whole pipeline needs rebuilding.

What Is oppref?

oppref is OpenAI’s click reference — a unique identifier ChatGPT appends to your landing-page URL when someone clicks your ad. OpenAI’s conversion measurement documentation states that the Pixel captures this reference from the landing-page URL and stores it in a first-party cookie, so a conversion recorded later — in the same session or on a later visit — can still be attributed back to that original click.

For example, if your ad’s destination is yoursite.com/course-signup/, a click might land the visitor on yoursite.com/course-signup/?oppref=ABC123. Everything downstream — the Pixel’s cookie, and any server-side event you send later — depends on that reference surviving long enough to be used.

The OpenAI Pixel vs. the Conversions API

Two mechanisms exist for sending a conversion event back to OpenAI, and OpenAI’s documentation recommends using both together where practical, for more resilient measurement than either alone provides.

What the Pixel Does (Browser-Side)

The Pixel is a JavaScript SDK added to your site. It captures oppref from the URL, stores it in a first-party cookie, and fires conversion events directly from the browser when you tell it to. It’s the simpler of the two to set up, and it’s the mechanism most advertisers reach for first.

What the Conversions API Does (Server-Side)

The Conversions API sends the same kind of conversion event, but from your backend rather than the browser. That matters because browser-side signals can be lost — an ad blocker, a browser tab closed before a script finishes, a JavaScript error unrelated to your form — none of which affect a server that’s already confirmed the underlying record was saved. If you control a backend, this is the more reliable half of the pair.

Comparison Table

Choosing the Right Conversion Event

Why “Reached the Final Step” or “Clicked Submit” Are the Wrong Signal

This is the single most consequential decision in the whole setup, and it’s worth explaining the reasoning rather than just stating the rule. Reaching the last step of a form means someone scrolled that far — it says nothing about whether they finished. Clicking a submit button is closer, but a click can be followed by validation failure, a network error, a backend rejection, a duplicate-entry check, or a database write that fails silently on the server — none of which represent the outcome you’re actually trying to measure. Any of these “looks like a conversion but isn’t” signals will inflate your reported conversions against a business outcome that never actually happened, and there’s no way to tell, from the number alone, how badly. The only signal that reliably represents the real thing is confirmation from whatever system actually owns the outcome — your backend confirming a record was saved, not any earlier point in the user interface.

Supported Standard Events

OpenAI’s documentation describes standard conversion event categories — broadly, lead-type, registration-type, and purchase-type events, among others — and states that custom conversion events are not currently eligible as the optimization goal for oCPC campaigns; only a supported standard event qualifies. The exact list of supported event names is exactly the kind of detail that shifts as the beta evolves, so check your current Ads Manager data source configuration directly rather than hard-coding an event name from any article, this one included.

How to Set Up the Pixel on Your Website

In Ads Manager, create a web data source under your measurement or conversions settings, which generates a Pixel ID. Add the Pixel’s initialization snippet to your site — we’d strongly recommend using the exact snippet Ads Manager generates for your data source rather than hand-writing your own, since OpenAI can change the underlying SDK syntax, and a hand-rolled version can silently drift out of date. Where you place it depends on your site: a traditional server-rendered site can put it in a shared base template so it’s available site-wide; a single-page application should initialize it as early as possible in the app’s lifecycle, covered in more detail below. Once it’s loading, fire the actual conversion event only at the point that represents your real conversion boundary — not on page load, and not on an intermediate UI action.

How to Set Up Server-Side Tracking With the Conversions API

The same data source in Ads Manager that generates your Pixel ID also provides a Conversions API key. From your backend, send a conversion event after — and only after — the action you’re measuring has actually been confirmed server-side. Conceptually, for a course-signup business:

// Backend, after the enrollment record is actually saved
enrollment = save_enrollment(form_data)
# enrollment now definitely exists in the database
 
send_conversions_api_event(
    event_name="registration_completed",
    event_id=enrollment.id,
    oppref=stored_oppref
)

The exact request shape, authentication, and required fields should come from your current Ads Manager credentials and OpenAI’s developer documentation rather than being copied from any example — including the one above, which is illustrative pseudocode, not a real API call.

One security point worth stating plainly, since it’s an easy mistake to make when a deadline is close: Conversions API credentials belong on your server, never in frontend JavaScript. It’s a natural temptation to reuse the same key you’re already using client-side for the Pixel, but the Conversions API’s credentials are meant to authenticate your backend, not your browser — shipping them in client-side code exposes them to anyone who opens dev tools. Keep them in your server’s environment configuration, the same place you’d keep any other private API key.

Event Deduplication With a Shared Event ID

If you’re sending the same underlying conversion through both the Pixel and the Conversions API — which OpenAI’s documentation recommends for resilience — use the same event ID on both. A natural choice is your own database record’s ID (the enrollment ID, the order ID, whatever your backend already generates uniquely for that record). OpenAI can then recognise both signals as the same real-world event and deduplicate them, rather than counting one conversion twice.

Tracking Conversions on Multi-Step Forms

Defining the True Conversion Boundary

For example, imagine a course-signup flow split into three steps on one page — account details, course and plan selection, and payment confirmation — all rendered client-side without the URL changing between them. The temptation is to fire a conversion when the third step becomes visible, since that feels like “the user made it to the end.” Don’t. The correct boundary is one step later: after the final submission is sent to your backend, and your backend confirms it was actually saved. The steps themselves — reaching step two, reaching step three — can be tracked as your own internal analytics if that’s useful to you, but none of them should be the event you send to OpenAI.

Worth keeping those two purposes distinct in your own head, since it’s easy to blur them once you’re already tracking every step for your own funnel analysis: internal analytics can care about every intermediate milestone, because that’s how you diagnose where people drop off. The single event you send to OpenAI as the advertising conversion should only ever be the one that represents the real business outcome. Sending step-completion events to your own dashboard is useful. Sending them to Ads Manager as conversions inflates your reported results against an outcome that didn’t actually happen.

The reasoning, made concrete:

// Wrong — fires as soon as the last step renders
if (currentStep === 3) {
    fireConversionEvent();
}
 
// Also wrong — fires on the click, before we know it succeeded
submitButton.addEventListener("click", () => {
    fireConversionEvent();
});
 
// Right — fires only after the backend confirms success
submitForm(formData).then(response => {
    if (response.success) {
        fireConversionEvent({
            event_name: "registration_completed",
            event_id: response.enrollment_id
        });
    }
});

That last version is the one that actually maps to a real, confirmed outcome — everything else is a proxy that can be wrong in either direction.

Tracking Conversions on Single-Page Applications

Example Architecture: Frontend SPA + Backend API

For example, imagine the same course-signup form built as a React single-page application with a separate backend API — a common and genuinely sound architecture, not a complication for conversion tracking. The flow looks like this:

ChatGPT Ad
    ↓ click
yoursite.com/course-signup/?oppref=ABC123
    ↓
React app loads → Pixel initializes, captures oppref
    ↓
Step 1 → Step 2 → Step 3 (client-side, URL doesn't change)
    ↓
Submit → POST to backend API
    ↓
Backend validates and saves the enrollment
    ↓
Backend returns { success: true, enrollment_id: 1842 }
    ↓
Frontend fires Pixel conversion event
    +
Backend fires Conversions API event (same event_id)
    ↓
OpenAI deduplicates and attributes the conversion

A few things worth being deliberate about in this shape. First, initialize the Pixel as early as possible in the application’s lifecycle — typically the app’s root component — so it’s active from the moment someone lands on the page, not only once they reach a later step. Second, the URL staying constant across all three steps is completely fine; oppref lives in a cookie once the Pixel captures it, not in the visible URL, so client-side step changes don’t affect attribution. Third, treat the backend’s success response as the only trigger — the frontend should fire its conversion event because the backend said so, not because a button was clicked.

This architecture works with any backend — Django, Node, or otherwise; the backend technology is genuinely not the deciding factor here. What matters is that some system you control can confirm, definitively, that the record was saved, and that confirmation is what triggers the conversion event, on either or both sides.

Verifying Your Setup in Ads Manager (and Expected Reporting Delays)

Installing the code isn’t the finish line — worth actually verifying it end to end before trusting the numbers it produces. A reasonable sequence: confirm the Pixel is loading at all, using your browser’s dev tools rather than assuming the snippet worked; walk through a real test signup yourself, the same path an actual visitor would take; confirm the conversion event fires only after that test signup genuinely succeeds, not on an earlier step; check that the event you’re sending matches the conversion event configured for the campaign, since a mismatch there means nothing gets attributed even if the event fires correctly; and only then check Ads Manager’s reporting, with the delay below factored in.

Once events are flowing, Ads Manager reports conversions alongside impressions, clicks, spend, CTR, CPC, and CPM. OpenAI’s documentation notes that delivery reporting (impressions, clicks) can lag by up to roughly 7 hours, while attributed conversions specifically can take 24–48 hours to appear. Don’t treat an empty conversion report on day one as proof your implementation is broken — check that events are firing correctly in your own logs or browser dev tools first, and give the reporting delay its full window before concluding something’s wrong.

Common Conversion-Tracking Mistakes

• Firing on step-reached or button-click instead of backend-confirmed success. Covered in detail above — this is the mistake with the biggest impact on data quality.
• Losing oppref across redirects or client-side navigation. If your flow involves a redirect before the Pixel has a chance to capture the reference, attribution can break before tracking even starts.
• Using different event IDs for the Pixel and Conversions API for the same real event. This defeats deduplication and can double-count a single conversion.
• Picking a custom event name when you plan to run oCPC. OpenAI’s documentation is explicit that oCPC requires a supported standard event — a custom event simply won’t be eligible as the optimization goal.
• Panicking over an empty conversion report on day one. Reporting lag is normal and documented; check that events are actually firing before assuming the setup is broken.

Recap: Building a Reliable ChatGPT Ads Measurement Stack

Reliable measurement comes down to a short set of disciplines: know exactly which action counts as your real conversion before you write any code; fire that event only on confirmed success, never on an earlier UI milestone; use the Pixel and Conversions API together where you can, tied by a shared event ID; and give reporting its documented delay before treating a quiet dashboard as a broken pipeline. None of this is exotic engineering — it’s the same rigor worth applying to any analytics implementation, just specific to how OpenAI’s oppref-based attribution works. If you haven’t set up your advertiser account yet, our beginner’s guide to advertising on ChatGPT covers that starting point, and if you haven’t structured your ad groups and campaign yet, our campaign setup guide covers everything upstream of the measurement work in this article.

Wiring up reliable conversion tracking — Pixel, Conversions API, or both — is exactly the kind of technical work that’s easy to get subtly wrong in a way that quietly corrupts your data for weeks. Valentius Kryptix can implement and audit your ChatGPT Ads measurement stack so you’re not making decisions on numbers you can’t fully trust. Talk to our team →

Frequently Asked Questions