Hashing the wrong fields: which user_data fields get SHA-256 in the Conversions API
Email and phone get SHA-256; IP, user agent, fbc and fbp don't. Mix them up and Meta matches fewer events. Which fields to hash and how to normalize them.
- With every purchase, the server sends in user_data the details Meta uses to recognise the customer.
- Email and phone must be SHA-256 hashed. So far, so good.
- But the IP, the user agent and the fbc and fbp cookies are hashed too, and those fields are sent without a hash.
- The cause: the integration hashes all of user_data, without telling fields apart.
- The fix: normalize and hash contact info only, and send the rest raw.
- Check it in the payload and in the event match quality in Events Manager.
Every Conversions API event carries a user_data object with the information Meta uses to link the event to a person: email, phone, IP, browser, Meta cookies. That link matters more than it seems: according to Meta, only matched events can be used for ads attribution and ad delivery optimization. And not every field is treated the same way. Contact information must arrive hashed; other fields, exactly as they are. Mixing up the two rules breaks matching without the API returning any error.
What wrong hashing looks like
Events arrive and Events Manager counts them, but Event Match Quality (a score out of 10) is low even though the integration sends plenty of parameters. Looking at the payload, you find something like this:
client_ip_address,client_user_agent,fbcorfbpholding 64-character hexadecimal strings, the look of a SHA-256, instead of an IP, a user agent or anfb.1.…value.- Or the other way round: email or phone in plain text, unhashed.
- Or hashed, but not normalized: the hash of
Ana@Example.comis not the hash ofana@example.com, so it never matches.
Why hashing ends up in the wrong place
Meta splits the user_data fields into three groups:
- Hashing required (SHA-256, after normalizing): email (
em), phone (ph), first name (fn), last name (ln), date of birth (db), gender (ge), city (ct), state (st), zip code (zp) and country (country). - Hashing recommended:
external_id, your own customer identifier. - Do not hash:
client_ip_address,client_user_agent,fbc,fbpand other Meta identifiers. For the IP, the documentation states explicitly that it must never be hashed.
The mistakes appear when an integration ignores that split:
- A function that hashes all of
user_data. The most common case in in-house builds and modified server-side GTM templates: the code loops over the object and runs SHA-256 on every value, the IP and the cookies included. - Hashing without normalizing. Meta asks you to normalize first: email trimmed and lowercased; phone as digits only, with the country code and no leading zeros; country as a lowercase two-letter ISO code.
- Double hashing. The library or SDK already hashes and the code hashes again before it. With Meta’s Business SDK, hashing is done automatically.
- Contact information in plain text. Meta states that its systems don’t accept unhashed contact information.
How to find fields with the wrong hashing
- Capture the real payload leaving the server: in the logs, in the server-side GTM preview or in your integration’s console.
- Go field by field:
em,phand the rest of the contact information must be 64-character hashes;client_ip_addressmust be a valid IP (IPv4 or IPv6), andfbcandfbpmust start withfb.. - Compute by hand the SHA-256 of a normalized test email and compare it with the
emsent. If they don’t match, normalization is missing or there is double hashing. - In Events Manager, open the Pixel’s Overview and check each event’s Event Match Quality; clicking the score shows details and recommendations.
How to hash only where it belongs
- Normalize and SHA-256 only the hashing-required fields (and
external_id, if you send it). - Send
client_ip_address,client_user_agent,fbcandfbpas they are. The IP must be the user’s real IP, not the server’s; the user agent is required for website events. - Hash once. If you use the Business SDK or a library that already does it, hand it the data normalized and in plain text.
- If you’re unsure about the structure, Meta’s Payload Helper shows how an event payload should look.
Meta’s documentation: Customer information parameters and Conversions API best practices.
How to check the hashing is right
- In the payload, contact information is made of 64-character hashes, and the IP, user agent,
fbcandfbpare readable. - The hash of a test email computed by hand matches the
emsent. - Over the following days, Event Match Quality goes up. Meta recommends aiming for a score of 6.0 or higher.
The hashes and values in the example are illustrative. The IP belongs to a range reserved for documentation.