Meta Conversions API vs the pixel: the mechanics.
What the browser pixel sees and misses, what the Conversions API adds, how deduplication works down to the payload, which parameters move Event Match Quality, and how to pick between server-side tagging, direct CAPI and the platform's own integration. Written from the side of the person who has to explain the purchase count to finance.
By Daria Dovzhikova · Updated September 2026
TL;DR
- The pixel reports what the browser lets through. The Conversions API reports what your server knows. Meta's recommended setup is both, sharing the same events.
- Both means deduplication: identical event_name and identical event_id on the browser and server copies, received within 48 hours. Different ids double your purchases; a missing channel halves them.
- Event Match Quality is a score out of 10 on server events. Hashed email, hashed phone, the visitor's IP with user agent, fbp and fbc move it. IP, user agent, fbp and fbc must never be hashed.
- Server-side tagging is a place to run this, not the API itself. Pick platform-native, direct CAPI or sGTM by who will own it after launch.
What the pixel sees, and what it misses
The Meta pixel is JavaScript in the page. It fires when the page runs it, and the event reaches Meta when the browser completes the request. Every step in that sentence is a place to lose the event: a content blocker that never loads the script, a consent banner the visitor declined, an iOS session with restricted storage, a one-page checkout whose confirmation step renders without a page load, a request that starts as the visitor closes the tab.
None of that is a bug in your setup. It is the browser doing what browsers do in 2026. The pixel still matters, because it is the copy that carries the browser identifiers (the _fbp cookie and the click id) that make matching cheap. It is simply no longer the copy you can count on for coverage.
What the Conversions API is, and is not
The Conversions API is a server-to-server channel. Your backend, a server container or a platform integration sends the event to Meta directly, and Meta processes it the same way it processes a pixel event, against the same dataset. Meta's best-practice guidance is explicit: use the Conversions API in addition to the pixel, share the same events through both, because the server copy carries events the pixel loses to connectivity and page-loading failures.
What it is not: a matching engine that finds the person for you. A server event with no customer information is an anonymous row. The API gives you a reliable channel; you still have to put email, phone, IP and the browser ids in the payload. That is where Event Match Quality comes from, and it is the section below the payload.
The three setups
| Setup | Coverage | Dedup risk | EMQ ceiling | Effort |
|---|---|---|---|---|
| Pixel only | Whatever the browser lets through. Blockers, declined consent, iOS restrictions and pages that never finish loading all drop events. | None. One channel, one copy of each event. | Capped by what the browser can see: fbp, fbc, IP and user agent. No email or phone unless the page collects them and the tag is wired to pass them. | Lowest. A tag in the page. |
| CAPI only | Every event your server knows about, including ones the browser never fired. Misses signals the browser owns unless you forward them. | None, and no browser fallback either. If your server integration breaks, reporting drops to zero. | Highest ceiling: hashed email, phone, name, external_id plus IP and user agent if you forward them. | Medium to high. Server code or a platform integration, plus a way to carry browser identifiers to the server. |
| Pixel and CAPI with deduplication | Union of both. Meta's own recommended setup. | The whole game. Same event_name plus the same event_id on both copies, or Meta counts the purchase twice. | Highest in practice: the browser copy carries fbp and fbc, the server copy carries the hashed customer data, Meta matches across both. | Highest, once. Then it is the setup that survives the next platform change. |
Deduplication, down to the payload
One purchase. Two copies of the Purchase event: one from the browser, one from the server. Meta's deduplication doc sets the rule: the pixel's eventID must match the API's event_id, and the pixel's event must match the API's event_name. Meta deduplicates only if the second copy arrives within 48 hours of the first, and when the two do not differ meaningfully it generally keeps whichever arrived first.
The browser copy. Meta's pixel reference recommends passing the id as the fourth argument to fbq('track'); Purchase also requires value and currency:
fbq('track', 'Purchase',
{ value: 249.00, currency: 'USD', content_ids: ['SKU-1042'], content_type: 'product' },
{ eventID: 'order_88213' }
);The server copy, same order, same id. Customer fields normalised and SHA-256 hashed per Meta's parameter rules; IP, user agent, fbp and fbc sent in the clear because Meta says they must never be hashed:
POST https://graph.facebook.com/v21.0/{DATASET_ID}/events
{
"data": [{
"event_name": "Purchase",
"event_time": 1789040000,
"event_id": "order_88213",
"action_source": "website",
"event_source_url": "https://shop.example.com/checkouts/thank-you",
"user_data": {
"em": ["<sha256 of trimmed, lowercased email>"],
"ph": ["<sha256 of digits-only phone with country code>"],
"fn": ["<sha256 of lowercased first name>"],
"client_ip_address": "203.0.113.42",
"client_user_agent": "Mozilla/5.0 ...",
"fbp": "fb.1.1789039000000.1234567890",
"fbc": "fb.1.1789039000000.IwAR0...",
"external_id": ["<sha256 of customer id>"]
},
"custom_data": { "value": 249.00, "currency": "USD", "content_ids": ["SKU-1042"] }
}]
}Three outcomes. Same id, both copies inside 48 hours: Meta counts one purchase and keeps the richer union of the two. Different ids (the marketing site generated one, the checkout generated another): Meta counts two purchases, your reported cost per purchase halves, and the algorithm optimises against a doubled signal. One copy missing: Meta counts whatever arrived, which for a pixel-only setup on a blocked browser is nothing.
Without an id at all, Meta falls back to event_name plus fbp and/or external_id. That fallback works for a single browser session. It does not save you when the server copy never received the fbp cookie in the first place, which is the usual case on hosted checkouts.
Event Match Quality: what moves it
Meta scores each server event type out of 10 on how well the customer information can be matched to an account. Two things move it more than anything else: hashed email, because it is the identifier Meta holds for almost every account, and the pair of client IP and user agent, because together they let Meta match a session even when no login identifier is present. The browser identifiers (fbp, fbc) carry the paid-click context. Hashing rules and normalisation are Meta's, linked in the table.
| Parameter | What it does for matching | Hashed |
|---|---|---|
| em (email, SHA-256) | Most. Trim, lowercase, hash. The single parameter that turns an anonymous event into a matched one. | Yes |
| ph (phone, SHA-256) | High. Digits only with country code, no leading zeros, then hash. | Yes |
| fn, ln (name, SHA-256) | Medium on their own, useful alongside email. | Yes |
| client_ip_address | High when paired with user agent. The server must forward the visitor's IP, never its own. | Never |
| client_user_agent | Pairs with IP. Forward the browser's string unchanged. | No |
| fbp (browser id) | High. The _fbp cookie value. Also one of the fallback dedup keys. | No |
| fbc (click id) | High for paid traffic. Built from the fbclid on the landing URL. | No |
| external_id | Medium. Your own customer id, consistent across channels. Hashing recommended, not required. | Recommended |
Parameter list and hashing rules from Meta's customer information parameters and best practices. The relative weight column is practitioner reading of those docs, not a published Meta ranking.
Where to run it: platform, direct, or server-side tagging
Server-side tagging is often sold as the answer, and it is one answer. Google's server container runs on Cloud Run, App Engine or a host of your choice (Stape is the common managed option), receives events from the browser on a first-party subdomain, and fans them out to Meta and everyone else. Google lists the benefits as page performance, privacy controls and data quality. The choice is about who owns the plumbing after launch.
Platform-native integration (Shopify's Meta channel, similar apps)
Choose it when: One store, standard checkout, no custom events, nobody on the team who wants to own tagging.
Watch for: You cannot see or change what is sent, and the browser copy the platform fires may not carry the same event id as the server copy it sends. Diagnose from Events Manager, not from the app's settings page.
Direct CAPI from your backend
Choose it when: You already have purchase events in your own code and a place to run server jobs. Cleanest data, full control of user_data.
Watch for: Someone has to maintain it, carry fbp and fbc from the browser to the server, and generate the event id in one place both copies can read.
Server-side tagging (sGTM, Stape or self-hosted)
Choose it when: Several tags need the same enriched event, you want first-party cookies on your own subdomain, and you would rather manage tags in a container than in code.
Watch for: One more system to host and monitor. Checkout pages on hosted platforms restrict what the browser side can do, so test with the platform's own tooling rather than GTM Preview.
One practitioner note from Stape's Shopify guide: checkout events do not show in GTM Preview because the checkout environment blocks script injection, so testing there needs the platform's own tooling. The Shopify-specific rebuild, including Web Pixels and Checkout Extensibility, is in the 2026 Shopify tracking guide.
Troubleshooting: Pixel Helper, Test Events, and what the symptoms mean
Two tools, two halves. The Meta Pixel Helper Chrome extension, which Meta has relabelled Meta Ads Data Advisor, shows the browser half: which pixels are on the page, which events fired, which parameters are missing, and it now offers to set up or repair the pixel and Conversions API through Google Tag Manager or Shopify. Events Manager shows the Meta half: what arrived, from which channel, whether it deduplicated, and the match quality it was scored. A green tick in the extension with an empty Test Events tab is the browser firing into a void.
| Symptom | How to read it |
|---|---|
| Purchases in Meta run at roughly double the order count | Two copies arriving with different ids or no id. Open Events Manager, pick the Purchase event, look at the deduplication rate. Below what your traffic mix should produce means the ids are not matching. |
| Purchases in Meta run far below the order count | One channel is silent. Test Events shows which. If browser events arrive and server events do not, the CAPI integration is down or pointing at the wrong dataset. |
| Diagnostics mention API_unavailable or a connection warning | The server channel is configured but not delivering. Check the dataset id, the access token, and whether the integration was ever completed rather than saved half way. |
| Event Match Quality sits low on Purchase | The server copy is arriving without email, phone or IP. Open the event, read the parameters received, compare with the list above. |
| Same purchase, different event ids across two domains | The marketing site and the checkout live on different systems and each generates its own id. Seen on a WordPress marketing site feeding Shopify stores: the WordPress side fired one id, the store fired another, and Meta saw two purchases for one order. The fix is one id, generated at order creation, carried to both copies. |
| Pixel Helper shows the event but Events Manager does not | The browser fired, the request never landed. Consent tooling, a blocker, or a request that failed after the page moved on. The server copy is the safety net for exactly this. |
The two-domain case in that table is the shape from a real engagement, a DTC brand with a WordPress marketing site and Shopify stores: two systems, two ids, one order counted twice, and a server channel whose diagnostics read as unavailable. The after-numbers belong to the client. The pattern is common enough that it is the first thing to check when reported purchases exceed the order count. Put your own numbers into the Attribution Leak Calculator to see which direction your gap runs.
FAQ
What is the Meta Conversions API?
A server-to-server channel for sending web, app, offline and CRM events to Meta. Server events land in a dataset and Meta processes them the same way it processes pixel events, so the ad system can optimise on them and attribute results to them. It sits alongside the pixel rather than replacing it.
Conversions API vs pixel: which one should I use?
Both, with deduplication. Meta's own guidance is to run the Conversions API in addition to the pixel and share the same events through both, because the server copy catches what the browser drops to blockers, consent and page-load failures. Running both without deduplication is worse than either alone.
How does Meta deduplicate pixel and server events?
By event_name plus event_id. The browser copy sends eventID as the fourth argument to fbq('track'), the server copy sends event_id in the payload, and the two values must be identical. Meta deduplicates only if both arrive within 48 hours of the first, and generally keeps the copy that arrived first. Without an id, Meta falls back to event_name plus fbp and/or external_id.
What happens if the event ids do not match?
Meta treats the two copies as two events. Your reported purchases inflate, cost per purchase looks better than it is, and the algorithm optimises on a doubled signal. This is the most common failure when a marketing site and a checkout run on different systems.
What is Event Match Quality?
A score out of 10 on each server event type that reflects how well the customer information you send can be matched to a Meta account. Hashed email and phone, client IP with user agent, fbp and fbc move it most. It is a property of the server channel; browser events are matched from what the browser carries.
Which customer parameters have to be hashed?
Email, phone, first and last name, city, state, zip and country must be SHA-256 hashed after normalisation (trimmed, lowercased, digits only for phone). client_ip_address, client_user_agent, fbc and fbp must never be hashed. external_id hashing is recommended but optional.
Is server-side tagging the same as the Conversions API?
No. Server-side tagging (Google's server container, hosted on Cloud Run, App Engine or a provider like Stape) is a place to receive events from the browser and fan them out to vendors. The Conversions API is Meta's endpoint. A server container can send CAPI events, and so can your own backend or a platform integration.
What does the Meta Pixel Helper show?
The Chrome extension, which Meta has since relabelled Meta Ads Data Advisor, shows the pixels on a page, the events they fire and warnings about missing parameters, and now offers to set up or repair pixel and Conversions API connections through Google Tag Manager or Shopify. It sees the browser side only. Whether an event reached Meta and deduplicated is a question for Events Manager.
Does CAPI fix attribution on its own?
It fixes coverage, which is half of attribution. It does nothing about the platform claiming purchases that another platform also claims, and it does nothing if the server copy arrives without customer information. Coverage first, match quality second, then reconcile against the order of record.
How do I check my own setup in ten minutes?
Run the Attribution Leak Calculator with last month's ad spend, platform-reported purchases and actual orders. Under-reporting with a pixel-only setup is signal loss; over-reporting with both channels is missing deduplication. Then open Events Manager, Test Events, and fire one test purchase through the browser and the server.
Want the setup fixed, with a number on both ends?
The Growth Pilot, $5,000, four weeks
Week one: server-side events, Meta CAPI with deduplication, GA4, the event layer, consent, and one reporting view finance will accept, as the baseline. Then two experiment cards run against the clean numbers, with a decision every Friday. Measured on match rate and attributed revenue, before and after.
Related guides
Purchases in Meta do not match the orders?
Thirty minutes to find out which direction the gap runs and what is causing it.