Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

In Meta Conversions API payloads, email and other designated customer-information fields may require normalization and SHA-256 hashing, while client_ip_address and client_user_agent should remain plaintext. A generic helper that hashes every string can put valid-looking digests in the wrong fields. The topic article reports that these mistakes can still receive HTTP 200, so a successful response alone does not show that an event matched a person or was attributed as intended.

Why a 200 response does not prove event matching worked

HTTP 200 indicates that a request received a successful response; it is not, by itself, evidence that every field was semantically correct or that Meta matched the event to a person. Aleksander Sekowski, author of the topic article and Pixellint maintainer, describes the failure mode: “A model that ‘hashes PII before send’ will hash the IP unless something checks the field list.” Read the topic article.

The article reports that a request with an incorrectly hashed field can still return 200. That behavior is reported by the article; it has not been independently confirmed here against accessible official Meta documentation. For the current requirements and response semantics, consult Meta’s Conversions API documentation.

Which values to hash—and which to leave alone

Hashing is a field-level contract, not a rule to apply indiscriminately to every string in a payload. Pixellint’s Meta Conversions API rulepack says that customer-information values such as email and phone are normalized and SHA-256 hashed, while client_ip_address and client_user_agent are sent in the clear. That description comes from Pixellint, not from Meta itself. See Pixellint’s rulepack.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Email: trim whitespace, lowercase the address, then SHA-256 hash the normalized value.
  • Phone: normalize to digits, including a country code, then hash, as described by Pixellint’s rulepack.
  • client_ip_address and client_user_agent: preserve their documented plaintext forms; do not run them through a customer-data hashing helper.

Normalization must precede hashing: a change to the input text changes the digest. A 64-character hexadecimal value may look like a plausible SHA-256 result, but appearance cannot establish that the value belongs in that field or was derived from the right normalized input.

How to prevent a blanket-hashing bug

Use a per-vendor, per-field allowlist

Define normalization and hashing rules for each destination and field. For the Meta example, hash only the customer-information fields that the current contract designates for hashing. Keep IP and user-agent fields outside that path. Do not reuse a single transformation over every string in the event object.

Test field meaning, not just output format

Build a fixture with a test email, phone, IP address, user-agent, and platform cookie. Assert that email and phone have the required normalized-and-hashed forms, and that the IP and user-agent remain in their documented plaintext forms. Handle cookies according to the receiving vendor’s current documentation; the field distinction established here concerns Meta’s client IP and user-agent.

Pixellint’s validator documentation describes checks for both raw email appearing in a hashed field and a hash-like string appearing in a field documented as plaintext. Pixellint is an independent validation option, not a Meta product or an authority on Meta’s contract. Review the validator rulepack.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Debug the payload when matching is poor

  1. Inspect the outgoing payload and verify that each value is mapped to the intended field.
  2. Check email normalization before hashing: whitespace trimmed and address lowercased.
  3. Check that each field requiring hashing contains a digest derived from its normalized value.
  4. Check that client_ip_address and client_user_agent were not hashed or otherwise transformed.
  5. Review the receiving platform’s current documentation for any other identifiers, normalization rules, and event deduplication requirements.

Do not diagnose matching from the HTTP status or from the presence of a hash-looking string alone. A correct hash in the wrong field is still a field-mapping error.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Do not reuse one platform’s hashing rules for another

The topic article contrasts Meta’s requirements with Google Ads enhanced-conversion email normalization and discusses other ad platforms. The practical lesson is not that every platform uses the same allowlist: each destination can specify different fields to hash, different normalization, and different treatment of request metadata or opaque click identifiers. Event IDs used to align browser and server events for deduplication are another separate concern; check the destination’s current documentation rather than treating them as customer fields to hash.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.