The quality of Meta ads depends less on your targeting settings than on the conversion signal you send the platform. As automated products like Advantage+ take targeting out of your hands, this has become even more true: the system learns who to find from your conversion data. If the data is incomplete, it finds the wrong people.
Why the browser alone is no longer enough
The Pixel sends events from the browser. After iOS consent changes, ad blockers and cookie restrictions, a serious share of those events never reaches Meta. What shows up in reports as "fewer conversions" is often not fewer sales — it is fewer visible sales. The Conversions API (CAPI) sends the same event from the server; what the browser cannot see, the server can.
Three roads to CAPI — which one when
- Platform integration (Shopify, WooCommerce, etc.): The fastest, lowest-maintenance road. If your commerce stack has a native Meta integration, this is the right start for most businesses. The price is flexibility: custom events and custom fields are limited.
- Server-side GTM: You distribute events to every platform (Meta, Google, TikTok) from your own server container, from one place. Full control, you own the data; the price is setup effort and a small server cost. If multiple ad platforms run on serious budgets, the investment amortises itself.
- CDP / third-party tools: Tools like Segment or Stape absorb the engineering load. A pragmatic bridge when there is no developer on the team; the price is a monthly fee and one more layer of dependency.
Both together, with deduplication
The correct setup runs both. When Pixel and CAPI send the same purchase, the events carry the same event_id so Meta doesn't count it twice; the system deduplicates them. The most common mistake I see is here: CAPI installed, but event_id doesn't match, conversions inflate, optimisation breaks.
event_id in practice
Deduplication needs three conditions: the same event name (Purchase must be Purchase on both sides), the same event_id (a deterministic value like the order number is the most robust; randomly generated IDs are useless if each side generates its own) and a reasonable time window (the two events must arrive close together). The place to check is the event detail in Events Manager: if you don't see the "deduplicated" label, the two channels are being counted separately — your conversions inflate on paper while the bidding algorithm feeds on dirty data.
Event match quality
The EMQ score in Events Manager shows how well your events match real people. Sending customer information — email, phone, name — hashed, along with events, raises the score. Low EMQ means low learning.
What raises EMQ in practice
- Email + phone together: Noticeably stronger matching than email alone; if you collect both, send both.
- fbp/fbc cookie values: Attaching browser cookies to server events ties the server identity to the browser identity — most native integrations do this; custom builds forget it.
- Name, city, country: Small contributions that add up; all sent hashed, no clear data goes to Meta.
- Collect at event time: Attach customer information to the purchase event as it happens, not through later "enrichment"; late data never enters the match.
The testing routine
Before trusting a live setup I run a four-step lap: watch server events arrive in the Test Events tab of Events Manager; verify client events in the browser with the Pixel Helper extension; place a test order and confirm both events land and get marked "deduplicated"; and check the EMQ score after 24–48 hours. A setup that hasn't passed this lap doesn't count as "done" — because a broken CAPI is worse than no CAPI: it gives false confidence.
The five mistakes I see most in the field
- Double counting: CAPI installed, no event_id. Conversions "grew" overnight on the dashboard; while the team celebrates, the bidding algorithm learns from garbage. The symptom is a sudden, unexplained conversion jump.
- A half event set: Purchase goes from the server but the top of the funnel (ViewContent, AddToCart) only from the browser. With asymmetric signal loss, the system's funnel picture warps.
- Empty customer information: CAPI technically works, but no email/phone travels with the events. EMQ stays low and the gain stays on paper. CAPI's value is in the match data it carries; sending empty envelopes isn't worth the postage.
- Test events left in production: A test event stream or trial values bleed into live data. Separating test traffic at launch is a five-minute job; not separating it means weeks of dirty data.
- Set and forget: Installed once, unchecked for years. The site gets redesigned, the theme changes, events silently break. Five minutes in Events Manager once a month manages this entire risk.
Setup quick checklist
- Do Pixel and CAPI send the same event set (not just Purchase)?
- Does every event carry a deterministic event_id, identical on both sides?
- Do events show as "deduplicated" in Events Manager?
- Do hashed email + phone travel with the events?
- Are fbp/fbc values attached to server events?
- Is the domain verified?
- Is the EMQ score checked regularly?
My standard
When I take over a Meta account: Pixel via GTM; CAPI via server-side GTM or platform integration; event_id on every event; domain verification for aggregated measurement; and diagnosis with test events. Until these are done I don't discuss creative or audiences, because you cannot optimise an account that flies blind.
Short questions, short answers
Is CAPI worth it on a small budget? With a native platform integration, yes — near-zero cost, hard-to-recover loss. The server-side GTM investment is a step I don't rush below a certain spend scale.
How soon do results show after CAPI? Reports change as soon as the signal heals (more conversions become visible); the optimisation effect settles within weeks as the system learns from the new data.
What's the Google-side equivalent? The same logic: enhanced conversions and offline conversion import. Once the signal architecture exists for one platform, porting it to the second is half a day.