Search Engine Land reported on September 4 that OpenAI has expanded the ChatGPT ad stack: new markets, a natural-language campaign plugin, a wider Custom Audiences API. The bigger change sits in older infrastructure: the ChatGPT Measurement Pixel’s user object now documents nine fields, and only five carry a SHA-256 hash. The other four are geography, travelling unhashed.
What Does the ChatGPT Measurement Pixel Collect?
The ChatGPT Measurement Pixel’s user object documents nine fields: five identity fields hashed with SHA-256 (email, phone, external ID, first name, last name) and four geography fields (country, city, region, postal code) with no hash suffix. OpenAI’s field table describes normalization only for those four, an ISO code, a character limit, lowercasing, not hashing.
Five Hashes, Four Plain Fields
The naming convention alone tells most of the story: five fields end in _sha256, and four do not.
| Field | Hashed? | What the docs say |
|---|---|---|
| email_sha256 | Yes | SHA-256 hash of the email address, trimmed and lowercased |
| phone_number_sha256 | Yes | SHA-256 hash of 8-15 digits, with a leading +, leading zeroes, whitespace, parentheses, periods and hyphens removed |
| external_id_sha256 | Yes | SHA-256 hash of a stable, pseudonymous customer identifier from your system |
| first_name_sha256 | Yes | SHA-256 hash of the lowercase first name, whitespace and ASCII punctuation removed |
| last_name_sha256 | Yes | SHA-256 hash of the lowercase last name, same rule |
| country | No | Two-letter ISO 3166-1 country code, such as US |
| city | No | City name, maximum 128 characters, trimmed and lowercased |
| region | No | State, province, or region, maximum 128 characters |
| postal_code | No | Postal or ZIP code: letters, numbers, spaces or hyphens, maximum 32 characters |
Search Engine Land described the addition as hashed customer information “including phone numbers, names, regions and postal codes.” Set against OpenAI’s table, that is half right: phone and name are hashed, region and postal code are not, their entries specify only a limit and format. The example payload sends exactly that unhashed: country “US”, city “San Francisco”, region “California”, postal code “94107”. The same page instructs advertisers: “Don’t send raw email addresses, phone numbers, external IDs, first names, or last names.” Geography is not on that list.
The pixel update ships alongside ChatGPT Ads reaching select countries across Europe, India, the Middle East and North Africa, per Search Engine Land, but that geography is not this story.
Hashed in the Browser Is a Claim About Transport, Not Scope
OpenAI documents a separate mechanism, automatic advanced matching, for sites that do not manually pass customer information:
“Automatic advanced matching improves website conversion measurement by helping match more conversions to your ads when a click identifier is unavailable. When enabled, the OpenAI Pixel automatically detects supported customer information from your website. The Pixel normalizes and securely hashes this information in the browser using SHA-256 before including it with conversion events. Raw customer information is not sent to OpenAI through automatic advanced matching. You do not need to manually pass customer information or make any changes to your Pixel implementation.”
Read that as a claim about transport, not scope. A SHA-256 digest of a phone number is stable: the same number always yields the same hash, the property that lets two parties match records without transmitting the number. That is hashing, not an accusation against OpenAI.
Trade reporting puts a date on the switch: automatic advanced matching became the default on already-installed web pixels on August 17, 2026, having already defaulted on for newly created ones, with opting out done from the pixel’s edit screen. The Pixel documentation gives no date. The field list grew underneath pixels that were already installed and already defaulted on.
The scope still matters: OpenAI’s line, raw customer information is not sent to OpenAI, applies only to automatic advanced matching. The four unhashed geography fields sit in the manually passed user object, a separate path with its own rules. OpenAI is not alone here: Meta enabled a similar off-site data feed by default, then removed a control.
Inclusion Needs 25,000 Users. Exclusion Needs None.
The Custom Audiences API treats list-building and exclusion as separate problems, with different eligibility rules. For inclusion and bid adjustments, OpenAI sets a planning threshold: “use 25,000 matched users as the public planning threshold. Privacy safeguards can affect the exact boundary, and uploading 25,000 identifiers doesn’t guarantee enough matched users.” For exclusion, there is no threshold: “Ready small or empty audiences can be used. No minimum matched size is required.”
A suppression list can be empty and still function. The floor guards who gets targeted, not who gets excluded.
The same update adds Google’s Advertising ID, GAID, as an accepted identifier. A chat product now takes a device identifier as a matching key, one that works without the customer’s email or phone number. European advertisers entering the new markets face a similar question for Google’s IP-based ad personalization in the EEA: what a default requires the advertiser to configure, not the platform.
An Impression Count Neither Source Defines
One more asymmetry sits in the same release. Search Engine Land reports that Ads Manager now shows impressions at the carousel-card level, and that OpenAI says those card impressions are separate from billable ad impressions. Neither that report nor the Pixel documentation says what makes an impression billable. The coming optimization model counts view-through conversions and bills by impression. Two counts, one surface: the one that charges is the one neither source defines, a shape this desk has documented before.
OpenAI’s Measurement Pixel documentation lists all nine fields. Search Engine Land’s report of September 4 covers the wider ad-stack update.