Automatic advanced matching in ChatGPT Ads: what the pixel does
What automatic advanced matching does in the OpenAI Pixel, which fields are hashed, how it differs from manual matching, and the consent rules.
Published Sep 28, 2026 · 15 min read
What is automatic advanced matching in ChatGPT Ads?
Automatic advanced matching is a pixel feature that helps connect a website conversion to an ad when the click identifier is unavailable. OpenAI's help center describes it in those terms and shortens the name to AAM.
Three terms are worth defining before going further:
- Conversion event. An action you report to OpenAI, such as
order_createdorlead_created. - Click identifier. A reference called
opprefthat OpenAI appends to the landing page URL when someone clicks an ad. - Advanced matching. Sending eligible first-party information, normalized and hashed, together with the conversion event, so the event can still be connected to an ad when the click identifier is incomplete.
The automatic version removes the engineering step. OpenAI states that the pixel detects supported customer information "from recognizable forms and other sources" on your website, normalizes it, hashes it in the browser, and includes the result with conversion events. You do not pass the data yourself.
If the vocabulary is new, our ChatGPT Ads glossary covers the rest of the measurement terms.
Why do conversions lose their click identifier?
Conversions lose the click identifier because oppref lives in a URL and then in a browser cookie, and both are fragile. OpenAI lists four conditions for a conversion to be reported, and the last one is that OpenAI can connect the event to an eligible ad click using available measurement signals.
The pixel captures oppref from the landing page URL and stores it in a first-party cookie named __oppref. The developer guide gives the cookie lifetimes the pixel requests:
| Cookie | What it holds | Requested expiry |
|---|---|---|
__oppref | The click identifier from the landing page URL | 30 days after the pixel writes it |
__obref | A randomly generated browser reference for your website | 365 days after creation |
Two details matter. Each time the pixel captures a non-empty oppref parameter, it resets the __oppref expiry to 30 days, but reading the cookie on a later visit without the parameter does not extend it. And OpenAI notes that browser restrictions or clearing cookies can shorten these lifetimes.
The chain usually breaks in one of these places:
- A redirect or link shortener drops the query string before the landing page loads.
- The visitor returns in another browser or on another device, where the cookie does not exist.
- The browser restricts or clears the cookie before the visitor converts.
- The visitor declined measurement consent, so the pixel holds no cookies at all.
OpenAI's event quality page names the first case directly. One of its warnings is that ad click information is missing or cannot be connected, and the first fix it lists is to preserve the oppref parameter through redirects and navigation. Our guide to URL parameters explains how to keep query strings intact.
How does the pixel collect and hash the data?
The pixel finds supported customer information on the page, normalizes it, hashes it with SHA-256 in the browser, and attaches the hash to the conversion event. The raw value is not what travels.
The developer guide says the pixel "normalizes and securely hashes this information in the browser using SHA-256" before including it with conversion events. OpenAI adds that you do not need to manually pass customer information or make any changes to your pixel implementation.
What OpenAI does not publish, in the pages we reviewed, is the exact list of fields AAM looks for or the rules it uses to recognize a form. The documentation says "supported customer information" and stops there. Treat any more specific claim you read elsewhere as unverified, and check what your own pages send.
Hashing is not the same as anonymity in a legal sense. That is our judgment, not an OpenAI statement. A hashed email is still derived from personal data, and in many jurisdictions it is treated as such. Plan your disclosures on that basis.
Which fields does advanced matching accept?
The documented field list belongs to manual advanced matching, and it is the best available guide to what the system can use. For the pixel, the fields sit in an optional user object. OpenAI states that every field in it is optional and that you should include only the fields you have.
| Pixel field | Content | Hashed |
|---|---|---|
email_sha256 | Email address, trimmed and lowercased | Yes |
phone_number_sha256 | Phone number reduced to 8 to 15 digits | Yes |
external_id_sha256 | A stable, pseudonymous customer ID from your system | Yes |
first_name_sha256 | First name, lowercased, no whitespace or ASCII punctuation | Yes |
last_name_sha256 | Last name, same rules as first name | Yes |
country | Two-letter ISO 3166-1 code, such as US | No |
city | City name, maximum 128 characters | No |
region | State, province or region, maximum 128 characters | No |
postal_code | Letters, numbers, spaces or hyphens, maximum 32 characters | No |
The Conversions API accepts the same kinds of data under plural list names, such as emails_sha256 and phone_numbers_sha256. For each list, the API uses the first three valid, unique values in the order provided and ignores the rest without rejecting the event.
The server side also accepts three fields the pixel table does not list: ip_address, user_agent, and android_advertising_id. OpenAI states that the last one supports Android GAID only, and that IDFA is not supported.
How are values normalized before hashing?
Each identifier is cleaned to a fixed form, encoded as UTF-8, hashed with SHA-256, and sent as a lowercase, 64-character hexadecimal string. With AAM the pixel does this for you. With manual matching you do it, and a mistake here produces a hash that matches nothing.
| Identifier | Rule | OpenAI's example |
|---|---|---|
| Trim leading and trailing whitespace, convert to lowercase | Not given | |
| Phone | Keep the country calling code. Remove whitespace, parentheses, periods and hyphens, then a leading plus and leading zeroes | +1 (415) 555-2671 becomes 14155552671 |
| External ID | Trim whitespace. Preserve case and all other characters | Not given |
| Names | Lowercase, remove whitespace and ASCII punctuation, keep accents | O'Connor becomes oconnor |
Names keep their non-ASCII characters: OpenAI says not to strip accents or transliterate, so José becomes josé. And geographic values are sent as raw strings, not hashes.
OpenAI is explicit about what must never be sent raw: email addresses, phone numbers, external IDs, first names and last names.
How is automatic different from manual advanced matching?
Manual matching sends the fields you choose from code you wrote. Automatic matching sends what the pixel detects on the page. The data format is the same. The control is not.
| Manual | Automatic | |
|---|---|---|
| Who supplies the data | You, in code | The pixel detects it |
| Where | A user object in the pixel's init call, or the Conversions API | Recognizable forms and other sources on your website |
| Hashing | You normalize and hash before sending | The pixel normalizes and hashes in the browser |
| Code changes | Required | None |
Manual matching has one placement rule that is easy to miss. OpenAI states that user data is request-scoped in the pixel, so it goes into oaiq("init", ...) and not into individual oaiq("measure", ...) calls. If the data becomes available later, for example after login, you call init again with the complete user object.
Our view is that the two are complementary. Manual matching gives you control over exactly which fields are sent. Automatic matching covers the pages where nobody wired that up.
Does it work with the Conversions API or the image tag?
No. Automatic advanced matching is described only as behavior of the OpenAI Pixel in the browser. Server events and image tags need a different approach.
| Integration | Matching data | Click identifier |
|---|---|---|
| OpenAI Pixel | Manual user object, plus AAM when enabled | Captured and stored automatically |
| Conversions API | Manual user object on each event | You capture and pass oppref yourself |
| Image tag | No user object supported | You pass oppref only if your page already has it |
For the Conversions API, OpenAI states that the user object is event-scoped, so it goes inside each entry in events and not at the request root. The API does not capture oppref for you.
For the image tag, the limitation is stricter. OpenAI states that the image tag does not support a user object and warns against putting personal data, customer identifiers or order identifiers in any query parameter.
If you run the pixel and the Conversions API together, there is one more field to know. OpenAI's hybrid guidance is to read the __obref cookie in the browser, send it to your server, and include it unchanged as obref inside user. It is passed without hashing, and only where your consent requirements allow it.
Advertisers who send events through a platform should read our guide to measurement partners, since the partner decides which matching fields it forwards.
Is automatic advanced matching on by default, and where is the setting?
OpenAI's documentation treats AAM as something that is enabled per website pixel, but the pages we reviewed do not state a default or a menu path. The developer guide says "when automatic advanced matching is enabled", and the conversion campaign guidance tells advertisers to enable it for their website pixel.
We have seen specific switch-on dates and click paths quoted elsewhere. We could not confirm them in an OpenAI source we were able to open, so they are not repeated here.
What is documented is where pixels live. OpenAI states that you create a Pixel ID in the conversions tab of Ads Manager. That is the place to open your data source and check the state of the setting. If you manage several websites, check each data source separately, since OpenAI assesses each pixel or data source on its own.
Whatever the state is, decide it on purpose, and tell the person who owns your privacy policy.
What consent do you need before using it?
You need whatever consent your jurisdiction requires for collecting and sharing this data, and you need it before the pixel sends anything. OpenAI's help page is direct about responsibility. Conversion data should be shared only when permitted, after you have given users clear and comprehensive information about what you collect and obtained all necessary consents where required by law.
The pixel has a consent control for this:
- The pixel starts with consent set to true by default, unless you set it to false or it finds a stored denial.
- Calling
oaiq("consent", false)before init stops measurement-event pings. - Calling
oaiq("consent", true)after the user agrees allows future events. Events blocked earlier are not replayed. - Setting consent to false also removes both pixel cookies.
Do not confuse consent with the opt_out option on an event. OpenAI describes opt_out as a flag that opts the event out of future user-level personalization, and adds that it does not currently use pixel data for user-level personalization. It does not stop the event from being sent. Consent does.
If your site serves visitors in the EU, the UK or Israel, connect the consent call to your banner before relying on any matching feature. Your privacy policy should name the practice too. That is our recommendation, and it is not legal advice. Our guide to reporting and privacy covers what Ads Manager shows and what it does not.
Why does OpenAI recommend it for conversion campaigns?
OpenAI recommends it because it helps improve conversion matching and provides additional measurement signals for campaign optimization. That sentence appears in the optimization tips for the Conversion optimization objective.
The logic is straightforward. A conversion campaign learns from the conversions it can see. The same list of tips tells advertisers to use a conversion event with enough signal and to keep conversion tracking healthy, because incomplete tracking makes reporting and optimization less effective.
Conversions that happen but cannot be matched teach the campaign nothing, and they make the channel look weaker in your reports than it is.
No OpenAI page we reviewed gives a number for how much matching improves. We do not publish one either.
How does it affect event quality warnings?
Matching information is one of the things the event quality assessment checks. Event quality is a per-data-source assessment in Ads Manager. OpenAI states that it refreshes daily using seven complete calendar days.
Two warnings relate directly to advanced matching:
| Warning | What it checks |
|---|---|
| Limited email or customer ID information | Whether eligible conversion events carry an email or a stable customer identifier |
| Limited additional matching information | Phone, name and location information, and the combination of client IP address and user agent |
For the name and location check, OpenAI asks for first and last name, postal code and country for the same person.
Read these warnings with care. OpenAI states that the second check measures the presence of information, not whether a person was successfully matched. It also states that a score does not predict campaign performance or guarantee that a conversion will match to an ad.
There is a rule against gaming it as well. OpenAI tells advertisers not to send extra events, invent identifiers, or change event times to improve a score.
How do you check that it is working?
Check it in the browser first, then in Ads Manager, and give reporting time to catch up. OpenAI documents the tools. The order below is our suggestion.
- Turn on debug mode. The pixel's optional
debugsetting logs SDK activity to the browser console while you test. - Complete a real conversion. OpenAI's event quality guidance is to test through your normal customer journey and confirm that the expected fields are present.
- Test the refusal path. Decline consent and confirm that no measurement event is sent.
- Confirm receipt. API users can query recent events. OpenAI states that the endpoint returns a sample from roughly the last 15 minutes, and that browser events appear with the channel
pixel_sdk. - Wait for attribution. OpenAI asks advertisers to allow 24 to 48 hours for attributed conversions to appear in reporting.
- Watch event quality. Improvements can appear gradually as earlier events leave the assessment window.
If your site enforces a Content Security Policy, the pixel needs its sources allowed or nothing is sent at all. OpenAI lists https://bzrcdn.openai.com for loading the SDK and https://bzr.openai.com for sending events.
What should you check on your site?
Most matching problems we see come from setup, not from the feature. Go through this list once:
- The pixel is installed on the pages that hold your forms, not only on the thank-you page. OpenAI's advice is to install it across relevant pages.
- The consent call runs before the pixel initializes.
- Redirects and link shorteners keep the
opprefparameter, so matching stays a fallback and not the main route. - The pixel and the Conversions API send the same event ID for the same conversion, so OpenAI can deduplicate. OpenAI uses the first event it receives for a matching key and ignores later duplicates.
- Server events carry the real client IP address and user agent. OpenAI warns against substituting your server's address or a generic user agent.
- The same customer keeps the same identifier. OpenAI warns against reusing a shared, placeholder or default identifier for different people.
The same hashing rules apply when you upload customer lists for targeting. Our guide to custom audiences covers that side.
How does it relate to modeled measurement and attribution windows?
Advanced matching is one of three signals OpenAI names for connecting events to ads: the click reference, eligible advanced matching information, and modeled measurement where available.
Modeled measurement is different in kind. It uses aggregated patterns from observed conversions to estimate attribution for conversions that could not be matched. Reported totals may include modeled conversions. Advanced matching works on real, individual events. Modeling estimates the remainder.
Matching also does not extend the attribution window. An event still has to occur within the applicable window. In reporting, Ads Manager lets you choose a 7-, 14- or 30-day click-through window, and either 0 Day or a 1-day view-through window. OpenAI adds that cookie expiry is separate from attribution windows and from conversion-data retention.
Expect Ads Manager and your analytics tool to disagree. OpenAI lists the usual reasons: different attribution windows, time zones, consent conditions and deduplication. A difference is not proof of an error. Our conversion tracking guide explains how to compare the two.
Frequently asked questions
Does automatic advanced matching send raw email addresses to OpenAI?
No. OpenAI states that the pixel hashes the information in the browser using SHA-256 before including it with conversion events, and that raw customer information is not sent to OpenAI through automatic advanced matching.
Which fields does automatic advanced matching detect?
OpenAI does not publish a field list for the automatic feature in the pages we reviewed. It refers to supported customer information from recognizable forms and other sources. The documented list of email, phone, external ID, names and location fields belongs to manual matching.
Does it work for server-side events?
No. The feature is documented as pixel behavior in the browser. For the Conversions API you add a user object to each event yourself, with values normalized and hashed according to the developer guide.
Should I keep manual advanced matching if the automatic feature is on?
In our judgment, yes. Manual matching sends the fields you know are correct, and it is the only route for server events. OpenAI's own list of ways to improve measurement quality includes providing eligible advanced matching data when permitted and supported.
Does it respect my cookie banner?
It runs inside the pixel, and the pixel has a consent control. When consent is false, OpenAI states that the pixel does not send measurement-event pings. The link between your banner and that call is something you have to build and test.
Will it raise my reported conversions?
It can raise the number of conversions that are connected to an ad. It does not change how many people bought or signed up. OpenAI gives no figure for the effect, and its event quality page says no score guarantees matching, attribution or campaign results.
Does it help campaigns that optimize for clicks?
It helps their reporting. OpenAI states that clicks and impressions campaigns can track conversions without changing their objective, so better matching gives a clearer view of results. The optimization benefit applies to campaigns with the Conversion optimization objective.
If you would like this set up and tested for you, see our services or contact us.
Want it done for you? Lead handling for ChatGPT Ads: every lead in one inbox, marked real or not