Automatic Advanced Matching in ChatGPT Ads: what changes on August 17, 2026

Tarun Kapoor Published August 7, 2026 12 min read

Automatic Advanced Matching (AAM) lets the ChatGPT Ads Web pixel read customer information your visitors type into your own website forms, hash it in the browser, and send it with the conversion event so OpenAI can match more conversions back to ad interactions. It is already the default for newly created Web pixels, and OpenAI will enable it on existing Web pixels on August 17, 2026. If you want it off, you have to opt out before that date. This guide covers what AAM does, how it differs from the manual user object you may already be sending, the exact opt-out path, and how to decide.

What changes on August 17, 2026

Two things are happening, and it helps to keep them separate. First, AAM became the default for new Web pixels — any pixel you create now ships with it enabled. Second, on August 17, 2026, OpenAI extends that default backwards to existing Web pixels. Accounts that installed the pixel earlier in the year and have never touched the setting will find it switched on that day.

For most advertisers this is a straightforward improvement — higher match rates mean more of the conversions you are already generating get credited to the campaigns that generated them. But it is a change in what data leaves your website, which means it belongs in front of whoever owns privacy review at your company before it happens rather than after. The window to make that decision on your own terms closes on the 17th.

What Automatic Advanced Matching actually is

Conversion attribution is a matching problem. Somebody has a conversation in ChatGPT, clicks a sponsored result, lands on your site, wanders off, comes back two days later on a different device, and buys. For OpenAI to credit that purchase to the ad, it needs a durable way to recognise that the buyer and the clicker are the same person.

The primary mechanism is oppref, the privacy-preserving identifier OpenAI appends to your landing page URL, which the pixel stores in a first-party cookie called __oppref. That works well inside a single browser session and reasonably well across sessions on the same device. It works less well across devices, across browsers, and after cookie expiry — which is exactly where a meaningful share of real conversions live.

Advanced matching fills that gap with customer information. If the same hashed email address appears on both an ad interaction and a conversion, the two can be connected even when the cookie is gone. Automatic Advanced Matching is the version where the pixel does the collection for you: rather than requiring your developers to locate the customer's email in your application state and pass it explicitly, the pixel reads values customers enter into forms on your site, hashes them in the browser, and includes them with the event.

The practical effect is more attributed conversions from the same real-world performance. Nothing about your actual sales changes; what changes is how many of them ChatGPT Ads can see and therefore how well conversion-optimized (oCPC) bidding can learn. On an account where the auction is trying to bias delivery toward converting clicks, feeding it a more complete conversion signal is one of the highest-leverage things you can do.

How the pixel collects form data

AAM operates on the forms already present in your pages. When a visitor submits information — typically during checkout, lead capture, or account creation — the pixel identifies eligible customer fields, normalises them, hashes them with SHA-256 in the browser, and attaches the resulting digests to the conversion event.

The hashing happens client-side, before transmission. That is the important architectural detail: the raw email address is not sent to OpenAI and then hashed at the other end — it is hashed on the visitor's own device, and only the digest travels. This is the same normalisation contract described in our identity and hashing section: trim whitespace, lowercase, SHA-256, render as lowercase 64-character hexadecimal.

OpenAI has not published an exhaustive list of every field AAM will attempt to detect, and the detection logic may evolve during the rollout. Treat the field coverage as "email address and similar customer identifiers entered into forms" rather than assuming a fixed schema, and verify what is actually being sent on your own site using the QA steps below rather than trusting a documented list.

AAM vs manual advanced matching

If you already pass a user object into oaiq("init", …) or into your Conversions API payloads, you are doing manual advanced matching. AAM does not replace that — it covers the cases your manual implementation misses.

The strongest configuration is both. Keep sending an explicit, correctly-normalised email_sha256 where you control the data — that is the highest-quality signal you have — and let AAM catch the surfaces nobody got around to instrumenting. Where both produce a value for the same conversion, you are supplying corroborating identity rather than conflicting identity.

One caution worth stating plainly: AAM is a Web pixel feature. It does nothing for server-side events sent through the Conversions API, and it does nothing for the image-tag fallback. If your measurement is primarily server-side, this change affects less of your stack than the announcement implies — but it still affects the browser events you send alongside it, and your deduplication should be verified after it turns on.

How to opt out

The setting lives inside the pixel's own configuration, not in account-level privacy preferences. In Ads Manager:

1. Open Tools.
2. Go to Conversions.
3. Select Data Source.
4. Choose Edit pixel on the Web pixel you want to change.
5. Turn Automatic Advanced Matching off, and save.

Do this before August 17, 2026 if you do not want it enabled on an existing pixel. The setting is per-pixel, so an account running several pixels across several properties needs the change applied to each one — check the full list rather than assuming a single toggle covers the account.

