On June 17, 2026, OpenAI shipped a quiet but consequential change to ChatGPT Ads measurement: conversion tracking is being updated to use provided user objects to more accurately match conversions. In OpenAI's own framing, "some advertisers may see a meaningful increase in reported conversions as a result." That is not a reporting cosmetic — a higher match rate means the platform finally sees conversions it was previously dropping on the floor, and every automated bidding decision downstream gets a cleaner signal to learn from.
If you run paid media, this is the kind of update you want to act on the day it lands. For the complete overview of building on this channel, see How to Start an AI Ads Agency. This post is the focused how-to: what conversion matching actually is, why user objects raise match rates, why that matters more now that optimization is automated, and exactly how to implement and verify them.
What "conversion matching" means
A conversion event by itself is just a record that something happened — a purchase, a signup, a qualified lead, with a value and a currency. Matching is the step where the ad platform decides which click, and which person, that conversion belongs to. Get the match right and the conversion is attributed and counted; get it wrong, or fail to match at all, and the conversion silently disappears from your reporting.
Historically, platforms leaned on browser signals — cookies, click identifiers carried in the URL — to make that match. Post-cookie, those signals are lossy: ad blockers, Intelligent Tracking Prevention, cross-device journeys, and short cookie lifetimes all break the thread between a click and a later conversion. The industry's answer, now standard across every major platform, is to stop relying on the browser alone and instead send first-party identifiers you already hold — the customer's email, phone, name — along with the conversion event itself, so the platform can match on identity rather than on a fragile cookie.
That bundle of identifiers is the user object.
What a user object is
A user object is the set of customer information you attach to a conversion event so the platform can match it to a known user. The identifiers are hashed before they leave your server — you never send raw email or phone numbers — and the platform compares your hashes against its own hashes of signed-in users. If they match, the conversion is credited.
This is not a novel ChatGPT-only invention. It is the same pattern two of the most-documented measurement systems on the web already use, which is why it is safe to implement against their well-established rules:
- Meta's Conversions API accepts customer-information parameters such as
em(email),ph(phone),fn/ln(name) and more, and Meta states that "supplying multiple identifiers increases the chances of accurately matching" a conversion to a user. See Meta's customer information parameters documentation. - Google's enhanced conversions sends "hashed first party conversion data" — email, phone, name, home address — and matches it "against Google logged-in user data" to report a conversion. See Google's enhanced conversions overview.
OpenAI's user-object update brings ChatGPT Ads onto the same footing. Read OpenAI's documentation for the channel-specific field names, but the concept transfers directly: send hashed identifiers with your conversions and your match rate goes up.
Why this matters more now: optimization is only as good as the signal
Here is the part operators underrate. Ad platforms have moved almost entirely to automated optimization — Meta's Advantage+, Google's AI Max and Smart Bidding, and ChatGPT Ads' own machine-driven delivery. You no longer hand-tune bids per keyword or audience; you hand the platform a conversion signal and it optimizes toward it.
That makes the conversion signal the single most leveraged input in the whole system. If 30% of your real conversions never match, the optimizer is not just under-reporting — it is learning from a biased, incomplete picture of who converts. It will misjudge which clicks are valuable, bid wrong, and steer budget toward the wrong audiences, and it will do all of this confidently because it cannot see the conversions it missed.
Improving match rate with user objects fixes the problem at its root. A higher-fidelity conversion signal means:
- More conversions reported — the immediate, visible effect OpenAI flags.
- Better bidding — the optimizer trains on a truer sample of converters, so its value predictions improve.
- Fairer channel comparison — a channel suppressed by a low match rate looks artificially expensive; restore the match and its real CPA emerges.
In a world of automated delivery, conversion-data quality is the optimization lever. You are not tuning the algorithm; you are feeding it.
How to implement user objects
The mechanics are the same wherever you send conversions. Four steps.
1. Send conversions server-side
User objects belong on server-side conversion events, sent from your backend, not scraped from the browser. Your server is where the real order lives — the confirmed purchase, the true value, and the customer's actual email and phone. Server-side reporting is also immune to ad blockers and browser-storage limits, which is exactly the lossiness you are trying to escape. The browser pixel still has a job (capturing click context on landing), but the conversion with its user object should come from your server, joined to the pixel by a shared event_id.
2. Collect the right identifiers
Send as many strong identifiers as you legitimately hold. Both Meta and Google are explicit that multiple identifiers raise match quality, because any single one might not match while another does. In priority order:
- Email — the highest-value identifier; almost every conversion has one.
- Phone — strong, especially for lead-gen and commerce.
- Name + postal address — useful supplements that help disambiguate.
3. Normalize, then hash with SHA-256
This is where match rates are won or lost. Normalize before you hash, because the platform hashes its copy the same way — if your normalization differs by a single character, the hashes will never match. The rules below are Google's documented formatting requirements for enhanced conversions; Meta's are equivalent.
| Field | Normalize | Then |
|---|---|---|
Trim whitespace, lowercase; for gmail.com/googlemail.com remove dots before the @ | SHA-256, hex | |
| Phone | E.164 format: + country code, digits only, no spaces or dashes (e.g. +11231234567) | SHA-256, hex |
| Name | Trim whitespace, lowercase | SHA-256, hex |
A correctly hashed value is a 64-character hex string, for example a8af8341993604f29cd4e0e5a5a4b5d48c575436c38b28abbfd7d481f345d5db. A practical normalize-then-hash sketch:
import hashlib
def normalize_email(email: str) -> str:
email = email.strip().lower()
local, _, domain = email.partition("@")
if domain in ("gmail.com", "googlemail.com"):
local = local.replace(".", "")
return f"{local}@{domain}"
def sha256_hex(value: str) -> str:
return hashlib.sha256(value.encode("utf-8")).hexdigest()
user_object = {
"email": sha256_hex(normalize_email("[email protected]")),
"phone": sha256_hex("+11231234567"), # already E.164
}A few rules that prevent silent failures:
- Hash identity fields, but never hash technical fields. IP address, user agent, and click identifiers are sent raw — they are matching aids, not PII you are protecting.
- Send a stable
event_idso the server event deduplicates against the browser pixel and you do not double-count. - Be consistent across all events. The same email, normalized the same way, must produce the same hash every time, or you fragment your own match.
4. Attach the user object to every conversion event
Once you have the hashed user object, attach it to each server-side conversion you report to ChatGPT Ads, alongside value, currency, and event_id. Do this for every conversion type that matters — purchase, signup, qualified lead — not just the headline one.
Privacy and hashing best practice
User objects are a privacy-forward design when done right, and a liability when done carelessly.
- SHA-256 is one-way. Google describes it as a "secure one-way hashing algorithm" and Meta requires SHA-256 on all customer-information parameters. The platform never receives a raw email or phone — only a fingerprint it can compare against its own.
- Hash on your server, before transmission. Raw PII should never touch the browser or transit the wire. Normalize and hash inside your backend.
- Only send identifiers you are permitted to use. A user object is built from first-party data you collected with a lawful basis and appropriate consent. Honor your consent signals; do not send identifiers for users who opted out of measurement.
- Don't over-collect. You need email (and ideally phone) to win most of the match. Sending more fields than you legitimately hold adds risk, not match rate.
Done this way, you improve measurement without exposing a single customer's raw contact details to the ad platform.
How to verify match quality
Implementing user objects is not done until you can see them working. Borrow the verification habits from the mature platforms:
- Watch reported conversions before and after. OpenAI's own note — "a meaningful increase in reported conversions" — is your headline metric. If you flip on user objects and matched conversions do not move, your normalization or hashing is almost certainly off.
- Confirm events are received and matched, not just sent. Check that your server events arrive, carry the user object, and are being matched rather than rejected. Meta exposes this as an Event Match Quality score; expect ChatGPT Ads' diagnostics to surface an equivalent signal.
- Spot-check your hashes. Take one real, normalized email, hash it locally, and confirm it is the expected 64-character hex string. A common bug is hashing the raw value before normalizing — which produces a hash the platform will never match.
- Reconcile against your own backend. Your database knows exactly how many purchases happened. The gap between that and matched conversions is your remaining match loss — chase it down with more identifiers or cleaner normalization.
The operator angle: clean data before you scale spend
For an AI ads agency, this update is a reminder of an order of operations that is easy to get wrong: wire clean conversion data before you scale spend, not after. Every dollar you pour into an automated channel is optimized against the conversion signal you provide. Scale spend on a broken or low-match signal and you scale the algorithm's mistakes — you buy more of the wrong clicks, faster, and the reporting looks fine until you reconcile against revenue.
The discipline that separates a scalable agency from a fragile one is making clean conversion data the first thing wired on every client account, and keeping it identical across all of them. That is hard to do by hand across a portfolio: every client has a different stack, a different way of storing customer data, and a different idea of what "a conversion" is. This is exactly the standardization an agent is built for. Soku provisions the pixel, sends hashed user objects with every server-side conversion, and applies one consistent normalization-and-hashing pipeline across every account — so match quality is high and comparable from the first dollar, and the day OpenAI ships a change like this, it is already live everywhere.
That standardized foundation is what makes the rest of the playbook work — the same conversion discipline underpins running ChatGPT Ads as an agency, launching product-feed campaigns, and choosing the right AI ads agency tech stack.
FAQ
What is a user object in ChatGPT Ads?
It is the set of customer identifiers — hashed email, phone, name — you attach to a conversion event so OpenAI can match that conversion to the right user. OpenAI's June 2026 update uses these to improve match accuracy, which can raise reported conversions.
Will user objects increase my reported conversions?
Often yes. OpenAI states some advertisers "may see a meaningful increase in reported conversions." The increase is conversions that were already happening but failing to match — not new sales, but a truer count of real ones.
Do I send raw email and phone numbers?
No. Identity fields are normalized and SHA-256 hashed on your server before they are sent. The platform compares hashes, so your customers' raw contact details never leave your systems.
Why does match quality matter for automated bidding?
Automated optimization learns from your conversion signal. A low match rate means the optimizer trains on an incomplete, biased sample of converters and bids wrong. Raising match quality gives it a truer picture, so it spends better.
Is this the same as Meta's Conversions API or Google's enhanced conversions?
Conceptually, yes — all three send hashed first-party identifiers with conversions to improve matching. The field names and endpoints differ per platform, but the normalize-then-hash-then-send pattern is identical, which is why it is safe to implement against the established Meta and Google rules.
