On August 17, 2026, OpenAI turns automatic advanced matching on by default for ChatGPT Ads web pixels created through the Ads API, retroactively including existing ones unless they were explicitly disabled or the ad account opted out. When enabled, the pixel detects customer information in website forms and sends an SHA-256 hash of it with conversion events. If you run ChatGPT Ads, you have until Sunday to decide whether that is what you want.
- What flips:
automatic_advanced_matching_enabledgoes from defaultfalseto default enabled for API-created web pixels - Retroactive: yes, for existing API-created web pixels, unless explicitly disabled or account opted out
- What it collects: supported customer information from website forms, hashed in-browser with SHA-256 before sending
- Off switch: pass
falseexplicitly per pixel via the Ads API - Consent default: the pixel initializes consent to true unless your consent tool explicitly denies it
- Scope: web pixels only; the Conversions API and image tag are unaffected
OpenAI pre-announced this one in its own Ads API changelog, dated August 17, 2026: new web pixels created through the Ads API will have automatic advanced matching enabled whenever the field is omitted, and the setting will be switched on for all existing API-created web pixels unless it was explicitly disabled or the ad account opted out. Trade coverage has reported the date. What has been missing is a technical account of what the feature actually does, what the pixel's consent machinery actually does, and what to change before Sunday. That is this post.
Everything below cites either OpenAI's developer documentation or the shipped pixel SDK itself, which we downloaded and read for this post. Where a claim comes from the SDK rather than the docs, we say so and pin the version.
A default is a decision made on your behalf. August 17 changes whose decision it is.
What is automatic advanced matching?
Automatic advanced matching exists to recover conversions that attribution would otherwise lose. OpenAI's Measurement Pixel documentation describes it as improving website conversion measurement by helping match more conversions to your ads when a click identifier is unavailable. The click identifier in question is oppref, the parameter ChatGPT appends to ad clicks; when cookie loss, redirects, or cross-device journeys break that chain, matching falls back to who the user is rather than which click they came from.
Mechanically, per the same documentation: when enabled, the pixel automatically detects supported customer information entered into website forms, normalizes it, and hashes it in the browser using SHA-256 before including it with conversion events. Raw customer information is not sent to OpenAI through automatic advanced matching, and no changes to your pixel implementation are needed. This is the same design Meta and Google use for their advanced matching features: the identifier leaves the page as a hash, and matching happens against hashes on the platform side.
Two boundaries worth stating precisely. It is a web pixel feature only: OpenAI's API reference states it is not available for other client types, so Conversions API events and the no-JavaScript image tag carry only what you explicitly pass them. And it is a matching feature, not a new event stream: it adds hashed identifiers to the conversion events your pixel already sends.
What exactly changes on August 17
The conversion setup API reference carries the change as a note on the pixel-creation endpoint, and it is two changes, not one:
- New pixels: "Beginning August 17, 2026, new Web pixels created through the Ads API have automatic advanced matching enabled when this field is omitted. Pass
falseexplicitly to disable it. Before August 17, the field defaults tofalse." - Existing pixels: "Also on August 17, OpenAI will enable automatic advanced matching for all existing Web pixels created through the Ads API, unless it was explicitly disabled or the ad account opted out."
The second bullet is the one that deserves your attention. This is not a change of default for future decisions; it is a retroactive flip of a setting on infrastructure you already run. If your pixel was created through the Ads API and nobody ever explicitly set automatic_advanced_matching_enabled to false, it turns on Sunday without any action from you.
One scope note, stated as precisely as the source allows: both changelog bullets cover pixels created through the Ads API. OpenAI's announcement does not state what happens to pixels provisioned through other surfaces, so if yours was created in the Ads Manager UI, check its setting there rather than assuming either way.
How the pixel's consent machinery actually works
The August 17 change lands differently depending on your consent setup, and this is where most coverage stops at the press release. The pixel's documented consent behavior is the place to start: OpenAI's docs state that the pixel initializes consent to true by default unless you set it to false or the pixel finds a stored denial. Consent is opt-out at the SDK level. A site that installs the pixel and never wires its consent banner to it runs fully consented, and after Sunday that includes hashed form-field identifiers on conversion events.
For this post we also downloaded and read the shipped SDK itself (oaiq.min.js v0.1.20, fetched August 12, 2026, SHA-256 7a6274b5…2720), so the following is verified against the exact bytes your visitors' browsers execute, as of that version. The consent gate in the shipped code treats only an explicit false as denial. When denial is set, the SDK drops measurement events before they are queued, and its own debug log says so plainly: "event dropped because consent is not granted". It purges any queued measurement events, and the denial handler clears the stored click identifier and browser reference. One class of traffic still flows under denial: anonymous diagnostic lifecycle pings, which the code sends with identifiers stripped and browser credentials omitted.
Read as a whole, that is a reasonable consent implementation with one sharp edge: everything hinges on your consent tool actually calling it. Denial genuinely stops measurement. But silence is treated as consent, and the burden of saying no sits with your integration, per OpenAI's own wiring pattern:
// Set consent BEFORE initializing the pixel.
oaiq("consent", false);
oaiq("init", {
pixelId: "<YOUR-PIXEL-ID>",
});
// Call this after the user grants measurement consent.
oaiq("consent", true);
// Note: events blocked while consent was denied are not replayed.If you advertise in the UK or the EU launch markets, the practical takeaway is not legal advice, it is a checklist item: confirm your consent platform calls oaiq("consent", false) for users who decline, before the pixel initializes, and review the advanced matching decision with your privacy team while the default still belongs to you. Attribution context lives alongside your UTM parameters and the oppref click identifier either way; advanced matching only changes what happens when those are missing.
What to do before August 17
1. Inventory your pixels
List the web pixels on your ad account through the Ads API and check each one's automatic_advanced_matching_enabled value. Anything created through the API that was never explicitly disabled will flip on Sunday.
2. Decide, and make the decision explicit
If you want advanced matching, do nothing on the pixel and spend the time on the consent check below instead. If you do not, pass an explicit false, because after August 17 omission means enabled on new API-created pixels:
curl -X POST https://api.ads.openai.com/v1/conversion_sources \
-H "Authorization: Bearer $ADS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Acme website",
"client_type": "web",
"automatic_advanced_matching_enabled": false
}'The changelog also references an ad-account-level opt-out. No public API surface for it is documented, so treat account-wide opt-outs as a conversation with OpenAI rather than a field you can set.
3. Verify your consent wiring, which matters more than the toggle
Load your site in a clean browser, decline consent in your banner, and confirm in the console (with debug: true) that the pixel logs dropped events rather than sending them. That single test verifies the entire chain that the August 17 change makes consequential.
4. Re-check after the flip
On or after August 17, re-read the field on your existing API-created pixels and confirm the state matches your decision. Retroactive changes are exactly the kind that quiet audits catch and assumptions miss.
Frequently Asked Questions
#What is automatic advanced matching in ChatGPT Ads?
Automatic advanced matching is a Measurement Pixel feature that improves conversion measurement when a click identifier is unavailable. When enabled, OpenAI's pixel automatically detects supported customer information entered into website forms, normalizes it, and hashes it in the browser with SHA-256 before including it with conversion events. OpenAI's documentation states that raw customer information is not sent through automatic advanced matching, and that no changes to your pixel implementation are needed.
#What changes for ChatGPT Ads pixels on August 17, 2026?
Two things, per OpenAI's dated API changelog. First, new Web pixels created through the Ads API get automatic advanced matching enabled whenever the automatic_advanced_matching_enabled field is omitted; before August 17 that field defaults to false. Second, OpenAI enables automatic advanced matching for all existing Web pixels created through the Ads API, unless it was explicitly disabled or the ad account opted out. The change is retroactive: doing nothing means existing API-created pixels flip on.
#How do I turn off automatic advanced matching for a ChatGPT Ads pixel?
Pass automatic_advanced_matching_enabled: false explicitly when creating or updating the pixel through the Ads API. After August 17, omitting the field on a new API-created web pixel means enabled, so an explicit false is the only reliable off switch at the pixel level. OpenAI's changelog also references an ad-account-level opt-out; no public API surface for it is documented, so account-wide opt-outs run through OpenAI directly.
#Does the ChatGPT Ads pixel respect consent by default?
The pixel has a consent feature, but you must wire it. OpenAI's documentation states the pixel initializes consent to true by default unless you set it to false or it finds a stored denial. In practice that means a site whose consent tool never calls oaiq('consent', false) runs the pixel as fully consented. When consent is denied, the pixel stops sending measurement events, and events blocked during denial are not replayed after consent is granted.
#Does automatic advanced matching send raw email addresses to OpenAI?
No, per OpenAI's documentation. The pixel normalizes and hashes detected customer information in the browser using SHA-256 before it is included with conversion events, and raw customer information is not sent to OpenAI through automatic advanced matching. Hashing in the browser is the same pattern Meta and Google use for advanced matching features. Whether hashed identifiers are acceptable under your consent posture is a question for your privacy team, not a technical setting.
#Does the August 17 change affect the Conversions API or the image tag?
No. OpenAI's API reference states automatic advanced matching is available only for web pixels, and the August 17 changelog entry covers Web pixels created through the Ads API. Server-side Conversions API events and the no-JavaScript image tag only carry the customer information you explicitly pass them, so nothing about their behavior changes automatically.
