Every Meta advertiser has a pixel. Most assume it reports what happened. It reports what was allowed to happen, which is a different thing.
Where the events go
Ad blockers strip the script before it runs. Browser tracking prevention — Safari's ITP, Firefox, and increasingly Chrome — limits or blocks third-party requests. Consent banners, when they work properly, gate the pixel until someone agrees. Network conditions drop requests on poor mobile connections. Page abandonment kills events that fire late.
Across our accounts the shortfall between browser-reported and server-reported conversions typically runs around a quarter. It varies by audience.
That variation is the actual problem.
If the loss were uniform you could multiply by a constant. It is not — the most privacy-protected users are the most likely to disappear, and they are not a random sample of your market.
What that does to optimization
Meta's delivery optimization learns from the conversions it receives. If a segment of your audience systematically fails to report conversions, Meta concludes that segment does not convert, and stops showing your ads to it.
You end up with a campaign optimized toward the people whose browsers report most reliably. Nobody chose that targeting.
The Conversions API
The server-side alternative. Your server sends the conversion directly to Meta, and because it never touches the visitor's device, none of the blocking applies.
Three things make it work properly:
Event ID deduplication. The browser and the server both report the same
conversion with the same event_id, and Meta collapses the pair. Without it,
every conversion is counted twice, which is worse than undercounting.
Normalized hashing. Email and phone go as SHA-256. The input must be normalized first — lowercased, trimmed, digits only for phone with the country code prefixed — or the same person hashes to two different values and the match silently fails. This is the most common implementation error and it produces no error message.
The click identifiers. Meta's _fbc cookie carries the click ID from the
ad that brought them, and _fbp identifies the browser. Passing both lifts
match quality substantially over email alone.
Send the right event
Most accounts send a conversion when a form is submitted. For anything with an appointment, that is the wrong moment — it teaches Meta to find form-fillers.
Send it when they book, and ideally send a second one when they attend. Then the algorithm is hunting for people who show up, which is the population you actually want. This requires connecting the booking system to the ad platform, which is most of the work and most of the value.
How to check yours
In Events Manager, compare browser and server event counts for the same event. If the server number is not meaningfully higher, the server implementation is either missing or misconfigured.
Then check match quality. If it is poor and you are sending email, the hashing normalization is almost certainly wrong.
If your account has a pixel and nothing else, this is the highest-value technical change available, and it is a day's work rather than a project.