Pulsar
metrics playbook · the invisible sales
Present: ← → Space · Esc back to Doc

Pulsar · Metrics playbook · No. 04 · Coverage & Event Match Quality. Real EMQ measured on the test pixel.

The Invisible Sales

Meta only optimizes on the conversions it can SEE and MATCH. The rest are budget you spent teaching it nothing.

Companion to No. 01 — Efficiency & Fatigue, No. 02 — Quantity vs. Quality and No. 03 — Garbage In, Lookalike Out.

Contents

01 The blind spot · 02 Coverage vs. match quality · 03 Send it server-side · 04 Event Match Quality · 05 What weak match costs · 06 The fix · 07 Where Pulsar fits

01

The blind spot: Meta only learns from what it can SEE

Meta can only optimize toward, attribute, and learn from conversions it actually RECEIVES and can MATCH to a person. A browser-only pixel loses a large share of events — ad-blockers, iOS / Intelligent Tracking Prevention, cookie expiry, dropped network calls — so a real sale can be completely INVISIBLE to Meta.

Can’t optimizedelivery never learns this ad produced a sale — the auction keeps hunting for the wrong pattern.
Can’t attributethe ad that earned the sale gets no credit — your reported ROAS drops below reality.
Can’t seedthe buyer never joins your lookalike seed — the exact failure mode of No. 03, Garbage In, Lookalike Out.
A sale Meta can’t see is a sale you paid for twice — once to make it, and again because Meta never learned from it.
02

Two SEPARATE problems: coverage vs. match quality

People blur these together and fix only one. They are different jobs, failed in different places, fixed by different tools.

Problem A

Coverage

did the event even ARRIVE?

Did the event even REACH Meta? A browser-only pixel misses a chunk — blocked, expired, dropped. Sending server-side (Conversions API / CAPI) recovers it.

Problem B

Match quality

once it arrives, does it COUNT?

Can Meta tie it to a real person? That needs identifiers — email, phone, name — hashed and attached. Without them Meta received an event from nobody in particular.

You need BOTH. A delivered-but-unmatchable event is almost as useless as a lost one — it arrived, but it doesn’t count for anyone.

Getting the event to Meta and getting Meta to recognize the person are two different jobs.
03

Coverage: send it server-side — real data

You send both: the browser pixel for speed and page context, and a server event (CAPI) that nothing in the browser can block. The two are deduplicated by a shared event_id — the same sale sent twice, counted once.

Browser eventfires in the page — fast, rich context — but ad-blockers, iOS/ITP and cookie loss can kill it before Meta sees it.
Server event (CAPI)fires from your backend — immune to blockers — the copy that always arrives, whatever the browser did.
event_idthe shared key on both copies — Meta drops the duplicate, so a sale is never double-counted.

Browser vs. server — and the slice only CAPI saves

Toggle below: with a browser-only pixel, a slice of real conversions is invisible. Server-side sending recovers it; the overlap is deduped on event_id.

This pixel measures CAPI coverage at 100% — Meta’s goal is 75%. Every unique browser event is backed by a server event; dedup on event_id runs browser 100% / server 100% — matched, not doubled.
100% vs 75%
CAPI coverage 100% vs Meta’s 75% goal — nothing lost in transit. Every unique browser event on this pixel is backed by a server event.
100% / 100%
Dedup on event_id: browser 100% / server 100% — the two copies are matched, not doubled. One sale, one count.

Coverage solves “did it arrive” — not “does it count.” That second job is section 04.

The diagram is interactive in the HTML version: a “browser only” state shows a red slice of conversions blocked before Meta ever sees them (ad-blockers, iOS/ITP, cookie loss, dropped calls); switching on CAPI turns that slice green — recovered by the server event — with the browser/server overlap deduped on the shared event_id.

04

Match Quality: the score that decides if it counts — real data

Event Match Quality (EMQ) is a 0–10 score — higher is better. It rises with how many strong identifiers each event carries. These are the real measured scores on the test pixel:

Real EMQ per event — test pixel

Scale is 0–10, higher is better. Hover a bar to see exactly which identifiers that event carries.

The 6.1 → 8.0 gap is the whole story: a checkout Meta can confidently attribute to a person vs. cart/search events it can only guess at from a device fingerprint.
What each event actually carriesReal identifier presence on the test pixel — strong identifiers (who it is) vs. device-only signals (which browser).
EventEMQ (0–10)Strong identifiersDevice signals
InitiateCheckout8.0 · rich matchemail 100% · phone 100% · first name 100% · last name 100% · external_idfbp
ViewCart6.1 · device-only— noneIP address · user-agent · fbp · fbc
Search6.1 · device-only— noneIP address · user-agent · fbp · fbc
AddToCart6.1 · device-only— noneIP address · user-agent · fbp · fbc
6.1 → 8.0
Attach an email + phone and a device-only event climbs from 6.1 toward 8.0. Email and phone are the heavy hitters; name and external_id top it off.
0–10
EMQ is scored 0–10 — higher is better. Device-only events sit around 6; richly-identified events reach 8+.

EMQ builder — what would YOUR event score?

Toggle the identifiers an event carries. Anchored to this pixel’s two real measured scores — device-only signals score 6.1 and the full identifier set scores 8.0. The curve in between is an illustrative diminishing-returns model, not a Meta formula.

Match quality6.1 / 10

The builder is interactive in the HTML version. Device-only signals (IP address, user-agent, fbp, fbc) sit around 6.1 — Meta is guessing. Turning on email + phone (plus name and external_id) climbs the meter toward 8.0 — richly matched, Meta is confident. Email and phone drive the jump.

05

What weak match quietly costs you

Unmatched or low-match conversions don’t fail loudly. They cause three compounding harms that all look like something else.

Harm 1

Under-reported results

your numbers lie low

Your ROAS looks worse than reality — so you cut ads that were actually winning. The sale happened; the report never heard about it.

Harm 2

Worse optimization

delivery drifts

Meta targets on partial signal; delivery drifts to the wrong people and CPA rises — the slow-bleed pattern from No. 01, Efficiency & Fatigue.

Harm 3

A thinner seed

lookalikes starve

Only matched conversions can seed a lookalike — weak match shrinks and dirties the seed. That’s the doom loop of No. 03 starting one lecture early.

Low match quality doesn’t just lose one sale — it quietly makes every other number lie.
06

The fix — four steps, in order

Coverage first, identifiers second, then keep both honest.

SEND SERVER-SIDE (CAPI) for coverage

Never rely on the browser pixel alone. The server copy is the one nothing in the browser can block — it’s what gets you to 100% coverage instead of hoping.

COLLECT & HASH strong identifiers

Email and phone are the heavy hitters; add name and external_id. Phone must be full international / E.164 format to match — a local-format number silently under-matches.

DEDUP browser + server on a shared event_id

Both copies carry the same event_id so nothing is double-counted — you get the coverage of two channels and the count of one.

WATCH EMQ per event

Push your money events (Purchase, Checkout) toward 8+. A 6.1 on Search is survivable; a 6.1 on Purchase is your revenue going invisible.

Coverage gets the event to Meta. Match quality makes it count. You need both.
07

Where Pulsar fits

Pulsar’s job here is to make every event both covered and matchable before Meta sees it.

Pulsar sends server-side by default (CAPI), measures real EMQ per event, hashes identifiers correctly (including E.164 phones), dedups browser + server on event_id, and filters bots — so the events Meta receives are the ones worth learning from.

Cross-reference — see No. 03 — Garbage In, Lookalike Out: matched conversions are your only real lookalike seed. And No. 02 — Quantity vs. Quality: only qualified, matched buyers count.

1 / 8