Normalize email and phone before hashing

A hash is only useful if both sides produced it from the same input. Hash Sam@Example.com while the destination hashes sam@example.com, and the two values have nothing in common. Nothing errors, nothing warns, and the conversion simply does not match.

This is why formatting is the first thing to check when a match rate disappoints, ahead of coverage. A field in the wrong shape is a field that did not arrive.

The order matters

Normalize first, then hash. Doing it the other way round produces a hash of the unnormalized value, which is exactly the problem this is meant to prevent.

The rules

Field	Normalize it like this
Email address	Trim leading and trailing whitespace, then convert everything to lowercase. One address per field.
Phone number	E.164. A leading plus sign, then the country code and the number, up to fifteen digits, with whitespace, brackets and hyphens removed. For example `+919876543210`. On a file source this goes in the format_b column.
First name, last name, city	Letters a to z only. Trim whitespace, convert to lowercase, remove punctuation and special characters.
State	For the United States, the two-character code in lowercase. Elsewhere, the full region name in lowercase with no punctuation, special characters or whitespace.
Postcode	Lowercase, no whitespace. United States, the first five digits only. United Kingdom, the Area, District and Sector format.
Country	The two-letter ISO 3166-1 alpha-2 code, in lowercase.
Gender	A single letter: `m` or `f`.
Date of birth	DD/MM/YYYY in the combined field, or YYYY, MM and DD in the three separate fields.

Then hash

Apply SHA-256 to the normalized value. If you send the value in plain text instead, Signals normalizes and hashes it for you before it reaches the destination, so either approach works. What does not work is hashing without normalizing.

What not to hash

Device identifiers. GAID, IDFA and IDFV are sent as they are, and hashing them makes them unusable at the destination.
Anything in a column that is not marked as hashed. On a file source that includes the plain postcode, country and external identifier columns.
City, state, country and postcode when the destination is Google. Those four go in plain text there, while email address and phone number are still hashed.
Empty values. Hashing a blank cell produces a real-looking 64-character value that matches nobody, and it is one of the most common export bugs we see. Leave the cell empty.

How to check your own work

Take one record you can identify and hash it by hand, then compare with what your export produced. They should be identical.
Check the length. A SHA-256 value is 64 hexadecimal characters. Anything shorter or longer is not one.
Look for the hash of an empty string in your file. If the same 64-character value appears on many rows in a column that should vary, blanks are being hashed.
Check a sample of phone numbers actually carry a country code, rather than assuming the export added one.