OpenAI Ads looks at the identity fields of the event’s user object to bind a conversion to the right ad interaction. The more complete these fields, the stronger the match, but the design is privacy-first: personal identifiers are hashed before they leave the browser or the server. Under GDPR and KVKK this distinction matters, because hashing masks the data but does not on its own stop it from being personal data. This post explains the identity matching fields, the hashing rules, and the oppref and opt_out fields.
The technical sections below are framed in a consent-neutral context; they describe how the fields are sent, not which legal basis applies. The legal basis and disclosure are a decision separate from the setup.
Why Identity Matching Exists
Matching an ad click to a conversion that happens later gets harder as cookie and browser restrictions grow. The fields in the user object close that gap: email, external ID, and geographic signals give extra matching material to connect a conversion to a user. All fields are optional and only what you have is sent; more fields mean a higher match probability, but none are required.
user Object Fields
The user object is carried inside the event and splits into two groups: fields sent hashed and fields sent raw1.
| Field | How sent | Description |
|---|---|---|
email_sha256 | Hash (SHA-256) | Email; hashed after trimming whitespace and lowercasing |
external_id_sha256 | Hash (SHA-256) | Hash of a stable, pseudonymous customer identifier from your system |
country | Raw | Two-letter ISO 3166-1 country code (US, etc.) |
city | Raw | Max 128 characters; OpenAI trims whitespace and lowercases |
zip_code | Raw | Letters, numbers, spaces, or hyphens; max 32 characters |
ip_address | Raw | Valid IPv4 or IPv6 address |
user_agent | Raw | Non-empty user-agent string from the client |
Geographic fields, IP, and user-agent are sent raw; email and external ID are sent only in hashed form.
Hashing Rules
Hashing follows a single format: hashes are sent as lowercase, 64-character hexadecimal strings1. For email the order is fixed: first trim whitespace, then lowercase, then take the SHA-256. If this normalization is skipped, two spellings of the same person (JohnDoe@Example.com and johndoe@example.com) produce different hashes and the match is lost.
Raw email addresses, raw external IDs, phone numbers, and phone number hashes are never sent1. Even a hash of the phone is not accepted; this field is entirely out of scope.
oppref and opt_out
Two fields relate directly to privacy1:
oppref: a privacy-preserving identifier provided by OpenAI. The pixel captures it automatically from the landing page URL; the Conversions API does not capture it automatically and carries it manually when available.opt_out: when set totrue, the event is kept out of future user-level personalization. Its default value isfalse.
opt_out is the way to carry a user preference at the event level: depending on consent state, sending this field as true includes the conversion in measurement while keeping it out of personalization.
Hashing Is Not Anonymization
There is a common conceptual mistake here. Hashing an email with SHA-256 makes it unreadable, but it does not make the data anonymous. Because the same email always produces the same hash, the hash is a stable identifier that serves to match a user across sources; under GDPR and KVKK, this is pseudonymous rather than anonymous data. The practical consequence: the personal-data regime still applies, so the legal basis, disclosure, and retention obligations do not disappear with hashing.
This is not something that prevents you from sending identity fields; it is only a warning that the assumption “we hashed it, so it is no longer personal data” is wrong.
Privacy-friendly design, not an exemption
OpenAI Ads’s hash-based identity model aims to match without sending raw PII to the platform, and that is a good default. But privacy-friendly design does not mean exemption from legal obligation. Which fields are sent under which legal basis is a separate assessment, independent of the setup.
Next Steps
Once the identity fields and privacy rules are clear, the next step is how these fields are sent in practice over the pixel and the Conversions API, and how they compare with the identity models of other platforms. Hash-based matching is not unique to OpenAI Ads; a similar logic runs on the Meta and Google sides too.
Footnotes
-
Conversions API (OpenAI Developers) — the
userobject fields and hashing requirements (email_sha256 “SHA-256 hash of the email address after trimming whitespace and converting it to lowercase”; external_id_sha256; country/city/zip_code/ip_address/user_agent raw), the hash format (“Send hashes as lowercase, 64-character hexadecimal strings.”), the raw-data prohibition (“Don’t send raw email addresses, raw external IDs, phone numbers, or phone number hashes.”), geographic/IP/user-agent raw (“Send the geographic, IP address, and user agent fields as raw values.”), oppref (“OpenAI-provided privacy-preserving identifier”, not captured automatically by the Conversions API), opt_out (“Set totrueto opt out the event from future user-level personalization. Defaults tofalse.”). ↩ ↩2 ↩3 ↩4
- 01 Identity matching fields are carried in the event's user object; all are optional, send only what you have.
- 02 Email and external ID are hashed with SHA-256 and sent as lowercase 64-character hexadecimal strings; raw email, external ID, and phone are never sent.
- 03 Geographic data (country, city, zip_code), IP, and user-agent are sent raw, not hashed.
- 04 oppref is OpenAI's privacy-preserving identifier; the pixel captures it automatically, the Conversions API carries it manually. opt_out true keeps the event out of personalization (default false).
- 05 Hashing masks the identity but, under GDPR/KVKK, the data counts as pseudonymous rather than anonymous; the personal-data regime still applies.
+ Which fields does OpenAI Ads use for identity matching?
The event's user object can carry these fields: email_sha256, external_id_sha256, country, city, zip_code, ip_address, and user_agent. All are optional; send only what you have. Email and external ID are hashed; geographic fields, IP, and user-agent are sent raw.
+ How is the email hashed?
The email is hashed with SHA-256 after trimming whitespace and converting to lowercase, then sent as a lowercase, 64-character hexadecimal string. Raw email is never sent; the same rule applies to raw external IDs, phone numbers, and phone hashes.
+ What do oppref and opt_out do?
oppref is a privacy-preserving identifier provided by OpenAI; the pixel captures it automatically, while the Conversions API carries it manually. When opt_out is set to true, that event is kept out of future user-level personalization; its default value is false.
+ Is a hashed email personal data under GDPR and KVKK?
SHA-256 hashing masks the identity but does not make the data anonymous. Under GDPR and KVKK, a hashed identifier is generally treated as pseudonymous data and the personal-data regime still applies. This means the legal basis and disclosure obligations do not disappear with hashing.