Pulsar · Field guide · No. 17 · Why browser pixels leak, what CAPI is, and how coverage and match quality decide whether an event counts.
Events the Browser Can’t Block
Ad-blockers and iOS quietly drop a chunk of your pixel events. The Conversions API sends a server-side copy nothing in the browser can stop — deduped so you never double-count.
The events that never arrive
The browser pixel is fragile by design. Ad-blockers strip it, iOS tracking prevention blocks it, cookies expire, and flaky networks drop it — all silently. A sale still happens; Meta just never hears about it.
An event that never arrives can’t optimize your ads or prove your sale. You paid for it twice.
The damage is invisible: your charts still move, but a chunk of conversions are missing from the exact signal Meta learns from. The fix isn’t a better pixel — it’s a second, unblockable copy sent from your server.
A server-side copy of every event
The Conversions API (CAPI) is your backend sending the event straight to Meta, server-to-server — no browser in the path. Same events (Purchase, AddToCart…), a channel nothing on the device can block.
Browser pixel
client-side
Fires from the user’s browser. Rich, easy — but blockable by ad-blockers, iOS and cookie loss.
Conversions API
server-side
Fires from your server. Survives ad-blockers and iOS because there’s no browser to block. The reliable copy.
You run both: the pixel for its rich browser context, CAPI for reliability — and you stitch them so Meta counts each real event once.
Deduplication: send both, count once
Sending the same Purchase from the browser and the server would double-count — unless you give Meta a way to see they’re the same event. That key is a shared event_id (plus event name).
Two different jobs: coverage vs match quality
Getting the event to Meta is only half of it. Two separate questions decide whether it actually helps you — and people fix only one.
| Question | Name | What fixes it |
|---|---|---|
| Did the event arrive at all? | Coverage | server-side sending (CAPI) so nothing blocks it |
| Once it arrives, can Meta tie it to a person? | Match quality (EMQ) | strong customer info on the event |
CAPI wins coverage. It does nothing for match quality on its own — that depends on what you put inside the event.
Give Meta something to match on
Meta scores every event 0–10 on how confidently it can tie it to a person — the Event Match Quality (EMQ). Send more (hashed) customer signals and the score climbs.
Device-only 6.1 → with contact 8.0
On a real pixel: an event carrying only device signals scored 6.1; the checkout carrying hashed email, phone and name scored 8.0. That gap decides whether Meta learns from your buyer or shrugs.
Send (SHA-256 hashed): email, phone, name, external_id — plus fbp/fbc. A 6.1 on Search is survivable; a 6.1 on Purchase is revenue going invisible.
How to turn it on
You don’t need to rebuild anything — you add a parallel server stream and stitch it to the pixel.
Common mistakes — and how Pulsar does it
- ×No event_id. Browser + server double-count. Always share the key.
- ×Device signals only. Coverage without match quality — the event arrives but barely counts. Send hashed contact info.
- ×Unhashed PII. Email/phone must be SHA-256 hashed before they leave your server.
- ×Browser-only in 2025+. Without CAPI you’re running on the most blockable channel there is.
fbp/fbc so the match survives, dedupes against the browser copy by event id, and pushes hashed email/phone/name to lift EMQ on your money events. Coverage and match quality, both handled.