Opting out is reversible, and so is opting back in. If your privacy review is not going to conclude before the 17th, the defensible sequence is to opt out now, finish the review, and enable it deliberately afterwards. That is a better position than discovering an unreviewed data flow went live because nobody owned the deadline.

Should you leave it on? A decision framework

There is no universally correct answer here, but the decision usually resolves cleanly once you ask three questions in order.

1. Do your forms collect data you are contractually or legally restricted from sharing? Health, financial, and children's data attract specific obligations, and some enterprise contracts restrict onward disclosure of customer identifiers regardless of hashing. If yes, opt out and route the decision to counsel. Hashing reduces exposure; it does not automatically discharge an obligation.

2. Does your consent management platform gate the pixel correctly today? AAM inherits whatever consent posture your pixel already has. If your CMP genuinely blocks oaiq until consent is granted, AAM cannot collect anything pre-consent. If your consent gating is aspirational rather than verified, fix that first — the exposure existed before this change and AAM widens it.

3. Are you running or planning conversion-optimized bidding? If yes, the argument for leaving AAM on is strong. oCPC learns from conversion volume, and thin conversion signal is the single most common reason a conversion campaign fails to leave the learning phase or underspends its budget. More matched conversions is directly more signal.

For most direct-response advertisers running standard ecommerce or lead-generation forms with working consent management, leaving AAM enabled is the reasonable default — provided the decision is made knowingly. The failure mode this guide exists to prevent is not "AAM is on", it is "AAM is on and nobody in the company knew it happened".

Consent, privacy, and the review nobody schedules

Bring three people into the decision before the 17th: whoever owns your privacy policy, whoever owns your consent management platform, and whoever owns the pixel implementation. In practice these are often three different people who have never been in the same conversation about this pixel.

The concrete artefacts to check: your privacy policy's description of what advertising partners receive should be accurate once AAM is on; your processing records should reflect the change; and your consent gating should be verified against the reject path, not just the accept path. Our consent and CSP section covers the mechanics of gating oaiq correctly.

Note also that consent gating and the event-level opt_out flag are different controls solving different problems. opt_out excludes an event from future personalization while still counting it; consent gating prevents collection entirely. Do not substitute one for the other when documenting your posture.

Verifying AAM is actually working

Once enabled, confirm behaviour on your own site rather than assuming the setting took effect.

• Open the network panel, filter to bzr.openai.com, and submit a real test form.
• Inspect the outgoing event payload. You should see hashed identity values present that you did not pass explicitly in code.
• Confirm every value is a lowercase 64-character hex string. Anything that looks like a raw email address in a payload is a defect — stop and escalate.
• Run the reject path of your consent banner and confirm no event fires at all.
• Check the Pixel validation diagnostics panel in Ads Manager (Tools → Conversions, diagnostics panel on the right) for newly dropped events, the affected field, and the recommended fix.
• After a week, compare matched conversion counts against the prior week and against your own order or lead counts for the same window.

That last step is the one people skip and the one that pays. If matched conversions rise while your internal counts hold steady, AAM is doing its job. If both rise together, something else changed and you should find out what before attributing the lift to this feature.

Failure modes worth pre-empting

• Double-hashing. If your form already contains a pre-hashed value in a hidden field, AAM detecting and hashing it again produces a digest that matches nothing. Audit hidden fields on high-value forms.
• Internal traffic. Staff submitting test forms on production adds noise to matching. Exclude internal traffic before, not after.
• Assuming server-side coverage. AAM does not touch Conversions API events. Teams that measure server-side sometimes conclude the change does not affect them and stop reading — it still affects the browser leg and therefore deduplication.
• Silent per-pixel drift. Multi-property accounts opt one pixel out, forget the others, and end up with an inconsistent posture that is hard to describe accurately in a privacy review.
• Treating the deadline as a suggestion. After the 17th the setting still exists and can still be turned off — but by then the flow has already gone live, which is a materially worse position to explain internally.

Automatic Advanced Matching: frequently asked questions

Sources and further reading

• OpenAI Help Center — Conversion measurement: automatic advanced matching (AAM behaviour, default status, and the opt-out path).
• OpenAI Help Center — Measure results (reporting columns and how conversions are counted).
• OpenAI Developers — Conversion-optimized campaigns (why conversion signal quality governs oCPC delivery).
• Context Hints — ChatGPT Ads conversion tracking (the pixel, the Conversions API, hashing rules, and deduplication).

Tarun Kapoor

Founder & CEO, Context Hints

Twelve years of media buying across GroupM, WPP, Ogilvy & Mather, and Neil Patel Digital. Has personally owned media for Nestlé, Sage, Qualcomm, Aetna, Weight Watchers, Chubb and Novotel.