Identifier Coverage in OpenAI Ads, Explained (and How to Raise It)
Identifier coverage is how much of your conversion data OpenAI can actually match to an ad. Here is what it means, why low coverage quietly costs you, and how to raise it.
“Identifier Coverage in OpenAI Ads, Explained (and How to Raise It)”
The short version
- Identifier coverage is the share of your conversion events that reach OpenAI carrying at least one identifier it can match to an ad.
- Events with no identifiers have a near-zero match rate, so your real conversions go uncredited and campaigns optimize on partial data.
- The
opprefin your landing URL gets you a baseline. A per-event user object, built from device and network signals plus a hashed email where allowed, is what lifts coverage. - Reach now attaches that user object to every server-side event automatically, privacy-first, so coverage climbs without you touching code.
If you have opened OpenAI Ads Manager and seen a metric called identifier coverage sitting low, it is worth understanding before you change anything. It is not a vanity number. It quietly decides how many of your sales OpenAI can actually credit to your ads, and how well your campaigns learn. Here is what it means and how to raise it without oversharing customer data.
What identifier coverage actually measures
When someone buys after seeing or clicking a ChatGPT ad, your store sends OpenAI a conversion event. That event is only useful if OpenAI can tie it back to the person who saw the ad. Identifier coverage is the percentage of your conversion events that arrive with at least one matchable identifier for that job. High coverage means most of your conversions can be matched. Low coverage means most of them arrive effectively anonymous.
Why low coverage quietly costs you
Low coverage hits you twice, and both are easy to miss:
- Under-reported conversions. An event OpenAI cannot match is an event it cannot credit. Your ROAS in Ads Manager looks worse than reality, which can push you to pause campaigns that are actually working.
- Weaker optimization. OpenAI optimizes delivery using the conversions it can match. Feed it a fraction of your real conversions and it learns from a fraction, so it bids and targets on a blurry picture.
An event with no user signals at all has a near-zero match rate. That is the failure mode coverage is warning you about.
What raises coverage: oppref plus the user object
There are two matching mechanisms, and you want both:
- oppref is a privacy-preserving reference OpenAI appends to your landing-page URL when someone arrives from an ad. Capturing it and sending it back on the conversion is the baseline, and it is the primary way OpenAI matches without cookies.
- The user object is an optional block you attach to each conversion event. Every field is optional, and the more usable signals it carries, the higher your coverage. This is the lever most merchants are leaving on the table.
Here is what can go in the user object, and how sensitive each signal is:
| Signal | Sent as | Needs protected customer data? | Effect on coverage |
|---|---|---|---|
| IP address + user-agent | Raw | No | Strong baseline lift, available on every event |
| Device / context identifiers | Raw | No | Adds matchable signal |
| Hashed (email_sha256) | Yes | Highest-quality match, where consent allows | |
| External / customer ID | Hashed (external_id_sha256) | Yes | Strong for logged-in shoppers |
Notice the top two rows: you can lift coverage meaningfully using only device and network signals, with no customer PII involved at all.
The privacy question, answered honestly
Raising coverage does not mean dumping raw customer data into an ad platform, and it should not. OpenAI never wants raw email, phone, or customer IDs. Those are sent as one-way SHA-256 hashes; IP, user-agent, and geo can be raw because they are not direct identifiers. The right approach is minimal, hashed, and consent-gated: send the least data that does the job, and only what a shopper has agreed to.
That is deliberately how Reach built this. It leads with device and network signals, which need no protected customer data, and only adds a hashed email where the shopper's consent and Shopify's protected-customer-data rules allow it. Nothing raw, nothing you would be uncomfortable standing behind.
How Reach raises your coverage
Reach's pixel and Conversions API now attach a user object to every server-side conversion event: device and network signals first, hashed email added where consent permits. It is consent-gated and minimal by design, so you get the coverage lift without a compliance headache and without writing any code. You install once, and your events start arriving with something to match on instead of blank.
The rest of a trustworthy setup, server-side delivery and deduplication, is covered in how to track OpenAI Ads conversions on Shopify. If your coverage is sitting at exactly zero, start with identifier coverage at 0%: what to do.
Give your conversions something to match on. Install Reach on the Shopify App Store to send server-side ChatGPT Ads events with a privacy-first user object attached automatically, so your identifier coverage climbs off zero, no code required.
Frequently asked questions
What is identifier coverage in OpenAI Ads?
It is the share of your conversion events that reach OpenAI carrying at least one identifier it can match to an ad. Higher coverage means more of your conversions can be credited and used to optimize.
Why is my identifier coverage low?
Usually because your events are sent without a user object, or you are relying on a browser pixel with no server-side events. Events that arrive with no signals cannot be matched.
Do I have to send customer emails to raise coverage?
No. You can lift coverage using device and network signals like IP address and user-agent, which need no protected customer data. A hashed email is an optional extra where consent allows.
Is it safe to send this data to OpenAI?
Yes, when done properly. Email and IDs are sent as one-way SHA-256 hashes, never raw. The best practice is minimal, hashed, and consent-gated, which is how Reach handles it.
How do I raise coverage without writing code?
Use a tracking app that attaches a user object to every server-side event for you. Reach does this automatically once installed.