{"id":10464,"date":"2026-09-18T07:20:00","date_gmt":"2026-09-18T05:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10464"},"modified":"2026-09-10T12:14:21","modified_gmt":"2026-09-10T10:14:21","slug":"conversions-api-hashing-normalising-customer-parameters-before-sha-256","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-marketing\/conversions-api-hashing-normalising-customer-parameters-before-sha-256\/","title":{"rendered":"Conversions API Hashing: Normalising Customer Parameters Before SHA-256 and Which Fields Stay Unhashed"},"content":{"rendered":"

A Conversions API event that carries a hashed email address looks the same whether the hashing was done right or wrong. The payload validates, the API answers with a success, the event counter goes up, and the match quality figure stays where it was – because the address, correctly hashed into a string that corresponds to nothing, was compared against a customer base and found in none of it.<\/p>\n

That is the failure mode worth understanding before any of the plumbing: hashing does not fail loudly, it fails by producing something that is technically flawless and semantically empty.<\/p>\n

\n\"The
Two real SHA-256 values of the same address. Three characters of whitespace and a few capitals separate them.<\/figcaption><\/figure>\n

Why a Small Difference Is a Total Difference<\/h2>\n

A hash function is built so that a minimal change to the input produces an unrecognisably different output. That property is what makes hashing useful, and it is exactly what makes a normalisation mistake fatal: there is no such thing as almost matching. Two hashes are identical or they have nothing to do with each other, and no amount of fuzzy matching downstream can recover the difference.<\/p>\n

So the entire question of whether an event finds a person is decided before the hash function is ever called, in the few lines that decide what exactly goes into it.<\/p>\n

The Form Each Parameter Has to Take<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
Parameter<\/th>\nRequired form<\/th>\nWhat goes wrong<\/th>\n<\/tr>\n<\/thead>\n
em<\/code><\/td>\ntrimmed, lowercase<\/td>\na capital from the form, a trailing space from a paste<\/td>\n<\/tr>\n
ph<\/code><\/td>\ndigits only, with country code<\/td>\nthe national trunk zero in +49 (0)170 survives<\/td>\n<\/tr>\n
fn<\/code>, ln<\/code><\/td>\nlowercase, no punctuation or spaces<\/td>\na hyphen in a double-barrelled surname<\/td>\n<\/tr>\n
ct<\/code><\/td>\nlowercase, no spaces<\/td>\nFrankfurt am Main keeps its spaces<\/td>\n<\/tr>\n
st<\/code>, country<\/code><\/td>\ntwo-letter lowercase code<\/td>\nthe country is written out<\/td>\n<\/tr>\n
ge<\/code><\/td>\nexactly f<\/code> or m<\/code><\/td>\nanything else, hashed as if it were a value<\/td>\n<\/tr>\n
db<\/code><\/td>\nYYYYMMDD<\/td>\na locale date format, silently reordered<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The phone number deserves a note of its own, because it is the one case that cannot be normalised mechanically. Stripping non-digits from +49 (0)170 1234567<\/code> leaves 4901701234567<\/code>, and the zero after the country code is a national dialling prefix that has no place in an international number. No rule can decide that reliably for every country, which is why the honest handling is to strip, then flag the suspicious pattern for a human rather than guess.<\/p>\n

The Parameters That Must Not Be Hashed<\/h2>\n

The opposite mistake is rarer and just as final. client_ip_address<\/code>, client_user_agent<\/code>, fbp<\/code> and fbc<\/code> are sent in plain text. They are not personal identifiers in the sense the hashed fields are; they are values Meta matches against its own records, and a hashed one is a string that corresponds to nothing on the other side.<\/p>\n

This happens most often when a hashing helper is applied to the whole user-data object at once, which is a reasonable-looking piece of code and wrong in exactly four fields. A helper that hashes by field name rather than by object is the version that survives a schema change.<\/p>\n

What This Looks Like From Outside<\/h2>\n
# the same address, three ways\n\"  Max.Mustermann@Example.COM \"   → 524d6368ceb086b2b1d8fed14ee75313…\n\"  max.mustermann@example.com \"   → de4c5edc5348280eedb5b029d7851764…\n\"max.mustermann@example.com\"      → dd432348e6c3373c5f646913fa94ae79…\n\n# only the third is ever compared against anything<\/code><\/pre>\n
None of these produces an error. The event count in the events manager is identical in all three cases, the delivery is confirmed in all three cases, and the only figure that moves is the match quality – downwards, slowly, in a way that is easy to attribute to seasonality or to a consent change.<\/p>\n
Which is why the useful check is not the API response but a comparison against a known value. Take one address from the customer base, hash it the way the shop hashes it, hash it the way the specification prescribes, and compare the two strings. They match or the pipeline has a normalisation bug, and the answer takes a minute.<\/p>\n
Where the Normalisation Belongs<\/h2>\n
The last decision is architectural. Normalisation can happen in the browser, in the server container, or in the backend that has the customer record – and only the last of those has the original value in the form the customer base stores it in.<\/p>\n
Doing it in the server-side container is the common middle ground and works, provided the container receives the raw value and not something a form has already mangled. Doing it in the browser is the one arrangement to avoid: it puts the plain address into a request that leaves the visitor’s machine, which is precisely what the hashing was there to prevent.<\/p>\n
\n
Sources<\/h2>\n