How to Send First Party Customer Data to Ad Platforms Safely
Hashed customer data is what keeps matching alive as cookies fade. Here is what to send, how to normalize it, and where the limits are.
As cookies get less reliable, the thing keeping your conversions matched is customer data you already own. Email, phone, name, address.
Sending it well is one of the highest return things you can do. Sending it carelessly is a privacy problem. Both are worth understanding.
What this is actually doing
When a sale happens, the platform needs to connect it to a person it recognizes. Historically that was a cookie. When the cookie is missing, hashed customer data gives a second route.
Hashing turns the email into a fixed string. The platform hashes its own records the same way and looks for a match. It never sees the readable address, and neither does anyone watching the request.
This is what powers Google’s Enhanced Conversions and Meta’s advanced matching. Same idea, different names.
What to send
In rough order of matching power:
Email. The strongest single identifier. If you send one thing, send this.
Phone number. Nearly as strong, and often present at checkout.
First and last name.
City, state, postal code, country. Weak alone, useful in combination.
External ID. Your own customer identifier. Underused, and genuinely helpful for repeat customers.
More fields means better matching. Most stores send email and stop, leaving a lot on the table.
Normalization, where it silently fails
Hashing is exact. Two strings that differ by one space produce completely different hashes and will never match.
So normalize before hashing, every time:
Lowercase everything.
Trim leading and trailing whitespace.
Strip spaces, dashes, and brackets from phone numbers.
Add the country code to phone numbers.
Remove titles from names. Send John, not Mr John.
Omit empty fields entirely rather than sending the text null or undefined.
That last one is a real and common bug. An empty field sent as the literal word undefined gets hashed and matched against nothing, forever.
Image: before and after table showing raw customer values and their normalized versions ready for hashing.
Where hashing should happen
Two options with different tradeoffs.
In the browser, before sending. Simple, and the readable value never leaves the user’s device.
On your server, in a server side container. More control, and you can enrich the data from your own records first. This is the better option if you are already running server side tracking. See
What you should not do is send raw readable emails to an ad platform and rely on them to hash it. Some accept it. Do not take the option.
The consent part
This is not a loophole. Sending hashed customer data still requires a legal basis.
If a user declined marketing consent, hashing their email does not make it acceptable to send. Consent state must gate this the same way it gates everything else.
There is also an acceptance step in Google Ads for customer data terms. Skip it and the feature quietly does nothing, which is a confusing way to spend a week.
Consent handling is covered in
Checking it works
Complete a real conversion and inspect the outgoing request.
Confirm the customer fields are present and hashed. You should see long strings, never readable emails.
Check the platform’s diagnostics. Google Ads reports enhanced conversion status, Meta reports match quality.
Look at the percentage of events that include each field. If phone is on 3 percent of events, your capture is broken.
After two weeks, check for additional conversions attributed through matching.
If diagnostics say data is arriving but nothing improves, normalization is the usual suspect.
Need this built properly?
If your match rates are poor and you are sending customer data you believe is correct, formatting is almost always where it breaks. I set up and repair tracking for ecommerce stores and lead generation businesses, so the numbers in your ad accounts match the money in your bank account.
Have a look at what I do, or book a call and we can go through your setup together.
