Conversions API Hashing: Normalising Customer Parameters Before SHA-256 and Which Fields Stay Unhashed

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.

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.

Why the exact input matters

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.

Field rules instead of one function for everything

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.

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 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.

Values that remain unhashed

client_ip_address, client_user_agent, fbp and fbc 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.

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.

A reproducible test without real customer data

This Python example calculates complete hashes for a fictional address. The first two outputs start with 524d6368 and de4c5edc; the normalised version starts with dd432348.

import hashlib

samples = [
    "  Max.Mustermann@Example.COM ",
    "  max.mustermann@example.com ",
    "max.mustermann@example.com",
]
for value in samples:
    print(repr(value), hashlib.sha256(value.encode("utf-8")).hexdigest())

expected = "dd432348e6c3373c5f646913fa94ae7947bc0086b42028aedec4371e3e3c2cdb"
normalised = samples[0].strip().lower()
assert hashlib.sha256(normalised.encode("utf-8")).hexdigest() == expected

The test demonstrates local calculation, not matching by Meta. Integration testing requires the same fictional test value to pass through every processing step, including the final data sent to Meta. Empty values, international phone numbers, postcodes and already hashed inputs also need coverage. Unprotected logs are unsuitable for raw customer data or real identifiers.

API errors and warnings remain relevant. A mismatching hash may pass unnoticed, but an SDK can reject malformed input before transmission. Event Match Quality is a diagnostic indicator, not proof that a specific event was linked to a specific person. A single hashing error does not imply a predictable change in that indicator or the event count.

Browser or server: the data flow matters

Normalisation and hashing can run in a browser or on a server. Meta also provides a client-side parameter builder. Browser hashing does not force transmission of the raw address: actual requests and other scripts determine whether raw data leave the device. A backend can also receive raw data, with corresponding protection requirements.

The integration needs a clearly assigned processing stage, a documented input state and inspection of outgoing data. A secret CAPI access token must not appear in publicly delivered browser code. Hashing replaces neither transport encryption nor a lawful processing arrangement.