{"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-10-26T11:52:52","modified_gmt":"2026-10-26T10:52:52","slug":"preparing-customer-data-for-the-meta-conversions-api-correct-formatting-and-hashing","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-marketing\/preparing-customer-data-for-the-meta-conversions-api-correct-formatting-and-hashing\/","title":{"rendered":"Preparing Customer Data for the Meta Conversions API: Correct Formatting and Hashing"},"content":{"rendered":"

SHA-256 calculates a fixed-length value from the input data. This value is called a hash. A successful Conversions API response does not establish that an email address was matched correctly. A plausible SHA-256 value can originate from incorrectly prepared data. Other identifiers may still support matching. API acceptance, data quality and actual matching therefore require separate checks.<\/p>\n

Normalisation means converting an input into the form required for a particular field before hashing. For an email address, the sequence is removal of surrounding whitespace, conversion to lowercase and then SHA-256. Changing the resulting hash cannot repair an input error.<\/p>\n

\"Two
Two spellings, two hashes. Local comparison with an expected value does not prove API acceptance or attribution.<\/figcaption><\/figure>\n

Why the exact input matters<\/h2>\n

SHA-256 processes bytes. Spaces and letter case change the result. Three spellings of the same fictional address produce three different hashes in the example. Comparison with the expected hash requires the normalised spelling. This does not mean that Meta never compares other values, or that the entire event necessarily remains unmatched.<\/p>\n

Field rules instead of one function for everything<\/h2>\n

The following overview is an integration guide. The current Meta field specification and the installed SDK version remain decisive. An SDK is a software library supplied to help applications use the API. It may already normalise and hash values, so preceding transformations must be compatible.<\/p>\n\n
Field<\/th>Preparation and check<\/th><\/tr><\/thead>
em<\/code><\/td>Removal of surrounding whitespace and lowercase conversion; no invented corrections to the address.<\/td><\/tr>\n
ph<\/code><\/td>International number with country calling code, containing only digits for hashing. Country-specific prefixes require correct interpretation first.<\/td><\/tr>\n
fn<\/code>, ln<\/code><\/td>Lowercase and surrounding whitespace require attention. The inspected Python\/Node.js helpers do not universally remove internal spaces and punctuation from these fields.<\/td><\/tr>\n
ct<\/code><\/td>Lowercase city name without spaces or punctuation according to the field specification; SDK behaviour needs representative tests.<\/td><\/tr>\n
country<\/code>, st<\/code><\/td>Country as a two-letter ISO code such as de<\/code>. Region handling is separate: a US state abbreviation is not a worldwide region rule.<\/td><\/tr>\n
ge<\/code>, db<\/code><\/td>Where available and permitted: f<\/code>\/m<\/code> or a valid date in YYYYMMDD<\/code>. Missing values must not be guessed.<\/td><\/tr>\n<\/tbody><\/table>\n

Phone numbers can be processed automatically with country context and a maintained library such as libphonenumber. Removing every non-digit is insufficient: the German example +49 (0)170 1234567<\/code> would retain an unnecessary zero. However, deleting a zero after every country calling code is also wrong; a leading zero can belong to an Italian international number. Ambiguous input requires clarification. Format validation does not prove current reachability.<\/p>\n\n\n\n

\"Laundry
Laundry is sorted by kind into three baskets, while a silk scarf hangs apart. Likewise, each kind of customer data needs its own rule before hashing (making it unreadable).<\/figcaption><\/figure>\n\n\n

Values that remain unhashed<\/h2>\n

client_ip_address<\/code>, client_user_agent<\/code>, fbp<\/code> and fbc<\/code> are transmitted unhashed according to the respective specification. That does not make these values harmless or unrelated to personal data. The IP address must correspond to the event; a proxy address does not replace the browser address. Cookie and click identifiers must not be arbitrarily invented.<\/p>\n

These are important examples, not a complete list of API fields. An explicit field mapping determines validation, normalisation, hashing or unchanged transmission. New fields need a deliberate decision rather than a blanket hashing loop over the entire object.<\/p>\n

A reproducible test without real customer data<\/h2>\n

This Python example calculates complete hashes for a fictional address. The first two outputs start with 524d6368<\/code> and de4c5edc<\/code>; the normalised version starts with dd432348<\/code>.<\/p>\n

Python<\/span>