How do I set up the Meta Conversions API the right way?

What the Conversions API actually is

The Conversions API (CAPI) sends conversion events to Meta from your server instead of from the browser. The pixel still fires client-side. CAPI runs alongside it, server-side. The point is coverage. Browser events get blocked by ad blockers, iOS settings, and consent tools. Server events do not, because they leave from your infrastructure, not the visitor’s device.

The mistake I see most often is treating CAPI as a switch you flip to “fix tracking.” It is not a fix on its own. A bad CAPI build makes reporting worse than no CAPI at all, because now you have two streams that double-count or contradict each other. The architecture is what makes it work.

The two-stream model

Run the pixel and CAPI as a matched pair. Every key event fires twice: once from the browser through the pixel, once from your server through CAPI. PageView, ViewContent, AddToCart, InitiateCheckout, Purchase. Both sides send the same event for the same user action.

That sounds like double-counting, and it would be, except for one field. You send a shared event_id on both the pixel call and the server call. Meta uses that id to recognize the two events as the same conversion and keeps one. This is deduplication, and it is the single most important part of the setup. Get it wrong and your Purchase count inflates, your ROAS looks better than reality, and the account optimizes toward a number that does not exist.

So the build order is: pixel first, CAPI second, dedup keys wired before you trust a single number.

What CAPI needs to match

A server event with no identity is close to useless. Meta has to tie the event back to a person to attribute it and to optimize. You do that by passing customer information parameters, hashed with SHA-256 before they leave your server. The fields that move match quality the most:

• Email (hashed)
• Phone (hashed)
• fbp and fbc cookies, captured from the browser and forwarded to the server
• IP address and user agent
• External ID, if you have a stable customer id

The fbc cookie carries the click id from the ad click. Forwarding it is what lets a server-side Purchase get attributed back to the specific ad that drove it. Skip it and you lose attribution on a large share of conversions even though the event itself arrived.

Match quality shows up in Events Manager as the Event Match Quality score per event. Below “Good” on Purchase, fix identity before you touch anything else.

How to send the events

There are three common paths, in rough order of how much control they give you.

Direct server-to-server. Your backend posts events to the Graph API endpoint. Most control, most match potential, most engineering. This is the right call for a custom stack or a high-spend account where match quality pays for itself.

Server-side Google Tag Manager (Stape or your own container). The browser sends events to a server container you own, and that container forwards them to Meta with full data. This is what I reach for on Shopify and most lead-gen sites. You get server-side identity and dedup without writing API calls by hand, and one container can feed Meta, GA4, and TikTok from the same event stream.

Native platform integration. Shopify’s built-in Meta channel and partner connectors send CAPI for you. Fast to turn on. The catch is you give up control of dedup keys and the exact data sent, so verify in Events Manager that events deduplicate and match well before you rely on it. I have seen native integrations that send a second Purchase with no event_id, which inflates counts. Check, do not assume.

Verify before you trust it

Setup is not done when the connection turns green. It is done when you have confirmed the numbers reconcile.

1. Open Events Manager and check that each event shows both “Browser” and “Server” as sources.
2. Confirm the deduplication rate is high. Low dedup means your event_id is not matching across the two streams.
3. Check Event Match Quality on Purchase and Lead. Push the weak ones up with more identity fields.
4. Compare Meta’s reported Purchase count against your real backend over the same window. Shopify orders, your CRM, your database. If Meta is meaningfully higher, you have a dedup or double-fire problem. If it is much lower, you have a coverage or match problem.

That last step is the one people skip, and it is the only one that tells you the truth. The platform UI will happily show you a healthy-looking setup that is double-counting. Reconciling against the source of record is how you catch it.

Where it sits in the stack

CAPI is one layer of a tracking stack, not the whole thing. It depends on a clean event layer feeding it, consistent event names across pixel and server, and a consent setup that does not strip the data you need. If your GA4 and Meta numbers already disagree, adding CAPI on top of a broken foundation just gives you a third number to reconcile. Fix the event layer and identity capture first, then add the server stream, then verify it reconciles. In that order it earns its place. Out of order it adds noise.