OpenAI has added an Event Quality assessment to ChatGPT Ads. Each pixel or data source now carries its own score and its own list of warnings, refreshed daily over a rolling seven-day window. The help centre article describing it — Understand and improve event quality — appeared in the ChatGPT Ads collection between our 2026-09-04 and 2026-09-07 documentation snapshots, and it carries a beta notice: "Event quality is currently in beta, and access is rapidly expanding."

Last verified: 2026-09-07. Everything in the "what the documentation says" sections below is quoted or paraphrased from official OpenAI pages, each linked at the point of use. Everything in the "what this means for your setup" sections is Soku editorial analysis and is labelled as such.

If you have run Meta ads, the shape will be familiar — this is recognisably the same family of diagnostic as Event Match Quality. It is not the same scoring, and OpenAI is unusually explicit about what it refuses to promise, which is the most useful part of the document and the part most likely to be misread.

The one sentence that governs how you should use this

From the official article:

"Your score and warnings highlight areas of your setup to review. They do not predict campaign performance or guarantee that a conversion will match to an ad."

That is a narrower claim than most advertisers will assume. Event Quality tells you whether the information arriving from a data source is the kind of information that can be used for measurement. It does not tell you that your CPA will improve if you raise it, and OpenAI does not claim a causal link anywhere in the document. Treat it as an integration linter, not as a performance lever.

Three mechanical facts follow from the same page and are worth writing on the wall before anyone on your team opens the tab:

The assessment is per data source, not per account. "Each pixel or data source has its own assessment." If you run three pixels across three properties, you are reading three unrelated scorecards.
It refreshes daily across seven complete calendar days, with time allowed for late-arriving events. So a fix does not show up tomorrow — it shows up as the bad days age out of the window. The document says improvements "can appear gradually as earlier events leave the assessment window."
A delayed refresh does not blank your score. "If a refresh is delayed, your previously available score remains visible until a newer assessment is available." An unchanged score after a change may simply be a stale assessment.

The nine warnings, and the field that actually fixes each one

The article enumerates nine named warnings. Below, each one is paired with the integration surface you change to address it. The warning text and remediation guidance are OpenAI's; the mapping to a specific field and the ordering by how often we expect it to bite are ours.

1. Limited email or customer ID information

What OpenAI says it checks: whether eligible conversion events carry an email address or a stable customer identifier. The document is careful to add that "a low result can also reflect a processing or integration issue," so a low score here is not automatically a data-collection problem.

Where you fix it: the hashed-identity fields on the Measurement Pixel and the Conversions API. The instruction that matters most is the one people skip: "Keep the same customer identifier for the same person. Do not reuse a shared, placeholder, or default identifier for different people." A logged-out checkout that assigns guest as the customer ID technically populates the field and defeats the check entirely.

Soku analysis: this is the warning where a well-meaning engineering fix makes the number worse. If you are told to "send a customer ID" and you wire up a session ID, you have sent a field that changes on every visit. The check is about identity stability, not about field presence.

2. Ad click information is missing or cannot be connected

What OpenAI says it checks: conversions associated with an ad click that did not include click information connectable to that same click. The document scopes it explicitly — "This check covers the clicked conversions we can assess; it does not measure every ad click or every customer journey."

Where you fix it: the oppref parameter. OpenAI's guidance is to "preserve the oppref parameter when a person lands on your site from an ad, including through redirects and navigation," and, for server-side events, to "pass the click information from that person's journey into the server event." The parameter is documented across Conversion measurement, the Conversions API and the image tag.

Soku analysis: in practice this is a redirect problem far more often than a tagging problem. Consent walls, link shorteners, geo-routers and an https:// → https://www. canonical hop all strip query parameters unless someone deliberately made them not. The official advice to "test your full path, including tracking links, redirects, checkout, and any handoff between browser and server" is the whole fix. Also note the explicit prohibition: "Do not reuse another person's click information or substitute a default value."

3. Conversions API events are delayed

What OpenAI says it checks: whether server events arrived too long after the recorded action. The threshold is stated plainly — "The check looks for receipt within one hour of the action."

