# ChatGPT Ads Event Quality Score: Every Warning, Diagnosed and Fixed (2026)

URL: https://www.gptadsai.com/guides/chatgpt-ads-event-quality
Author: Tarun Kapoor — Founder, GPT Ads AI (12+ years paid media)
Published: 2026-09-17
Type: Guide

> OpenAI grades every ChatGPT Ads pixel and data source on event quality, daily, over seven complete calendar days. All nine warnings in OpenAI's own words, the exact Pixel and Conversions API field that clears each one, why a score can be unavailable, how it compares to Meta EMQ and Snapchat EQS, and who on your team owns the fix.

## Contents

- [What event quality is — and what it is not](#what-event-quality-is-and-what-it-is-not)
- [Where to find event quality, and how to work the warnings](#where-to-find-event-quality-and-how-to-work-the-warnings)
- [The nine event quality warnings, and what fixes each one](#the-nine-event-quality-warnings-and-what-fixes-each-one)
- [Why a score or check may be unavailable](#why-a-score-or-check-may-be-unavailable)
- [Event quality vs Meta EMQ, Snapchat EQS and Pinterest EQS](#event-quality-vs-meta-emq-snapchat-eqs-and-pinterest-eqs)
- [The field map: which key goes where](#the-field-map-which-key-goes-where)
- [Deduplication, and the two warnings it causes](#deduplication-and-the-two-warnings-it-causes)
- [Why your event quality dropped](#why-your-event-quality-dropped)
- [A weekly event quality routine](#a-weekly-event-quality-routine)
- [What this looks like on a real account](#what-this-looks-like-on-a-real-account)
- [Sources and further reading](#sources-and-further-reading)

> **Short answer.** Event quality is OpenAI's daily assessment of whether the conversion data arriving from a ChatGPT Ads pixel or data source is actually usable for measurement. Each data source gets its own score and its own list of **nine named warnings**, refreshed daily over **seven complete calendar days**. There is no published numeric scale and no target number — you work the warnings, not the score. OpenAI states plainly that event quality *"[does] not predict campaign performance or guarantee that a conversion will match to an ad."* This guide takes all nine warnings in OpenAI's own wording, explains what each one is really telling you, names the exact pixel or Conversions API field that clears it, and says which team in your company owns the fix.

Every conversion tracking system undercounts. What is new is that ChatGPT Ads now tells you *how* yours is undercounting, in writing, every day. That is a significant upgrade on the usual state of affairs — where a measurement defect shows up as a CPA that looks slightly wrong for a quarter and nobody can say why.

It also creates a new failure mode. A list of nine warnings with no scale and no threshold invites two equally bad reactions: ignore it because there is no number to chase, or panic and start sending more events to make it look better. Both cost money. What follows is the operating procedure we use on client accounts, in the order we actually work it.

> **Who this is for.** Anyone looking at an event quality warning in OpenAI Ads Manager and deciding whether it is a developer ticket, a marketing-ops fix, or something to leave alone. Warning names and their published guidance are quoted from [OpenAI's event quality documentation](https://help.openai.com/en/articles/20001513-understand-and-improve-event-quality); field names come from the current [Conversions API](https://developers.openai.com/ads/conversions-api) and [Measurement Pixel](https://developers.openai.com/ads/measurement-pixel) references. Where we give operating judgement rather than documented behaviour, it is labelled as ours. If you have not installed tracking yet, start with the [conversion tracking guide](/guides/chatgpt-ads-conversion-tracking.md) and come back here.

## What event quality is — and what it is not

Event quality answers one question: **is the conversion information you are sending good enough to connect an event to the right person and the right ad click?** It is assessed per pixel or data source, not per campaign and not per account, so two data sources on the same ad account can carry completely different warnings.

Three mechanics matter before you read a single warning, because they explain most of the confusion advertisers have with this feature.

- **It refreshes daily, over a seven-day window.** The assessment uses seven complete calendar days, with time allowed for recent events to arrive. That means a fix you shipped this morning cannot show up today, and it will not show up fully for a week — improvements appear gradually as the older, broken events age out of the window.
- **A delayed refresh does not wipe your score.** If the daily refresh is late, the previously available score stays visible until a newer assessment is ready. A score that has not moved is not evidence that your fix failed.
- **It is a diagnostic, not a lever.** OpenAI is explicit that the score and warnings highlight areas of your setup to review, and that they do not predict campaign performance or guarantee a conversion will match. There is no published scale, no bands, and no pass mark.

| Event quality **is** | Event quality **is not** |
|---|---|
| A per-data-source health check on the conversion information you send | A campaign performance forecast |
| A named list of specific, fixable integration defects | A bid signal or a ranking factor |
| Refreshed daily across seven complete calendar days | Real-time — nothing you ship today shows up today |
| Evidence about the events it can assess | A census of every conversion or every customer journey |
| A reason to fix your integration before you scale spend | A number to optimise toward for its own sake |

> **The one rule that governs everything below.** OpenAI's guidance is unusually direct about it: *"Only send information you are permitted to share and respect the person's privacy and consent choices. Use real customer information and real business actions. Do not send extra events, invent identifiers, or change event times to improve a score."* Every one of those prohibitions describes a real tactic someone has already tried. All of them corrupt the data the auction learns from, which means they cost more than the warning did.

## Where to find event quality, and how to work the warnings

Event quality lives with your data sources in Ads Manager, under **Tools → Conversions**, alongside the pixel validation diagnostics panel covered in the [conversion tracking guide](/guides/chatgpt-ads-conversion-tracking.md#pixel-validation-diagnostics-in-ads-manager). Open the warnings for the data source you care about and review each one.

The two panels answer different questions and both belong in your weekly review. **Pixel validation diagnostics** tell you why an event was *dropped* — which field failed, what the error was, and a recommended fix. **Event quality** tells you whether the events that *did* arrive are useful. An integration can pass diagnostics cleanly and still carry five event quality warnings, because nothing was malformed; it was just thin.

OpenAI's own advice on sequencing is to start with the issues you can verify in your integration — missing matching information, delayed server events, repeated event firing — and to investigate the cause before changing the setup. Our working order, which is operating judgement rather than documented guidance:

1. **Attribution first.** If the click reference is being lost, nothing downstream can be attributed no matter how good your identity data is. Fix `oppref` survival before anything else.
2. **Identity second.** Email or a stable customer ID on the events that matter, then the supporting fields. This is the largest and cheapest coverage win available.
3. **Timing and duplication third.** The one-hour rule and a consistent event ID. These are architectural, so they take longer and need a developer, but they are also the ones that quietly inflate or deflate your conversion count.
4. **Breadth and goal configuration last.** Funnel coverage and conversion-goal wiring matter, but they are usually a reporting problem rather than an attribution one.
5. **Then wait a week.** Do not ship four fixes on four consecutive days across a seven-day assessment window — you will never learn which one worked. Ship a batch, note the date, and read it again in seven days.

## The nine event quality warnings, and what fixes each one

This is the reference section. Each warning below carries OpenAI's own name and meaning, then the field-level fix, then how we verify it. The table is the index — find your warning, then read its subsection.

| Warning | What it is really telling you | First thing to check | Who owns the fix |
|---|---|---|---|
| Limited email or customer ID information | Your conversions arrive without a strong identifier | Whether checkout or the form actually captures an email, and whether it reaches the event | Marketing ops, then developer |
| Ad click information is missing or cannot be connected | The click reference is being destroyed between the ad and the conversion | Every redirect hop, the consent interstitial, and the browser-to-server handoff | Developer |
| Conversions API events are delayed | Server events arrive more than an hour after the action | Batch schedules, queue depth, retry logic, and the timestamp you send | Developer |
| Conversion matches need review | Potential matches were removed during attribution checks | Duplicate tags, repeated callbacks, retries, and event ID consistency | Developer |
| Many conversions are linked to the same ad interaction | Conversions are unusually concentrated on a few clicks or views | Whether a page refresh, callback or retry re-sends the same business action | Developer |
| Limited additional matching information | Only your primary identifier is present; the supporting fields are absent | Phone, name plus postal code plus country, and the real client IP and user agent | Marketing ops, then developer |
| Limited event types observed | You are reporting outcomes without the browsing and intermediate steps | Which funnel stages actually exist in your journey, and whether each fires | Marketing ops |
| Limited Pixel and Conversions API activity | One or both channels are installed but not measurably delivering accepted events | That requests are accepted and pointed at the intended data source | Developer |
| Limited activity for a configured conversion goal | A goal you configured is receiving almost nothing | Whether the configured event name byte-matches the event you send | Marketing ops |

### 1. Limited email or customer ID information

**What it means.** OpenAI observed limited email or stable customer ID information on the conversion events eligible for this check. These identifiers are what connect an event to the correct person. OpenAI also notes that a low result can reflect a processing or integration issue rather than genuinely absent data — so before you conclude your forms are the problem, confirm what your integration is actually sending.

**What clears it.** An email address or your own stable customer identifier on the conversion events that matter, through the fields your integration supports:

- On the **Pixel**: `email_sha256` and `external_id_sha256`, set in the `init` call's `user` object.
- On the **Conversions API**: `emails_sha256` and `external_ids_sha256` — note the **plural list forms**, which is the single most common reason a correctly-built server integration reports nothing here.
- Hash with SHA-256 after normalising: trim and lowercase an email; trim an external ID but **preserve its case**.
- Call `init` again with the complete object if identity arrives later in the session, such as after login.

**The trap that produces this warning on accounts that look fine.** OpenAI's guidance says to keep the same customer identifier for the same person, and not to reuse a shared, placeholder or default identifier for different people. In practice that means a guest checkout writing `guest`, `0`, `null` or a session ID into the external ID field is worse than sending nothing — you have told the platform that thousands of different people are one person. If you cannot produce a stable per-person ID, omit the field.

**How we test it.** Put a real order through the normal customer journey and confirm the expected fields are present on the event, on both the browser and server paths if you run both. A normalisation mismatch between the two — frontend hashing the raw input, backend hashing a trimmed and lowercased value — produces two different digests, degrades matching, and throws no error anywhere. Write the normalisation once, in one shared function, and unit-test it against a fixed fixture.

### 2. Ad click information is missing or cannot be connected

**What it means.** Some assessed conversions that were associated with an ad click did not include click information that could be connected back to that same click. OpenAI is careful to scope this: it covers the clicked conversions it can assess, and does not measure every ad click or every customer journey.

**What clears it.** Preserving the `oppref` parameter from the moment someone lands on your site from an ad, through every redirect and every subsequent navigation. The [identity chain is documented in full](/guides/chatgpt-ads-conversion-tracking.md#how-attribution-identity-flows-oppref-obref-and-the-cookie) in our conversion tracking guide, but the short version is: the ad appends `oppref` to your landing URL, the Pixel captures it into a first-party cookie, later events carry it automatically, and your server reads that cookie's **unmodified** value and sends it as `obref` on Conversions API events.

**Where the chain breaks, in the order we find it:**

- **Redirects that drop the query string.** Link shorteners, affiliate wrappers, marketing-automation click trackers, and naive `www` or locale redirects all discard `oppref` happily. Test the live destination URL, not the one in your campaign sheet.
- **Consent interstitials that navigate before the SDK runs.** If your consent platform bounces the visitor to a consent page and back without carrying parameters through, the identifier is gone before anything captured it.
- **Client-side canonicalisation.** A landing page that immediately rewrites itself to a canonical URL without the query parameters — common on frameworks that normalise routes on mount.
- **Cookie policies that block the first-party cookie write,** so the identifier survives the landing page and nothing after it.
- **Server-side input sanitisation.** A well-meaning filter that trims, re-encodes or lowercases the cookie value before forwarding it. Pass through exactly what the browser holds.

**The diagnostic that saves a week.** If conversions that happen in a single uninterrupted session attribute fine but multi-page journeys do not, your cookie write is the problem. If nothing attributes at all, the parameter is being lost before the landing page ever loads. Those two findings point at different teams, which is worth establishing before you raise a ticket.

**And the thing not to do.** OpenAI's guidance is explicit: do not reuse another person's click information or substitute a default value. A hard-coded `oppref` will clear the warning and destroy your attribution.

### 3. Conversions API events are delayed

**What it means.** Some assessed server events arrived too long after the recorded action, or their timing could not be assessed correctly. OpenAI states the threshold directly: **the check looks for receipt within one hour of the action.**

**Why this one catches good engineering teams.** A nightly or hourly batch export is a perfectly reasonable data pipeline for almost every other purpose, and it fails this check by design. So does a queue that drains on a schedule, a retry with a long backoff, and a finance-driven offline import. None of those are bugs; they are architectural decisions that now have a measurement consequence.

**What clears it:**

- Send the event promptly once the business action is confirmed — not on a schedule, and not before the action is real.
- Audit scheduled uploads, queue depth, failed requests and retry delays. A queue that is usually fast and occasionally hours deep will trip this intermittently, which is harder to diagnose than a consistent failure.
- **Keep the original action time when you retry.** Do not replace `timestamp_ms` with the upload time. This is the single most common way teams accidentally make the delay warning permanent while believing they fixed it.
- Verify timestamp format, units and clock settings. `timestamp_ms` is milliseconds; a seconds-based value is off by a factor of a thousand and will not fall inside any sane window.

> **The architecture that satisfies this without putting OpenAI on your checkout path.** Write conversion events to a durable queue at the moment of the business action, and drain that queue on a short interval with a worker that batches, retries with backoff, and preserves the original `timestamp_ms`. Do not call the API synchronously inside the checkout request — that turns an OpenAI latency spike into a checkout latency spike. The batching detail is in the [Conversions API section](/guides/chatgpt-ads-conversion-tracking.md#the-conversions-api-full-request-anatomy) of the tracking guide, including the fact that one malformed event fails the entire batch.

### 4. Conversion matches need review

**What it means.** Some potential conversion matches were removed during attribution checks. OpenAI names the likely causes: repeated callbacks for the same action, inconsistent timing, or too many matches linked to the same ad view. It also adds an important reassurance — this does not mean your underlying business events were deleted, or that every affected event was invalid.

**What clears it:**

- Confirm that a conversion fires **after a real action** — a confirmed order, a completed registration — rather than on a page load that can be repeated.
- Hunt repeated page loads, duplicate tags, webhook callbacks and retries that send the same action more than once. A thank-you page that a customer refreshes, or a payment webhook that retries until it gets a 200, both produce this.
- Use a **consistent event ID** for copies of the same action, including the browser and server copies of one conversion — and **different IDs for genuinely distinct actions**.
- Preserve the action's original timestamp, and investigate any mismatch against your own business records.

**If the events are accurate and the warning persists,** OpenAI's documented path is to contact support with the data source, the affected event names, the date range, and the checks you have already completed. That last item is the one that gets a useful answer rather than a generic reply.

### 5. Many conversions are linked to the same ad interaction

**What it means.** The conversions OpenAI can assess are unusually concentrated on a small number of ad clicks or views. This is the warning most likely to be a false positive on a healthy account, and OpenAI says so: a customer can legitimately complete multiple actions after one interaction, so the warning alone does not prove duplicate events or invalid activity.

**Work out which case you are in before you change anything.**

| This is a defect if… | This is legitimate if… |
|---|---|
| A page load, refresh, callback or retry re-sends the same business action | A customer genuinely buys repeatedly after one ad interaction |
| Distinct actions are sharing one event ID | Your journey has several real, distinct steps that each fire once |
| Conversion events fire at the wrong stage of the journey | You sell consumables or subscriptions with fast repeat purchase |
| Retries generate a new event ID each time instead of preserving the original | One account signup legitimately produces several tracked outcomes |

**If the pattern is real,** OpenAI's guidance is to retain those events and document the behaviour when asking support to review the warning. A permanently-present warning on a subscription or consumables business is an acceptable end state. Do not delete real conversions to clear a diagnostic.

### 6. Limited additional matching information

**What it means.** Your eligible conversion events contain limited *additional* matching information — meaning the supporting identity fields beyond email and customer ID. This check considers three groups: phone information; name and location information; and the combination of client IP address and user agent. Critically, OpenAI notes it measures **the presence of information, not whether a person was successfully matched** — so this is purely a coverage check, and coverage is entirely within your control.

**What clears it:**

- **Phone**, where you are permitted to send it: `phone_number_sha256` on the Pixel, `phone_numbers_sha256` on the API. Normalise first — strip the leading `+`, leading zeroes, whitespace, brackets, periods and hyphens so 8 to 15 digits remain — then hash.
- **Name and location for the same person**: first name, last name, postal code and country. Names are hashed after lowercasing and removing whitespace and ASCII punctuation; country, region, city and postal code are sent raw.
- **The real client's IP address and user agent** on server events, taken from the inbound request. OpenAI's wording leaves no room here: *"Do not substitute your server's address or a generic user agent."* Forwarding your own data-centre IP for every conversion is worse than sending nothing.
- Keep sending eligible email or stable customer ID as well — additional matching information supplements your primary identifier rather than replacing it.

> **The proxy problem nobody warns you about.** If your traffic passes through a CDN or reverse proxy, the connection your application sees originates from the proxy, not the customer. Read the forwarded-for header your provider sets and send that value — otherwise every server event carries one identical IP, which reads as a single person making thousands of conversions and can trip warning 5 as well.

### 7. Limited event types observed

**What it means.** OpenAI observed limited activity across the three standard event groups this check uses: **browsing**, **intermediate actions**, and **completed outcomes**. It explicitly allows for the fact that different businesses have different journeys and not every stage applies, and that the check does not verify your entire funnel is complete.

**What clears it.** Map the steps that genuinely exist in your customer journey, then confirm each applicable one fires:

| Group | What belongs here | Standard events |
|---|---|---|
| Browsing | Someone is looking | `page_viewed`, `contents_viewed` |
| Intermediate actions | Someone is committing | `items_added`, `checkout_started`, `lead_created` |
| Completed outcomes | Someone converted | `order_created`, `registration_completed`, `trial_started`, `subscription_created`, `appointment_scheduled` |

Use a supported standard event whenever one accurately represents the action — the [full standard event reference](/guides/chatgpt-ads-conversion-tracking.md#the-complete-standard-event-reference) lists every one. One detail matters here more than anywhere else on the page: **custom events are not included in this particular breadth check.** An account measuring its entire funnel through well-named custom events will carry this warning permanently and there is nothing wrong with its tracking.

**And the line not to cross.** OpenAI's guidance ends with *"Do not create artificial funnel stages to clear a warning."* If your business genuinely has no add-to-cart step, inventing one produces a cleaner diagnostic and a worse dataset.

### 8. Limited Pixel and Conversions API activity

**What it means.** OpenAI has not observed enough **accepted** activity from the supported Pixel SDK or Conversions API channels to assess their use positively. The sentence that matters: *"Installing an integration alone does not establish that events are arriving."*

**What clears it:**

- Verify the Pixel is sending browser events and the Conversions API is sending confirmed server outcomes, to the extent each fits your setup.
- Confirm requests are **accepted** — not merely sent — and that they are going to the **intended data source**. A staging pixel ID in production, or a second data source created during a migration, both produce this warning while a developer watches successful network calls in the console.
- When both channels report the same action, use the **same Pixel ID, the same event name, and the same event ID** so the copies can be recognised as copies.
- Keep distinct events for distinct actions, and do not send an outcome before it actually occurs.

OpenAI's own framing of the upside is measured, and worth quoting because it is more honest than most vendor material on this subject: using both channels *"can provide complementary information,"* but *"channel activity by itself does not verify correct pairing or complete event capture."* Running both is necessary. It is not sufficient, and it is not a substitute for testing.

### 9. Limited activity for a configured conversion goal

**What it means.** At least one configured conversion goal received very few or no events during the assessment window. Two clarifications from OpenAI make this warning much easier to interpret: other goals can be perfectly healthy while this one appears, and **received events for this check include events that were not matched to an ad** — so this is about whether the events arrive at all, not whether they attributed.

**What clears it:**

- Compare the affected goal's **event name and configuration** against what your integration actually sends. This is the same byte-for-byte mismatch that makes a conversion column read zero: for custom events, Ads Manager must use **Event type: Custom** and the name must match exactly — a matching display name is not enough.
- Confirm the event fires when the real action occurs, and that recent events are being received.
- Review goals that are outdated or no longer represent an action you want to measure. A goal left over from last year's funnel will carry this warning forever and deserves deleting rather than debugging.

**When to do nothing.** If the action is genuinely rare or demand is simply low right now, OpenAI's guidance is to continue monitoring: *"Low volume alone does not establish a setup defect."* A high-ticket B2B account with four conversions a month is not broken.

### Not sure whether your warning is a developer ticket or a data problem?

Send us a screenshot of your data source warnings and we will tell you which ones are a code fix, which are a marketing-ops fix, and which you should leave alone — before you spend a sprint on the wrong one. It is the first thing we do on every account. See what the full [measurement and attribution build](/services/chatgpt-ads-measurement.md) covers.

[Book a discovery call](https://calendly.com/tarunkapoor/discovery)

[Measurement service](/services/chatgpt-ads-measurement.md)

## Why a score or check may be unavailable

An absent score is not a zero score, and the difference matters because four of the five reasons require no action from you at all. OpenAI documents each state separately.

| Status | What it means | What to do |
|---|---|---|
| **No configured conversion goals** | There is nothing set up to measure | Configure the conversion actions you care about and confirm your integration sends the matching events |
| **Not enough conversion activity** | Too little recent conversion activity to produce a useful score. OpenAI notes this status is **different from a score of zero** | Verify the setup, then let real activity accumulate |
| **Not enough attribution evidence** | Some checks need observable connections between conversions and ad clicks or views. You can be receiving events while this evidence is still limited | Work the `oppref` and click-information path — warning 2 above |
| **Limited information for a check** | One check needs more eligible events or more observable activity. **Missing information is not treated as a failed check** and does not automatically produce an advertiser warning | Nothing. Increase coverage naturally over time |
| **Data is still being processed** | The first assessment is not ready, or the latest one is incomplete | Return after processing completes; contact support only if it persists |

The one to internalise is **not enough attribution evidence**, because it is the state most often misread as "tracking is broken". OpenAI addresses it directly: it does not mean your business has no real conversions. It means the platform cannot yet see enough connections between the conversions it received and the ad clicks or views that preceded them. That is usually a click-reference problem, and it is fixable.

## Event quality vs Meta EMQ, Snapchat EQS and Pinterest EQS

Most people arriving at an event quality warning have a Meta mental model, and the first question is always the same: *what score should I be aiming for?* On ChatGPT Ads there is no answer to that question, and that is a deliberate design difference rather than a gap in the documentation.

| Platform | What it is called | Scale | Scored unit | Refresh window |
|---|---|---|---|---|
| **ChatGPT Ads (OpenAI)** | Event quality | Score plus nine named warnings; **no published numeric scale or threshold** | Per pixel or data source | Daily, over seven complete calendar days |
| Meta | Event Match Quality (EMQ) | 0 to 10 | Per event type, web events, surfaced for Conversions API events | Rolling 48 hours |
| Snapchat | Event Quality Score (EQS) | Good / Okay / Poor, plus N/A | Per use case, event type and source | Up to 24 hours to reflect changes |
| Pinterest | Event Quality Score (EQS) | Good / Fair / Needs improvement | Per event source | 14-day average, 1-day toggle |
| TikTok | Event Match Quality (EMQ Score) | Weighted average of match key coverage | Per event | 7-day activity window |

Two practical consequences. First, **stop looking for the number** — the warning list *is* the interface, and it is arguably more useful than a score because it tells you what to do rather than how you rate. Second, **your existing work carries over**. The identity signals OpenAI prioritises are the same ones Meta and Snapchat prioritise, in nearly the same order.

### The warning crosswalk

If you have run Meta or Snapchat tracking, you have almost certainly fixed these exact defects under different names. This mapping is ours, not OpenAI's, and it is the fastest way for an experienced measurement person to triage a ChatGPT Ads warning list.

| OpenAI event quality warning | The equivalent you already know |
|---|---|
| Limited email or customer ID information | Meta: low coverage on `em` / `external_id`. Snapchat: "Majority of your events sent lack valid identifiers" |
| Ad click information is missing or cannot be connected | Meta: missing `fbc` coverage. Snapchat: "Insufficient volume of conversion click IDs" |
| Conversions API events are delayed | Meta: "share events closer to real time" and the event delay guidance |
| Conversion matches need review | Meta: deduplication overlap on `event_id`. Snapchat: transaction ID overlap between CAPI and Pixel |
| Many conversions are linked to the same ad interaction | Snapchat: "Majority of your conversion events have the same Client Deduplication ID value" |
| Limited additional matching information | Meta: low coverage on `ph`, `fn`, `ln`, `zp`, `client_ip_address`, `client_user_agent` |
| Limited event types observed | Snapchat: "Missing conversion events that are relevant to your Sales funnel". Pinterest: event coverage on lower-funnel events |
| Limited Pixel and Conversions API activity | Meta: the Conversions-API-to-Pixel event coverage ratio |
| Limited activity for a configured conversion goal | Meta: a custom conversion configured against an event name you never send |

The identifier mapping is just as direct: OpenAI's `oppref` and `obref` do the job Meta's `fbc` and `fbp` do, Snapchat's `sccid` does, and Google's `gclid` does. If your team already knows to preserve a click ID through redirects, they already know the most important thing on this page.

## The field map: which key goes where

This is where competent integrations lose match rate silently. The Pixel takes **singular** keys. The Conversions API takes **plural list** keys. Send a singular key to the API — or a plural one to the Pixel — and the field is not read. No error, no rejected event, no diagnostic. Just a quieter match rate and, eventually, warning 1 or warning 6.

| Signal | Pixel `user` key | Conversions API `user` key | Hashed? |
|---|---|---|---|
| Email | `email_sha256` | `emails_sha256` | SHA-256 |
| Phone | `phone_number_sha256` | `phone_numbers_sha256` | SHA-256 |
| Customer ID | `external_id_sha256` | `external_ids_sha256` | SHA-256 |
| First / last name | `first_name_sha256` / `last_name_sha256` | `first_names_sha256` / `last_names_sha256` | SHA-256 |
| Country | `country` | `countries` | Raw |
| Region | `region` | `regions` | Raw |
| City | `city` | `cities` | Raw |
| Postal code | `postal_code` | `postal_codes` | Raw |
| Android GAID | — | `android_advertising_id` | Raw |
| Click reference | captured automatically into the first-party cookie | `obref` (user) and `oppref` (event) | Raw, unmodified |
| Client network | — | `ip_address`, `user_agent` | Raw |

**Normalisation is not optional, and getting it wrong is silent.** Hash only after normalising, and use the same function on both paths:

- **Email** — trim whitespace, convert to lowercase, then SHA-256.
- **Phone** — remove the leading `+`, leading zeroes, whitespace, brackets, periods and hyphens, leaving 8 to 15 digits, then SHA-256.
- **External ID** — trim whitespace only. **Preserve case** and every other character, then SHA-256.
- **Names** — lowercase, remove whitespace and ASCII punctuation, preserve non-ASCII characters, then SHA-256.
- **Region, city** — sent raw; the API trims, lowercases and caps them at 128 characters.
- **Postal code** — sent raw; letters, numbers, spaces or hyphens, up to 32 characters.
- **Country** — sent raw as a two-letter ISO code, such as `US`.

> **Two API behaviours to design around.** The Conversions API uses the **first three valid, unique values** in each list and ignores the rest — so order each list by how confident you are in the value rather than dumping a customer's entire history. And an all-zero advertising ID is **ignored rather than rejected**, so a padded GAID fails quietly instead of loudly. The plural fields are genuinely valuable: one customer routinely has a work and a personal email, or an old and a new phone number, and [sending the set](/guides/chatgpt-ads-conversion-tracking.md#sending-user-matching-data) raises the odds that one of them matches without sending anything you were not already entitled to send.

## Deduplication, and the two warnings it causes

Warnings 4 and 5 — *conversion matches need review* and *many conversions are linked to the same ad interaction* — are usually the same underlying defect seen from two angles. Both come down to one rule: **one business action, one event ID, however many paths report it.**

![One order sent from both the browser pixel and the Conversions API under a shared event identifier, recorded once.](https://www.gptadsai.com/diagrams/event-deduplication.svg)

*One order, two senders, one shared identifier — recorded once. Omit the identifier and both copies count.*

Matching uses the **Pixel ID, the event name, and the event identifier** together — `event_id` on the Pixel side and `id` on the Conversions API side. Both paths must report the same Pixel ID. The implementation rule that makes this reliable is to **generate the identifier once, at the moment of the business event, somewhere both paths can read it.** Your order ID is almost always the right value: it already exists, it is already unique, and it is available to the browser on the confirmation page and to the server at fulfilment.

- **Do** use the same identifier for the browser and server copies of one conversion.
- **Do** preserve the original identifier when you retry — a retry that mints a fresh ID creates a duplicate.
- **Do** use genuinely different identifiers for genuinely different actions.
- **Do not** generate an identifier in the browser and hope the backend can reconstruct it.
- **Do not** derive it from a timestamp or a session — both produce collisions and phantom duplicates.

The consequence of getting this wrong is worse under conversion-optimised bidding than it looks in a report. A doubled conversion count halves your apparent cost per conversion, which makes a mediocre campaign look excellent, which invites you to scale it — while the auction, optimising toward an inflated signal, buys more of whatever produced the phantom. The [conversion campaigns guide](/guides/chatgpt-ads-conversion-campaigns.md) covers what oCPC and oCPM do with that signal, and the [deduplication section](/guides/chatgpt-ads-conversion-tracking.md#deduplication-the-single-most-important-setting) of the tracking guide has the full implementation.

## Why your event quality dropped

A warning that appears on a previously clean data source is almost always a regression from a change your team shipped, not a platform event. Because the assessment window is seven days, the change that caused it may be up to a week old. Check these in order:

| Symptom | Likely cause | Where to look |
|---|---|---|
| Click information warning appears suddenly | A redirect, canonical URL rule or link wrapper was added between the ad and the landing page | Deploys in the last seven days; test the live ad destination URL end to end |
| Identity coverage falls across the board | A form field was renamed, so automatic advanced matching no longer detects it | Front-end changes to checkout or lead form field names |
| Coverage falls in one region only | A consent banner change, or a new market where consent is declined more often | Consent platform configuration and its geo rules |
| Every server event carries the same IP | A CDN or proxy was introduced and the forwarded client IP is not being read | Infrastructure changes; the forwarded-for header handling in your app |
| Delay warning appears intermittently | A queue that is usually fast is occasionally hours deep | Queue depth monitoring and retry backoff settings |
| Duplicate or concentration warning appears | A new webhook, analytics tag or retry path started re-sending confirmed actions | Tag manager changes and any new server-side integration |

> **Do not chase noise.** With a seven-day window and a daily refresh, a warning that appears and disappears once is not a project. Read event quality on a schedule, note what changed in the days before a genuine regression, and treat a warning that persists across two consecutive weekly reviews as real. This cadence advice is ours; OpenAI publishes no volatility guidance.

## A weekly event quality routine

Event quality only earns its keep as a habit. This is the routine we run on managed accounts — fifteen minutes a week, in the same session as the delivery and pacing check.

1. **Open Tools → Conversions and read the warnings on every data source**, not just your primary pixel. A forgotten second data source from a migration is a common source of noise.
2. **Read the pixel validation diagnostics panel beside it.** Dropped events and thin events are different problems with different owners, and the two panels answer different questions.
3. **Compare this week's warning list to last week's.** New warnings get triaged against the deploy log for the previous seven days. Persistent warnings get a ticket. Resolved warnings get noted so you know which fix worked.
4. **Screenshot the list with the date.** You will need it if you contact support, and you will want the history when someone asks why CPA moved two months ago.
5. **Reconcile one full day of platform conversions against your own order table.** Not to make them match — they will not — but to track the ratio over time. That ratio is the most useful number you will own on this channel, and it is much harder to establish once an account is large. The [reporting guide](/guides/chatgpt-ads-reporting.md) covers doing this against CSV exports.
6. **Only then look at performance.** A CPA read against an integration carrying three unresolved warnings is a CPA you cannot act on.

> **If you do need support,** send the data source, the affected event names, the date range, and the checks you have already completed — that is OpenAI's documented list for event quality issues. For a reporting discrepancy the list is longer: ad account ID, campaign and ad names, date range and time zone, an Ads Manager CSV export, your analytics comparison, the Pixel ID, event names, sample conversion timestamps, and screenshots. Assembling it first is the difference between one reply and five. Both checklists are in the [Ads Manager guide](/guides/chatgpt-ads-manager.md).

## What this looks like on a real account

Event quality scoring is new. The failure modes it names are not — they are the same defects we have been fixing on ChatGPT Ads accounts since the channel opened, which is exactly why the warning list reads as familiar to anyone who has done this work. The engagement below predates the score. What it demonstrates is the measurement discipline the score now makes visible.

**8-figure DTC supplements brand.** 92% of new-customer spend was running through Meta and CAC had risen 38% year over year. They wanted a second compounding channel rather than another test. We launched ChatGPT Ads as a parallel channel in 11 days, built a creative system mapped to high-intent buyer questions, **instrumented server-side tracking** — the Conversions API path, click-reference survival through checkout, and shared event IDs for deduplication — and migrated 18% of Meta budget across as performance proved out.

| Result | Measured against |
|---|---|
| **−31%** blended CAC | The 90 days before launch, all channels |
| **3.4x** ROAS on ChatGPT Ads | Channel-level, over the same 90 days |
| **+22%** new customer growth, month on month | Their own prior-month baseline |

*"We treated ChatGPT as an experiment for six months and learned nothing. GPT Ads AI ran it as a P&L channel from day one."* — Head of Growth, DTC supplements brand.

> **Provenance, stated plainly.** This engagement is anonymised under an active NDA, and the figures are program-level over the stated 90-day period rather than the result of any single fix. We are not claiming that clearing event quality warnings produced a 31% CAC improvement — the score did not exist during this engagement. We are claiming that the three things it grades hardest, click-reference survival, identity coverage and deduplication, were built correctly from the start, and that this is what a channel looks like when they are. Two more engagements with their baselines are on the [case studies page](/case-studies.md). Past results do not guarantee future outcomes.

### Want your event quality warnings cleared before you scale spend?

We build the measurement layer and prove it fires before anyone trusts a number: `oppref` survival tested through every redirect, the one-hour Conversions API timing audit, deduplication verified with a live test order, the matching fields upgraded to the plural API keys, and event quality read every week in your account review. That is the [measurement and attribution service](/services/chatgpt-ads-measurement.md) — available on its own or inside full management.

[Book a discovery call](https://calendly.com/tarunkapoor/discovery)

[Measurement service](/services/chatgpt-ads-measurement.md)

## Sources and further reading

- OpenAI Help Center — [Understand and improve event quality](https://help.openai.com/en/articles/20001513-understand-and-improve-event-quality) (all nine warning names, their published meanings, and the five unavailable states)
- OpenAI Help Center — [Conversion Measurement](https://help.openai.com/en/articles/20001409-conversion-measurement) (the click reference, advanced matching, modeled measurement)
- OpenAI Help Center — [Measure Results](https://help.openai.com/en/articles/20001214-measure-results) (reporting columns, attribution windows, the support checklist)
- OpenAI developer docs — [Conversions API reference](https://developers.openai.com/ads/conversions-api) (the plural list field names, normalisation rules, deduplication keys)
- OpenAI developer docs — [Measurement Pixel reference](https://developers.openai.com/ads/measurement-pixel) (the singular field names, `init` options, debug mode)
- Meta Business Help Center — [About event match quality](https://www.facebook.com/business/help/765081237991954) (the customer-information parameter priority table used in the crosswalk above)
- GPT Ads AI — [ChatGPT Ads conversion tracking](/guides/chatgpt-ads-conversion-tracking.md), [reporting](/guides/chatgpt-ads-reporting.md), [conversion campaigns](/guides/chatgpt-ads-conversion-campaigns.md), and the [news timeline](/guides/chatgpt-ads-news.md) for shipped platform changes

## FAQ

**What is event quality in ChatGPT Ads?** Event quality is OpenAI's assessment of whether the conversion information received from a selected ChatGPT Ads data source is useful for measurement. Each pixel or data source carries its own score and its own list of named warnings, refreshed daily using seven complete calendar days of data. It highlights areas of your setup to review, and OpenAI states it does not predict campaign performance or guarantee that a conversion will match to an ad.

**Is ChatGPT Ads event quality a 0 to 10 score like Meta's Event Match Quality?** No. OpenAI publishes no numeric scale, no rating bands and no target threshold for event quality. Meta's Event Match Quality is a 0 to 10 score per event type, Snapchat's Event Quality Score is Good, Okay or Poor, and Pinterest's is Good, Fair or Needs improvement. On ChatGPT Ads the actionable interface is the list of nine named warnings, so you work the warnings rather than chasing a number.

**What is a good event quality score for ChatGPT Ads?** There is no published answer, because OpenAI does not publish a scale or a pass mark. The useful equivalent of a good score is an empty warning list, or a warning list containing only the items that are legitimately permanent for your business — for example the event-types breadth check on an account that measures its funnel through custom events, or the ad-interaction concentration check on a genuine subscription business.

**How often does ChatGPT Ads event quality refresh?** Daily, using seven complete calendar days of data, with time allowed for recent events to arrive. That means a fix cannot show up the same day and will not show up fully for about a week, because improvements appear gradually as the older broken events leave the assessment window. If a refresh is delayed, your previously available score stays visible until a newer assessment is ready.

**Does event quality affect ChatGPT Ads delivery, bidding or oCPC optimisation?** Not directly. OpenAI states that the score and warnings do not predict campaign performance and do not guarantee matching. There is no evidence it is used as a bid signal. The indirect effect is real, though: every warning describes conversions the platform cannot see or cannot trust, and conversion-optimised campaigns learn from the conversions that do get matched. A model optimising on a partial view of your conversions spends real money on the wrong traffic.

**Where do I find event quality in OpenAI Ads Manager?** Under Tools → Conversions, with your data sources. Open the warnings for the data source you want to review. The pixel validation diagnostics panel sits alongside it and answers a different question: diagnostics tell you why an event was dropped and which field failed, while event quality tells you whether the events that did arrive are useful.

**How do I fix 'Limited email or customer ID information' in ChatGPT Ads?** Make sure your eligible conversion events carry an email address or your own stable customer identifier — email_sha256 and external_id_sha256 on the Pixel, or the plural emails_sha256 and external_ids_sha256 on the Conversions API. Hash with SHA-256 after normalising, keep the same identifier for the same person, and never reuse a shared, placeholder or default value such as guest or null for different people. Then put a real order through the normal customer journey and confirm the fields are present on both paths.

**How do I fix 'Ad click information is missing or cannot be connected'?** Preserve the oppref parameter when someone lands on your site from an ad, including through every redirect and subsequent navigation, and pass the click information into server events when you use the Conversions API. Test the full path: tracking links, redirects, consent interstitials, checkout, and the browser-to-server handoff. Never reuse another person's click information or substitute a default value. If single-session conversions attribute but multi-page ones do not, the first-party cookie write is your problem; if nothing attributes, the parameter is lost before the landing page loads.

**Why are my Conversions API events reported as delayed?** The check looks for receipt within one hour of the recorded action, so batch uploads, scheduled exports, deep queues and long retry backoffs all trip it by design. Send events promptly once the business action is confirmed, audit scheduled uploads and retry delays, and critically, keep the original action time when you retry rather than replacing timestamp_ms with the upload time. Also verify the timestamp format, units and clock settings — timestamp_ms is milliseconds.

**Can I improve my event quality by sending more events?** No, and OpenAI prohibits it. The guidance states you should use real customer information and real business actions, and should not send extra events, invent identifiers, or change event times to improve a score. Creating artificial funnel stages to clear the event-types warning is named specifically. Beyond the policy question, it is self-defeating: fabricated events corrupt the signal that conversion-optimised campaigns learn from, so you pay for the deception twice.

**Why is my ChatGPT Ads event quality score unavailable?** There are five documented reasons. No configured conversion goals means nothing is set up to measure. Not enough conversion activity means too little recent activity for a useful score, which OpenAI notes is different from a score of zero. Not enough attribution evidence means events are arriving but observable connections to ad clicks or views are still limited. Limited information for a check means one check needs more eligible events, and is not treated as a failed check. Data is still being processed means the assessment is not ready yet.

**Does automatic advanced matching fix 'limited email' warnings on its own?** It helps and it is worth having on, but it is not a substitute for sending identity deliberately. Automatic advanced matching lets the Pixel detect supported customer information from your website forms and hash it with SHA-256 in the browser, which covers conversions where a click identifier is unavailable. It depends entirely on your forms, so a renamed field can silently reduce coverage, and it cannot help the Conversions API, where you must pass the matching fields yourself. Run both.

**Who should fix each ChatGPT Ads event quality warning?** Click information, delayed Conversions API events, match review, ad-interaction concentration and channel activity are engineering work — they involve redirects, queues, timestamps, event IDs and server configuration. Email and customer ID coverage, additional matching information, event-type breadth and conversion-goal configuration usually start as marketing-ops fixes in forms, tag manager and Ads Manager settings, escalating to engineering only if the data is genuinely not being captured. The unavailable states are mostly a matter of waiting.

## Related guides

- https://www.gptadsai.com/guides/chatgpt-ads-conversion-tracking.md
- https://www.gptadsai.com/guides/chatgpt-ads-reporting.md
- https://www.gptadsai.com/guides/chatgpt-ads-conversion-campaigns.md
- https://www.gptadsai.com/guides/chatgpt-ads-manager.md

## Work with GPT Ads AI

- Measurement & attribution — https://www.gptadsai.com/services/chatgpt-ads-measurement.md
- Ads Manager account setup & access — https://www.gptadsai.com/services/chatgpt-ads-account-setup.md
- Book a discovery call: https://calendly.com/tarunkapoor/discovery