Tracking ChatGPT ad conversions without mishandling customer data
What actually leaves your store, what hashing does and does not protect, and the difference between consent and opt out.
Every merchant I talk to about conversion tracking eventually asks some version of the same question: what is this actually sending about my customers?
It's a fair question and it usually gets a vague answer. So here is the specific one — what leaves your store, what form it's in, and the two controls that decide whether anything is sent at all.
What actually gets sent#
A conversion event carries two kinds of information: what was bought, and signals to match the purchase to someone who saw your ad.
The purchase side is unremarkable — an amount, a currency, the products. Nothing personal.
The matching side is where the questions are. ChatGPT Ads accepts these identifiers, and the field names tell you the story:
emails_sha256phone_numbers_sha256external_ids_sha256first_names_sha256,last_names_sha256
Every one ends in sha256, meaning the value must be hashed before it's sent. You send a fingerprint, not the address.
A few fields are sent as plain values because hashing them would be pointless: countries, cities, regions, postal_codes, plus ip_address and user_agent. These are coarse — a city and a postal code, not a street.
What hashing does and doesn't do#
Worth being precise here, because "it's hashed" gets used as though it settles the matter.
SHA-256 turns alice@example.com into a fixed string of characters. The process only runs one way: you cannot reverse the string back into the address. Two systems that hash the same address get the same result, which is what makes matching possible without either side transmitting the address itself.
What it does not do is make the data anonymous in a legal sense. A hashed email still identifies one specific person — anyone holding the same address can hash it and confirm the match. Under GDPR this is pseudonymised data, not anonymous data, and it stays personal data with all the obligations that carries.
So hashing is a genuine and worthwhile protection. It is not a reason to skip consent, and anyone who tells you otherwise is wrong about the law.
The two controls, and why they're different#
This is the part almost everyone conflates, and the distinction matters.
Consent decides whether anything is sent. When consent is false, the pixel doesn't send measurement events at all.
Opt-out is a flag on an event that is sent. The event goes through and is recorded for measurement, but is excluded from future user-level personalization — it won't feed targeting.
In plain terms: consent-false means you don't count the sale. Opt-out means you count the sale but don't use it to profile anyone.
That difference is worth understanding, because they map to different things a shopper might be declining. Someone refusing all tracking is the first case. Someone happy to be counted but not profiled is the second — and in that case you keep your conversion data.
The timing detail that catches people out#
One behaviour is easy to get wrong: events blocked by consent are not replayed.
If someone lands on your store, browses, and then accepts your consent banner at checkout, everything before that acceptance is gone. It wasn't queued waiting for permission. It was dropped.
This has a practical consequence. If your banner appears late, or your tracking initialises before your consent platform has told it what the shopper chose, you will silently lose events from visitors who did consent. That looks identical to a broken pixel.
The pixel also remembers a stored denial — a shopper who declined isn't asked again on the next page, and events stay blocked. That's correct behaviour, and worth knowing when you're testing: if your test browser previously declined, you'll see nothing and may assume something is broken.
What I'd actually do#
Gate tracking on consent, properly. Not as a checkbox exercise. The pixel should be told the shopper's choice before it sends anything, and told again when that choice changes.
Send the minimum that works. Every identifier is optional. If a hashed email is enough to match your conversions, you don't need to add phone numbers and names because the field exists.
Never hash in the browser if you can hash on your server. Hashing in the browser means the raw value was in the page first, where extensions and scripts can read it. Server-side, the raw value never leaves your backend.
Don't store what you don't need. The strongest position is having nothing to disclose in the first place. The app I build hashes identifiers in memory, forwards them, and writes no customer data to disk at all — which makes a data request from a customer straightforward to answer.
Write it down. Your privacy policy should name what's collected, that identifiers are hashed before transmission, that data goes to OpenAI for measurement, and how someone requests erasure. If you sell into the EU or UK you need this anyway.
The question to ask your tracking app#
If you use an app rather than building this yourself, ask one thing: does it store customer data, and where?
There's a real difference between an app that forwards hashed identifiers and retains nothing, and one that keeps a copy of your customer list on its own servers. Both may describe themselves as privacy-friendly. Only one of them leaves you with nothing to breach.
You're the data controller here. Your customers' data is your responsibility regardless of which app you installed, so it's worth ten minutes reading what the app you chose actually does with it.
I build LLM Pixels, a Shopify app for ChatGPT Ads conversion tracking. It gates on consent, hashes identifiers before they leave the server, and stores no customer data.