OpenAI Pixel Consent Management Explained

On 24 August, ChatGPT ads will begin appearing across 31 European markets. With them comes OpenAI’s conversion pixel, which is likely to be added to a growing number of European websites.

For marketers, the setup will feel familiar. The OpenAI Pixel follows much the same model as Meta and Google: a browser-based SDK, standard conversion events, a server-side Conversions API, and deduplication between browser and server events.

It also includes a consent control. That sounds reassuring, but there is an important catch: unless you change the configuration, consent starts in the “on” position.

How OpenAI’s consent control works

The pixel provides a simple consent command. OpenAI expects you to set the visitor’s consent state before initialising the pixel, then update it when the visitor makes a choice:

oaiq("consent", false);

oaiq("init", {
   pixelId: "<YOUR-PIXEL-ID>",
});

// Call this after the user grants measurement consent.
oaiq("consent", true);

If you have worked with the Meta Pixel, the pattern should look familiar. Meta uses fbq('consent', 'revoke') before initialisation and fbq('consent', 'grant') afterwards. OpenAI uses booleans rather than strings, but the principle is effectively the same.

Unfortunately, so is the underlying problem.

The default works against EU consent requirements

According to OpenAI’s documentation, consent defaults to true unless you explicitly set it to false or the pixel detects a previously stored refusal.

That matters significantly on European websites.

If you add the pixel using the standard quickstart implementation and make no other changes, it will behave as though every visitor has already agreed to measurement. Conversion activity can therefore begin from the first pageview.

EU privacy rules generally require the opposite approach. Under the ePrivacy framework and GDPR, consent normally needs to be obtained before non-essential technologies store information on, or access information from, a visitor’s device.

In other words, the regulatory starting point is effectively “no”. The pixel’s technical starting point is “yes”.

OpenAI is hardly alone here. Meta and much of the advertising technology ecosystem operate in a similar way. But that only reinforces the practical lesson: the advertiser is responsible for making sure the implementation runs in the correct order.

There is another point worth examining.

OpenAI says that when consent is false, measurement-event requests are not sent, and events suppressed before consent are not retrospectively replayed once consent is granted.

What the documentation does not appear to promise is that the SDK itself will not load, or that nothing will be written to the visitor’s device.

The SDK is still served from OpenAI infrastructure. OpenAI also separately documents use of a first-party __oppref cookie for storing the oppref click reference so it can be reused on later pageviews.

For that reason, if your implementation relies solely on oaiq("consent", false), it is worth testing the actual pre-consent behaviour in the browser rather than assuming the consent flag prevents every form of storage or communication.

Automatic advanced matching is enabled by default as well

The OpenAI Pixel also supports advanced matching. This allows identifiers such as email address, phone number, name and external ID to be hashed and sent with conversion events, improving OpenAI’s ability to match conversions when a click identifier is unavailable.

You can supply these values explicitly through a user object. But OpenAI also provides automatic advanced matching, which is enabled by default on newly created web pixels.

When enabled, the pixel can identify supported customer information available on your site, normalise it, hash it using SHA-256 in the browser, and send the resulting hash with conversion events. No additional implementation is required.

OpenAI states that the underlying customer information is not transmitted in plaintext. That is clearly preferable to sending raw identifiers.

It does not, however, make the resulting data anonymous for GDPR purposes. Hashing is generally a form of pseudonymisation rather than anonymisation. A SHA-256 hash of an email address is deterministic: the same email address produces the same hash every time. A party that already possesses the email address can hash it independently and compare the result.

That matching capability is the whole purpose of the feature.

GDPR Recital 26 makes clear that pseudonymised information can remain personal data when it can still be attributed to an identifiable person using additional information.

So organisations should treat automatic advanced matching as a deliberate privacy decision. A feature that reads customer information from your website and sends derived identifiers to an advertising platform should have an appropriate lawful basis and should not simply be accepted because the default happens to be enabled.

Two ways to manage the OpenAI Pixel in Consent Studio

There are two practical approaches in Consent Studio. They provide different levels of control.

Level one: send the visitor’s consent state to the pixel

The simpler approach is to enable the OpenAI Pixel integration in Consent Studio Web CMP.

The visitor’s consent decision is then passed to the pixel in the correct sequence, so OpenAI is instructed not to perform measurement until the relevant consent has been granted.

For most organisations, this is a sensible baseline. It requires minimal implementation work, stays aligned with the visitor’s preferences, and updates automatically if those preferences change later.

There is still a dependency, however: you are relying on the OpenAI SDK to honour the consent state exactly as documented.

That means your compliance model depends in part on the behaviour of third-party code, including how that behaviour may evolve in future SDK releases.

Level two: prevent the pixel from loading before consent

A stricter implementation is to stop the OpenAI Pixel from loading altogether until the visitor has consented.

Before consent, there is no SDK request, no pixel execution and no opportunity for the tag to set cookies or communicate with OpenAI’s advertising infrastructure.

Once the visitor agrees, the tag is allowed to load.

In Consent Studio Launcher, our consent-native tag manager, this can be configured directly as part of the tag’s consent conditions.

The same principle can also be implemented in Google Tag Manager. Consent Studio can push custom events to the dataLayer, and the OpenAI Pixel tag can be configured to fire only when the appropriate consent event occurs.

From a compliance perspective, this gives you stronger control. Instead of depending on a third party to suppress activity correctly, you prevent its code from running until the necessary permission exists.

Practical implementation points

There are several details worth checking before putting the pixel into production.

Load order

OpenAI recommends placing the pixel high in the <head> so that early conversion activity is not missed. A consent-first implementation necessarily changes that behaviour. If you prevent the tag from loading before consent, measurement begins later by design.

That creates a measurement gap for visitors who have not yet made a consent choice. It is not an implementation failure; it is a consequence of choosing consent-first measurement. Marketing teams should understand that trade-off before launch.

Content Security Policy

Sites using CSP will need to allow OpenAI’s required domains. The pixel documentation specifies https://bzrcdn.openai.com for script-src and connect-src, together with https://bzr.openai.com for connect-src and img-src.

OpenAI also advises against adding unsafe-inline purely to support the pixel. A nonce or hash should be used instead.

Test the implementation yourself

Use a clean browser profile, visit the site, reject consent and inspect both the network requests and browser storage.

Confirm that the implementation behaves the way you expect before relying on it in production. Consent Studio Monitoring can help identify technical issues, but a direct browser check remains one of the quickest ways to catch an incorrect configuration.

Server-side tracking does not remove the consent question.

OpenAI’s Conversions API allows conversion events to be sent from your server, and browser and server events can be deduplicated using a shared event_id.

Moving an event server-side changes the technical route used to transmit it. It does not automatically provide a lawful basis for processing the personal data involved.

If a visitor has refused the consent on which the conversion measurement depends, sending the equivalent event through your server does not solve the underlying compliance issue.

The important part is making the choice deliberately

Both approaches can form part of a legitimate implementation.

Passing the visitor’s consent state to OpenAI is a practical baseline and can be enabled with very little work.

Preventing the pixel from loading until consent has been granted provides stronger technical control and may be more appropriate for organisations with a lower risk tolerance or operating in more closely scrutinised sectors.

What you should avoid is relying on OpenAI’s default.

If you want help deciding which approach is appropriate for your organisation, or would like another pair of eyes on an existing OpenAI Pixel implementation, get in touch. We are happy to review it with you.