Where you fix it: your queueing and retry layer, not your tag. OpenAI's guidance is to send promptly, to check "scheduled uploads, queues, failed requests, and retry delays," and — critically — to "keep the original time of the action when retrying an event. Do not replace it with the upload time."

Soku analysis: the one-hour figure is the single most operationally useful number in the whole document, because it rules a common architecture out. If your conversions reach OpenAI through a nightly warehouse export or an hourly batch job that runs on the hour, you are structurally at or past the boundary. Anyone running a reverse-ETL pattern should read this warning as a design constraint rather than a tuning knob.

4. Conversion matches need review

What OpenAI says it checks: potential matches removed during attribution checks — "repeated callbacks for the same action, inconsistent timing, or too many matches linked to the same ad view." The document adds the reassurance that this "does not mean that the underlying business events were deleted or that every affected event was invalid."

Where you fix it: event IDs. "Use a consistent event ID for copies of the same action, including browser and server copies; use different IDs for distinct actions."

Soku analysis: this is the dedup contract. If you run the Pixel and the Conversions API together — which OpenAI encourages — the browser copy and the server copy of one purchase must share an event ID, or you have manufactured a duplicate rather than a redundancy.

5. Many conversions are linked to the same ad interaction

What OpenAI says it checks: whether assessable conversions are "unusually concentrated on some ad clicks or views." Notably, OpenAI declines to call this an error: "A customer can legitimately complete multiple actions after one interaction, so this warning alone does not prove duplicate events or invalid activity."

Where you fix it: the same event-ID discipline as above, plus firing stage. Look for "a page load, refresh, callback, or retry" that repeatedly sends the same business action.

Soku analysis: the document offers an escape hatch most scoring systems do not — if the concentration is real repeat-purchase behaviour, "retain those events and document the behavior when asking support to review the warning." Subscription and consumables businesses should expect to sit in this warning permanently and should not tune their tracking to clear it.

6. Limited additional matching information

What OpenAI says it checks: the presence of phone information, name and location information, and the combination of client IP address and user agent. The document draws the distinction explicitly: "It measures the presence of information, not whether a person was successfully matched."

Where you fix it: the expanded matching fields. The OpenAI advertiser product-update email of 2026-09-03 announced that the Pixel now supports hashed phone, first name, last name, region and postal code, and that the Conversions API supports plural list fields for hashed email, phone, external ID, first and last name, country, city, region and postal code, plus Android GAID for mobile — and both surfaces are documented, at Measurement Pixel and Conversions API. For server events, OpenAI's instruction is to "forward the real client's IP address and user agent when supported. Do not substitute your server's address or a generic user agent."

Soku analysis: the server IP substitution is the failure we would bet on. A Conversions API implementation written by a backend engineer without an explicit brief will send the request from a server, and the server's own address is the default value sitting right there. It populates the field, it passes code review, and it is exactly what the document tells you not to do.

7. Limited event types observed

What OpenAI says it checks: activity across three standard event groups — "browsing, intermediate actions, and completed outcomes." It hedges appropriately: "Different businesses have different journeys, and not every stage applies. This check does not verify that your entire funnel is complete."

Where you fix it: the supported events taxonomy. The important restriction is that custom events do not count for this check — "Use a supported standard event when it accurately represents the action. Custom events are not included in this particular breadth check." The standard names include page_viewed and contents_viewed for browsing, items_added, checkout_started and lead_created for intermediate actions, and order_created, trial_started, subscription_created and registration_completed for outcomes.

Soku analysis: this is the warning most likely to push a team into bad behaviour, and OpenAI pre-empts it in the document: "Do not create artificial funnel stages to clear a warning." If you are a lead-gen business with a two-step funnel, a permanent partial score on breadth is the correct outcome.

8. Limited Pixel and Conversions API activity

What OpenAI says it checks: whether enough accepted activity has been observed from the supported Pixel SDK or Conversions API channels. The line to internalise: "Installing an integration alone does not establish that events are arriving."

Where you fix it: verify requests are accepted and land on the intended data source, and when both channels report the same action, "use the same Pixel ID, event name, and event ID so copies can be recognized."

