Meta's Conversions API accepts a long list of advanced matching parameters. Most teams send email and phone and stop there. Four additional parameters consistently improve match quality enough to justify the small additional PII exposure.

1. external_id

Your own user identifier (a UUID, a CRM ID, a hashed user_id from your auth system). Meta uses it to deduplicate events from the same user across sessions and devices. Without it, repeated visits from the same user can be miscounted.

Send as a SHA-256 hash. Meta does not display the value back to you, so even your own debugging tools see only the hash.

2. fn and ln (first name, last name)

Hashed first and last name. Lowercase, strip whitespace, then SHA-256. Useful for users who signed up with a different email than the one Meta has on file. The combination of name + city is sometimes the only matching keys that work for a given user.

3. ct, st, zp (city, state, zip)

All three should be lowercase, ASCII-stripped (remove accents), trimmed, then hashed. Country (country) is a special case: send the lowercase ISO 3166-1 alpha-2 code (us, fr, jp), hashed.

4. db (date of birth)

Format: YYYYMMDD as a string, then SHA-256. Date of birth is a strong matching key, especially when combined with name. The trade-off in PII sensitivity is meaningful; send only when you genuinely have it from a registration form.

The lift

Adding all four typically improves event match quality (EMQ in Meta's terms) by 5-15 points. Combined with proper email and phone normalisation, this puts most accounts in the 75-85 EMQ range.

What not to send

Avoid sending fields you cannot trust. If your registration form does not require last name, do not send a placeholder. Send only the fields you have actual user data for. Hashed empty strings are still valid hashes and Meta will fail to match them.

For the simpler email-and-phone-only setup, the phone normalisation guide covers the trickier of the two.