On this page
A server-side event arrives at Meta with no browser attached to it. There is no cookie, no click ID from the URL, nothing that says which ad this person came from. The only way Meta can join that event to the click that produced it is by recognising the person, and the only way it is allowed to do that is by comparing hashes of contact details it already holds.
What gets hashed, and what it is for
- Email and phone. The two that do most of the work, because Meta holds both for most accounts and a match on either is usually decisive.
- First name, last name and state. Weaker on their own, useful as corroboration when the email is a shared or business address.
- IP address and user agent. Not hashed, sent alongside, and they help place the event with the session that produced it.
- The event ID, which is what lets the server copy be collapsed into the browser copy rather than counted twice.
The contact details are hashed before they leave your server, so what Meta receives is not the merchant’s email address but a fingerprint of it. It compares that against fingerprints of the addresses it already has. Nothing readable crosses the wire, which is why this is the standard way of doing it rather than a clever one. Meta scores the result as Event Match Quality, and that score is the practical measure of whether your server events are doing anything at all.
Why the form’s verification steps exist
This is where the funnel design and the tracking turn out to be the same decision. A one-time passcode to the mobile number and a live email check are usually argued for on lead quality: they remove fakes, VoIP numbers and mistyped addresses before a record exists. They are also what makes the hashed data worth sending. A phone number nobody verified is a fifty-fifty chance of a hash that matches nothing.
Put the other way round: the verification steps pay for themselves twice. Once on the floor, because a rep dials a number that rings, and once in the ad account, because the event for that lead can be matched to the click that bought it.
Where it matters most: the funded deal
For a qualified-submission event, hashed data improves attribution at the margin — the browser copy often gets through, and the click ID is available. For an event fired weeks later from a CRM, it is the whole mechanism. A funded deal has no browser session at all; the only thing connecting it to an ad is the merchant’s email and phone.
Two details on that board are easy to miss. The funded deal goes back as a Purchase with the deal amount as its value, not as a custom event — Purchase is what unlocks value-based bidding, so Meta starts chasing deal size rather than deal count, and a $100,000 funding weighs more than a $20,000 one. And it should be sent the day it funds, because the older the event, the worse the match.
The failure mode
A Conversions API with no hashed data is one of the five mistakes that turn up on nearly every consulting call. It is worse than not running the Conversions API at all, because the events arrive, the numbers in Events Manager look healthy, and none of it is attributable to an ad. You have built the expensive half of the system and thrown away the part that made it useful.
Questions brokers ask
What data does the Meta Conversions API need?
Hashed email, phone, first name, last name and state, plus the IP address and user agent, and the event ID that matches the browser copy. Email and phone do most of the matching; the rest is corroboration.
What is Event Match Quality?
Meta’s score for how well it can match your server events to real people and therefore to ad clicks. It rises with the number and accuracy of the hashed fields you send, and a low score means the events are arriving but attributing to nothing.
Is sending hashed customer data to Meta safe?
The contact details are hashed before they leave your server, so Meta receives a fingerprint rather than a readable address or number, and compares it against fingerprints it already holds. Your own privacy notice still has to say the data is used this way.
How does Meta know which ad produced a funded deal weeks later?
By the hashed email and phone on the event. There is no browser session left, so the contact details are the only link back to the original click — which is why both are verified on the application form.
Should a funded deal be sent as a custom event?
No, send it as Purchase with the deal amount as the value. Purchase unlocks value-based bidding, so Meta optimises towards larger fundings rather than simply more of them, and a custom event gives it no value to bid on.
Reference
The video this comes fromThe Conversions API step, the funded-deal path and the transcript in full.
Alex Makowski
Founder, Infinite Bookings
Runs the lead generation operation behind Infinite Bookings — paid traffic, the funding application, and the delivery pipeline that puts records into brokers’ CRMs.
Reachable directly at alex@infinitebookings.com or 732-609-7182.