Soku analysis: OpenAI closes this section with a caveat worth quoting because it undercuts a common assumption: "Channel activity by itself does not verify correct pairing or complete event capture." Running both channels is not, in itself, evidence of a healthy setup.

9. Limited activity for a configured conversion goal

What OpenAI says it checks: at least one configured goal has very few or no received events in the window. Received events here "include events that were not matched to an ad" — so this is a firing check, not an attribution check.

Where you fix it: the goal configuration versus the event names your integration actually sends. Also, prune: "Review goals that are outdated or no longer represent actions you want to measure."

Soku analysis: the closing note matters for anyone with a genuinely low-volume conversion — "If the action is genuinely rare or recent demand is low, continue monitoring it. Low volume alone does not establish a setup defect." A B2B advertiser measuring signed contracts should not chase this one.

Four reasons the score is missing — and they are not the same reason

The section most likely to generate support tickets is the one explaining unavailability, because the four causes have four different responses and look identical in the UI. Paraphrasing the official text:

Status	What it means	What to do
No configured conversion goals	Nothing has been set up to measure	Configure the conversion actions, confirm the integration sends the matching events
Not enough conversion activity	Too little recent activity to produce a useful score — and OpenAI notes this "is different from a score of zero"	Verify the setup, then let real activity accumulate
Not enough attribution evidence	Events are arriving, but the observable connections to clicks or views are limited. "This does not mean that your business has no real conversions."	Work the `oppref` / click-information path
Data is still being processed	First assessment not ready, or latest assessment incomplete	Wait; contact support only if it persists

The document also states that a check lacking enough eligible events is not treated as a failure: "Missing information is not treated as a failed check, and it does not automatically produce an advertiser warning."

What we would actually do with this, in order

This section is Soku editorial, not documentation.

Fix oppref preservation first. It is the only warning whose failure mode is silent, total and invisible in your own analytics — your conversions still record perfectly, they just arrive unconnectable. Test the real path: ad → tracking link → consent wall → canonical redirect → checkout → server event.
Audit the one-hour Conversions API window second, because it is an architecture decision rather than a bug. If your pipeline cannot meet it, you need to know now, not after a quarter of degraded matching.
Fix identity stability third — one stable customer ID per person, hashed to spec, in both the browser and server implementations.
Then stop. Warnings 5, 7 and 9 are the ones where a real business legitimately sits in a permanent warning state. OpenAI says so in three separate places. Optimising them is how you end up sending events that do not correspond to business actions, which the document explicitly prohibits: "Do not send extra events, invent identifiers, or change event times to improve a score."

There is a real governance line in the article that deserves repeating in full, because it is the sentence a growth team under pressure will be tempted to ignore:

"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."

What Event Quality is not

It is not a bid signal. Nothing in the documentation states that the score is used in ranking, pricing or delivery.
It is not a forecast. OpenAI says directly that the score does not predict campaign performance.
It is not account-level. Do not average three data sources into one number for a status report.
It is not stable enough to read daily. A seven-day window with late-arrival allowance means day-over-day movement is mostly window mechanics.

Where this sits in the wider ChatGPT Ads measurement stack

Event Quality is a diagnostic layer over infrastructure that was already documented. If you are still assembling that infrastructure, the relevant primary sources are Conversion measurement, Measure results, the Measurement Pixel and Conversions API developer docs, and the supported events taxonomy. Our own walkthroughs of conversion tracking with user objects, identifier normalization and hashing and automatic advanced matching cover the implementation detail this article assumes.

If you are optimising toward conversions, the score also interacts with conversion-optimized oCPC campaigns — not because the documentation links the two, but because both depend on the same events arriving, on time, connectable to a click.

Sources

Every factual claim above traces to one of these, read on 2026-09-07:

Understand and improve event quality — the primary source for this article
Conversion measurement
Measure results
Measurement Pixel
Conversions API
Supported events
OpenAI advertiser product-update email, 2026-09-03 — cited only for the announcement of the expanded matching fields, which are themselves documented at the two developer-doc URLs above