Why ChatGPT shows fewer conversions than you actually got
The three reasons your ChatGPT Ads dashboard undercounts sales, and how to tell which one is affecting your store.
You ran ads on ChatGPT. Orders came in. But the conversion count in your ads dashboard is lower than the number of orders in Shopify, and the revenue figure is lower still.
I've been building conversion tracking for ChatGPT Ads for a while now, and I want to walk through what actually causes this — because when I first hit it on my own test store, I assumed the pixel was broken. It wasn't. Everything returned a success response. The events were simply arriving without the one piece of information that ties them back to your ad.
Here is what's really going on, in the order I'd check it.
First, some of the gap is normal#
Before the debugging: a gap of some size is expected, and no setup removes it.
ChatGPT attributes a conversion two ways. Click-through attribution counts a purchase when someone clicked your ad within a configured window. View- through attribution counts a purchase when someone saw your ad but didn't click, and that window is fixed at one day.
So a shopper who sees your ad on Monday, thinks about it, and buys on Thursday without clicking is a real sale your ads caused and that ChatGPT will not credit. That's not a bug — every ad platform draws this line somewhere.
What you're looking for is a gap bigger than that. In my case the gap was total: real orders, tracked as if they came from nowhere.
Cause 1: the click ID never reached the order#
This is the big one, and it's the one almost nobody finds without looking.
When someone clicks your ad, ChatGPT appends a click identifier to your landing page URL. It looks like this:
https://yourstore.com/products/trail-shell?oppref=Cj0KCQiA-oppref-example
That oppref value is the entire link between the click and the sale. If the purchase event arrives without it, ChatGPT has an anonymous conversion. It sees a sale. It cannot tell you the sale came from your ad.
The parameter only exists on the landing page URL. By the time the shopper has browsed three products and reached checkout, it's long gone from the address bar — so it has to be stored somewhere and carried forward. Standard practice is a first-party cookie (__oppref); mine holds it for 90 days.
Where this breaks on Shopify: most integrations carry the click ID forward by attaching it to the cart. It's the natural place — the cart follows the shopper into checkout and becomes part of the order.
Except express checkout doesn't use the cart.
When a shopper taps Shop Pay, Apple Pay, Google Pay or PayPal directly from a product page, Shopify sends them straight into checkout. The cart is never created. Anything you attached to the cart is never attached to anything.
I found this the way most people will: four orders in a row on my test store came through with no click ID attached, while orders through the normal add-to-cart path tracked perfectly. Same store, same pixel, same ad. The only difference was which button the shopper pressed.
That's a nasty failure mode, because express checkout skews toward mobile and toward your most decisive buyers — the ones most likely to have come straight from an ad. You lose attribution precisely where your ads work best.
How to check: place two test orders on your own store. One through add-to-cart and checkout normally. One by tapping the express checkout button on a product page. If the first tracks and the second doesn't, this is your problem.
The fix is to stop relying on the cart as the only carrier — the tracking code needs a second path that hands the click ID over directly when checkout begins, independent of whether a cart exists. Once I added that, the express checkout order tracked with the click ID intact.
Cause 2: the shopper's browser never sent the event#
Browser-based tracking is a request made from the shopper's device. Plenty of things stop it:
- Ad blockers and privacy extensions block requests to known measurement endpoints outright.
- Browser privacy modes — Safari's protections, Firefox's strict mode, private windows — restrict or clear the cookie holding the click ID.
- The shopper closes the tab on the thank-you page before the request finishes.
- Flaky mobile connections drop the request entirely.
None of these produce an error you'd ever see. The order completes, the customer is happy, and the event silently never happened.
There's no way to defeat this from the browser, because the browser is the thing being restricted. The answer is to send purchase events from your server as well, using the Conversions API. Your server knows the order completed regardless of what the shopper's browser did.
If you're running browser tracking only, expect to lose somewhere in the region of a fifth of purchase events to this category — the exact number depends heavily on your audience. A store selling to developers loses far more than one selling to retirees.
Send both, tag each purchase with the same event ID, and ChatGPT counts one conversion rather than two. That last part matters — see below.
Cause 3: the shopper declined tracking#
If you run a consent banner, and a shopper declines, tracking should not fire. That's the banner working correctly.
Worth saying plainly because I've watched people spend a day debugging a "broken" pixel that was doing exactly what it was told. If you serve the EU or UK and your banner defaults to denied, a meaningful share of your traffic will never be tracked, and that's the intended behaviour.
Check what your decline rate actually is before treating the gap as a fault. If 30% of your EU visitors decline, you've explained 30% of your missing conversions and there is nothing to fix.
The one that inflates instead#
Worth knowing about since it's the mirror image: if you turn on server-side tracking without wiring it up correctly, you can end up sending the same purchase twice — once from the browser, once from the server — and reporting double the conversions you got.
The guard is the event ID. Both events carry the same one, and ChatGPT recognises them as one conversion. Without it, your numbers go up and your reported cost per acquisition halves, which is a much more pleasant-looking problem and a much more expensive one, because you'll scale spend on it.
How to work out which one is hitting you#
In order, because each rules out the ones below it:
- Compare your Shopify order count to your ads dashboard for the same period. Establish the actual size of the gap before theorising.
- Place a test order through express checkout. Then place one through the normal cart flow. If only one tracks, it's Cause 1.
- Check your consent decline rate. If it's high and you sell into the EU, part of your gap is explained and legitimate.
- Check whether purchases are being sent from your server at all. If it's browser-only, some loss is unavoidable.
For step 2 you'll want to see the events as they fire. I built a free Chrome extension for this — it shows every event your store sends to ChatGPT, decodes what's in it, and tells you whether the click ID came along. It's how I found the express checkout problem, and it turns "the numbers look wrong" into "this specific event is missing this specific field."
What I'd take away#
The reason this is worth an afternoon: none of these failures announce themselves. Every request returns a success response. Nothing errors. Your store works perfectly. The only symptom is a number that's lower than it should be — and a number that's lower than it should be looks exactly like ads that aren't working.
Which means the real cost isn't the reporting. It's the decision you make next. I've seen the logic: campaign shows a 1.4x return, so pause it. If half your conversions weren't being counted, the real figure was 2.8x and you just switched off the thing that was working.
Fix the measurement before you judge the campaign.
I build LLM Pixels, a Shopify app that handles ChatGPT Ads conversion tracking — including the express checkout path and server-side purchases. The Chrome extension mentioned above is free and works on any store, whatever you use to run your pixel.