Get your Meta CAPI tracking to 95%+ accuracy guaranteed in writing.
Partner integrations and app-store plugins will happily turn CAPI on for you. What they send is a Purchase with an email, no fbc, no fbp, no external_id, and an event_id that doesn't match the one the Pixel sent — so Meta either can't match the person or counts the sale twice. We build CAPI from your backend, share one event_id with the Pixel, and pass the full matching payload.
Free30 minutesNo obligation
Meta CAPI · what breaks
How CAPI usually goes wrong
- 01
Event Match Quality sits at 4 or 5 and nobody knows why
The server event carries a hashed email and nothing else. EMQ is a function of how many matching signals you send — em, ph, fn, ln, ct, st, zp, country, external_id, fbp, fbc, client IP and user agent all contribute, and most integrations send two of them.
- 02
Purchases are counted twice in Ads Manager
Both the Pixel and the server send a Purchase, but the event_id differs — the browser generates a random ID while the plugin uses the order number, or one side omits it entirely. Meta has no key to dedupe on, so it keeps both.
- 03
fbc is missing because nobody stored the click
The fbclid arrives in the landing URL and is gone by checkout. Without fbc reconstructed from the stored click ID and timestamp, the server event loses its single strongest attribution signal and falls back to probabilistic matching.
- 04
Purchase fires on page load, not on a real order
A confirmation-page trigger fires on refresh, on back-button, and on customers who reach the page without paying. Meanwhile the buyers who never land there — bank redirect, app handoff, abandoned tab — never register at all.
Meta CAPI · the fix
What a properly built CAPI setup gives you
Deduplication that Meta can actually perform
The Pixel and the server send the same event_name and the same event_id, generated once from your order ID. Events Manager shows the pair collapsing into one, and you can watch it happen in the deduplication view.
Event Match Quality in the 8+ range, guaranteed in writing
Full advanced matching from the order record — hashed email, phone in E.164, name, city, state, ZIP, country, external_id — plus fbp, fbc, IP and user agent forwarded server-side rather than dropped.
Purchase reflects money received, not pages viewed
The event fires when your backend creates the paid order, so refunds, failed payments and test orders can be excluded, and value matches what your accounting system says you took in.
Meta's optimization stops learning from the wrong people
Advantage+ and lookalike seeding are only as good as the events feeding them. When high-EMQ Purchase events with correct values arrive, the audience the algorithm chases starts to resemble your actual buyers.
Meta CAPI · architecture
How one purchase becomes one deduplicated Meta event
Deduplication is not a setting you turn on. It is the consequence of the Pixel and your server agreeing on an event name and an event_id that was minted once, in one place.
- 1
fbclid captured and persisted at landing
The click ID arrives in the landing URL, is stored first-party with its timestamp, and is reassembled into a correctly formatted fbc value at conversion time.
- 2
event_id minted once from the order ID
One deterministic ID is derived from your order or lead ID, written into the dataLayer for the Pixel and reused verbatim by the server event.
- 3
The Pixel sends the browser copy
The browser event carries fbp, the browser context and the shared event_id, and it keeps doing so because removing the Pixel is not the goal.
- 4
Your backend sends the server copy
At paid-order creation, the server container sends Purchase with full advanced matching, external_id, fbp, fbc, client IP and user agent.
- 5
Meta collapses the pair, we watch the rate
Events Manager shows the two copies merging into one, and the dedup rate and EMQ are monitored afterward so a plugin release cannot quietly undo it.
Meta CAPI · events
The Meta event map we build to, parameter by parameter
Every row names the real standard event and the real parameter keys Meta expects.
| Event | Fires when | Key parameters | Sent from |
|---|---|---|---|
| PageView | Any page loads | fbp, fbc, client_ip_address, client_user_agent, event_id | Browser and Server |
| ViewContent | The product view renders with its data | content_ids, content_type, value, currency, event_id | Browser |
| AddToCart | The cart API confirms the line item | contents[], content_ids, value, currency, event_id | Browser and Server |
| InitiateCheckout | A checkout session is created | num_items, contents[], value, currency, event_id | Browser |
| Purchase | The backend creates the paid order | value, currency, event_id from order_id, contents[], em, ph, fn, ln, ct, st, zp, country, external_id, fbp, fbc | Server, deduped with the Pixel |
| Lead | Your CRM accepts the lead record | value, currency, event_id from lead_id, em, ph, external_id, lead_event_source | Server |
| Subscribe | The first recurring payment settles | value, currency, predicted_ltv, event_id, external_id | Server |
Meta CAPI · prove
How we prove the events match and do not double count — Meta CAPI
Two numbers decide whether a CAPI build worked: Event Match Quality per event, and whether Meta's Purchase count equals the orders you were paid for.
Source of truth
Paid orders in Shopify, WooCommerce or Stripe, the same rows your accountant uses
- Compare Meta Purchase count and value against paid orders day by day, not just as a total for the month.
- Open the deduplication view in Events Manager and confirm browser and server copies collapse rather than stack.
- Read EMQ per event and check which matching parameters arrive populated versus empty in the payload sample.
- Place a live order and confirm one Purchase, one event_id, from both sources in Test Events.
- Confirm refunded and failed payments are excluded so reported value never outruns money actually banked.
- Recheck EMQ and dedup rate at day 30 to catch a theme or plugin release that changed the dataLayer contract.
Meta CAPI · free audit
What we check in the free audit
- Event Match Quality sits at 4 or 5 and nobody knows why
- Purchases are counted twice in Ads Manager
- fbc is missing because nobody stored the click
- Purchase fires on page load, not on a real order
Checked against
Paid orders in Shopify, WooCommerce or Stripe, the same rows your accountant uses
Free30 minutesNo obligation
Meta CAPI · when not to buy
When your existing CAPI connection is good enough
The native integrations are not worthless, and sometimes they are the right answer.
- Your EMQ already sits at 7 or 8 and Ads Manager purchases line up with your order count. The integration is doing its job.
- You spend a few hundred dollars a month. Matching quality is not your constraint yet; creative and offer are.
- Your real conversion closes in a CRM weeks after the click. That is an offline conversion upload project, not a CAPI rebuild.
- You want server events sent regardless of the consent state the visitor chose. We will not build that, so hire someone else.
Meta CAPI · what we deliver
What the Meta CAPI build includes
Dataset audit before anything is rebuilt
Current EMQ per event, deduplication rate, which parameters arrive and which are empty, and how many events your existing integration is dropping or duplicating. You get this whether or not you hire us for the rebuild.
Server container on your own subdomain
A GTM server container on something like data.yourdomain.com. First-party context means fbp is set in a first-party cookie with a real lifetime instead of being truncated by ITP.
Shared event_id strategy across browser and server
One deterministic ID derived from the order or lead ID, written into the dataLayer and reused by the server event. Documented so your developers don't accidentally break it in the next release.
Full advanced matching from the order record
All matchable customer parameters normalized and hashed server-side, plus external_id keyed to your customer ID so returning buyers are recognized across sessions and devices.
Click ID capture and persistence
fbclid captured at landing, stored first-party with its timestamp, and reassembled into a correctly formatted fbc value at conversion time — so a purchase five days after the click still carries the click.
Backend reconciliation and a 30-day watch
We compare Meta Purchase count and value against your order records for the validation window, then monitor EMQ and dedup rate afterward so a plugin update doesn't quietly undo the work.
Written guarantee
95%+ tracking accuracy
Measured against Paid orders in Shopify, WooCommerce or Stripe, the same rows your accountant uses. Miss it and we keep working at no cost.
FAQ
Meta CAPI questions, answered
It's a real CAPI connection, so it's not worthless. The limits are consistent: a thin matching payload, no reliable fbc, and an event_id scheme you don't control. If your EMQ is above 7 and Ads Manager purchases line up with your order count, keep it. If neither is true, the integration is the reason.
No. Meta expects both. The browser Pixel contributes fbp, browser signals and events the server can't see; the server contributes reliability and backend truth. Running both with a shared event_id is the supported design — the redundancy is the point, and deduplication is what makes it safe.
By sending more matchable signals, correctly formatted. Email and phone alone get you to the middle of the scale. Adding name, city, state, ZIP, country, external_id, fbp, fbc, client IP and user agent — all normalized before hashing — is what moves it. It also requires that your checkout collects those fields; if you only capture an email, we'll tell you the ceiling before you sign.
It does not, and anyone who says otherwise is selling something. ATT governs what Meta may do with the data for attribution and targeting. CAPI's job is to make sure the event reaches Meta at all when the browser tag is blocked or truncated, and to carry enough signal to match. Those are different problems.
No, and we won't build it that way. Server-side is not a route around a user's choice. We wire Consent Mode v2 and your CMP categories so events respect the state the visitor selected, and we document exactly what gets sent under each one. Your legal team reviews that document; we don't make compliance promises on your behalf.
If you're spending a few hundred dollars a month, your EMQ is already 7 or 8, and Ads Manager purchases match your Shopify orders closely, the native integration is doing its job — spend the money on creative instead. Also skip it if your real conversion happens weeks later in a CRM; then the work is offline conversion upload, not CAPI.
Far less than a browser-only setup, because the money event originates from your backend rather than from markup on a page. The parts that can drift are the dataLayer contract and the event_id. Both are documented in the handover spec, and the 30-day watch exists precisely to catch a release that changes them.
More on Meta CAPI
- GuideMeta Pixel vs Conversions API: What Each One Misses (And Why You Need Both)
- GuideEvent Match Quality Is Low: Why Your Meta EMQ Score Sucks and How to Raise It
- GuideDuplicate Purchase Events Are Wrecking Your Ad Data — Find and Fix Them
- Pixel vs CAPIMeta Pixel vs the Conversions API
- LinkedIn CAPILinkedIn tracking that reports pipeline, not form fills
- sGTM vs CAPI GatewayServer GTM vs Meta's Conversions API Gateway
Free · 30 min
Send me your Events Manager screenshot
WhatsAppFree30 minutesNo obligation
