What PII Hashing Is
Personally identifiable information (PII) is data that identifies a person directly, such as an email address, phone number or name. Measurement and ad platforms often need some of it, for example to match a conversion to a user who signed in on another device, or to send conversions to Meta and Google with enough detail for them to attribute it.
Hashing lets you share a stand-in for the value instead of the value itself. A hash function takes any input and produces a fixed-length output. The same input always gives the same output, and a tiny change gives a completely different one. Good hash functions are one-way: you cannot calculate the original from the hash. Two parties who hash the same email will get the same string and can match on it without either sending the raw email.
How SHA-256 Hashing Works in Practice
SHA-256 is the standard for advertising. It outputs 256 bits, written as 64 hexadecimal characters. Meta's Conversions API, Google Ads enhanced conversions and customer match, and most MMPs accept SHA-256 hashes of normalised values.
Normalisation comes first, and it is where most matching problems start. For emails, trim spaces and convert to lowercase. For phone numbers, remove spaces, dashes and brackets, and use the full international format with country code. Names, cities and postcodes have their own rules per platform. Hash only after normalising, and check that every system in your pipeline uses the same rules. One system lowercasing and another not is enough to drop match rates sharply.
Some platforms also accept or require a salt or key, which is a secret mixed into the input so outsiders cannot match hashes against lists of known values. Advertising matching usually uses unsalted SHA-256, because both sides need to produce the same hash.
What Hashing Does and Does Not Protect
Hashing protects against casual exposure. A hashed email in a log file, a postback or an export does not reveal the address to someone reading it. That is useful and worth doing.
It does not make data anonymous. Anyone who already has an email address can hash it and look for a match, and lists of common emails or every possible phone number in a country can be hashed in bulk. For that reason, privacy regulators generally treat hashed identifiers as pseudonymised personal data. GDPR, the CCPA and India's DPDPA still apply to them. You still need a lawful basis or consent to share them, and you still need to honor deletion and opt-out requests.
Where PII Hashing Is Used in Attribution
Server-side conversion APIs are the main use. When an app sends a purchase to Meta or Google, adding hashed email or phone improves the platform's ability to match the event to an ad interaction, especially on iOS where device identifiers are often unavailable.
Cross-device journeys are another. A user who clicks an ad on the web and later signs in on the app can be connected through a hashed email or phone they used in both places. In Linkrunner, multi-touch attribution (available per project on request) connects cross-device journeys through your customer user ID and hashed email or phone, never IP.
PII Hashing in Linkrunner
PII hashing in Linkrunner is an opt-in SDK setting, enablePIIHashing(true), not the default. When enabled, the SDK hashes name, email and phone number with SHA-256 on the device before sending them to Linkrunner servers. Decide with your privacy team whether to turn it on, and keep the normalisation consistent with what your ad platforms expect. See the Trust Center for Linkrunner's broader security and privacy practices.
Hashing Is One Control Among Several
Hashing works best as part of a set of privacy controls rather than on its own. Data minimisation comes first: send only the identifiers a partner actually needs for the job, and skip optional fields such as names or addresses when an email or phone is enough. Consent comes next: hashed identifiers still need a lawful basis to be shared, and should not be sent for users who declined.
Access control matters too. Limit who in your company can export hashed identifiers, and log exports. Retention rules should cover hashed values the same way they cover raw ones, and deletion requests should remove both.
Finally, review partners. Ask how each partner stores the hashes it receives, how long it keeps them, whether it combines them with other data, and how it handles deletion. The protection you get from hashing depends on what happens to the hash after it leaves your systems.