Meta Pixel + Conversions API Setup Guide

When a store owner shows us an Ads Manager screenshot with a 4x ROAS and a bank account that says otherwise, the cause is usually not the ads. It is the data the ads are judged on. Meta's pixel alone misses a share of purchases, and a half-finished Conversions API setup can count the same purchase twice. Either way the number you scale on is wrong, and so is the signal Meta's algorithm learns from. This guide explains what the pixel and the Conversions API (CAPI) each do, how to set them up so they agree with your store, and the checks we run before we spend a dollar for an e-commerce brand.

Pixel vs Conversions API in plain terms

The Meta pixel is a piece of JavaScript on your site. When a visitor views a product, adds to cart or buys, their browser sends an event to Meta. It is easy to install and it is the source of most browser-side detail, but it depends on the browser cooperating. Ad blockers, browser privacy features, cookie restrictions, slow pages that close before the script fires and people who decline tracking all mean some events never arrive.

The Conversions API sends events from a server instead of the browser: your store platform, a tag server or Meta's own gateway tells Meta "order #1043 happened, value $57, currency USD" along with hashed customer details such as email and phone. It does not depend on the visitor's browser, so it fills many of the gaps. It does not replace the pixel. Meta's recommendation, and ours, is to run both and let Meta deduplicate them.

Why this matters for profit and not just for reports:

Under-counting makes good ads look bad. If 20% of purchases never reach Meta, a campaign really at 2.8 ROAS shows 2.2, and you might switch off the best thing in the account.
Over-counting makes bad ads look good. If the pixel and CAPI both report a purchase and deduplication fails, Ads Manager can show nearly double the real sales. This is the more dangerous error, because it tells you to scale.
The algorithm learns from what you send. Purchase-optimized campaigns look for more people like the ones who bought. Missing or duplicated purchases blur that picture, and delivery gets worse over time.

Three ways to set it up

Which route fits depends on your platform and how much technical help you have. All three can work; the wrong choice is usually the one nobody maintains.

Route	Best for	Watch out for
Platform partner integration (Shopify, WooCommerce, BigCommerce and others)	Most small stores. A few clicks, sends both browser and server events.	Old theme code or a second app still firing its own pixel, which causes duplicates.
Conversions API Gateway or a server-side tag manager	Custom sites, several data sources, teams that want control over what is sent.	Hosting cost and someone who owns it. A server tag that silently breaks after a site update is worse than none.
Direct API integration by a developer	Custom checkouts, subscription apps, offline or phone orders.	Getting deduplication and customer parameters right is on you.

On Shopify, which most of the DTC brands we talk to use, the usual path is Meta's sales channel app with data sharing set to the highest level your privacy setup allows. Integration names and settings change, so follow what the app shows today rather than any screenshot from a blog post, including ours.

Deduplication: the step that breaks most setups

When both the pixel and CAPI send the same purchase, Meta needs to know it is one order, not two. It matches them using the event name and an event ID: the browser event and the server event must carry the same name (for example "Purchase", with the same spelling and capitalization) and the same event ID, usually the order ID or a value generated at checkout. Meta also uses other identifiers to deduplicate, but a matching event ID is the reliable way.

Where it goes wrong in practice:

Two installations. The partner app sends pixel and server events with matching IDs, but an old pixel snippet in the theme or a Google Tag Manager tag also fires "Purchase" without an ID. That second browser event cannot be matched and is counted.
Different event names. The server sends "Purchase" and the browser sends "purchase" or a custom event like "OrderComplete".
IDs that do not match. The browser uses the checkout token, the server uses the order number.
Thank-you page reloads. A customer refreshes or revisits the order confirmation page and the pixel fires again. A stable event ID lets Meta drop the repeat.

In Events Manager, open the Purchase event and look at the deduplication and event source details. You want to see both browser and server events received and a high share deduplicated. If you see purchases from the server only, or browser purchases with no event IDs, fix that before anything else.

Not sure your Meta tracking counts real sales? Book 30 minutes with Nick. You leave with a concrete 7-day ad test, whether you hire us or not.

Book a free call →

Event Match Quality and what to send

A server event is only useful if Meta can tie it to a person who saw or clicked an ad. That is what Event Match Quality (EMQ) in Events Manager estimates, on a scale up to 10. It rises when you send more customer information parameters, hashed: email, phone, first and last name, city, postal code, country, plus the click ID (fbc) and browser ID (fbp) that the pixel stores, and the client IP address and user agent.

We do not chase a specific score, because what is achievable depends on your checkout and on what customers agree to share. What we look for is that the Purchase event sends at least email, the fbc and fbp values when they exist, IP and user agent. Most partner integrations handle this; custom setups often send only the order value and nothing that identifies the buyer, which gives Meta a purchase it cannot connect to any ad.

Also check the boring fields. Every Purchase should carry value and currency. A Canadian store selling in CAD and USD must send the currency of the actual order, or Meta will treat a CAD 80 order as USD 80. Decide whether value includes shipping and tax, and use the same definition when you calculate your break-even ROAS, or the two numbers will never be comparable.

How to test before launch

This takes about an hour and saves weeks of wrong decisions:

Inventory every tag. Use the Meta Pixel Helper browser extension and your tag manager to list everything that fires Meta events on the site. There should be one source for the pixel, not three.
Run Test Events. In Events Manager, open Test Events, visit your site through it and go from a product page to a real order (use a discount code or refund it). Check that PageView, ViewContent, AddToCart, InitiateCheckout and Purchase arrive, each from browser and server where expected.
Check the Purchase payload. Value, currency, content IDs that match your catalog and an event ID. Compare the value to the order in your store admin.
Check deduplication. Your test order should appear as one purchase, not two.
Verify your domain in Business Settings and review the event setup Meta shows for it. Meta has changed its rules around event configuration for iOS traffic several times since 2021, so check what your account currently asks for rather than following an older checklist.
Look at diagnostics. Events Manager flags problems such as missing parameters, duplicate events or a drop in server events. Read them; they are usually right.

The weekly reconciliation that keeps ROAS honest

Even a correct setup drifts. Apps update, someone edits the theme, a checkout extension changes. So once a week we compare three numbers for the same seven days:

Orders in your store (total, and ones with Meta UTM tags).
Purchases Meta received in Events Manager (all purchases, not just attributed ones).
Purchases attributed to ads in Ads Manager.

Events Manager purchases should be close to your store's total orders. If Meta receives noticeably more purchases than you had orders, you have duplicates. If it receives far fewer, events are being lost. Attributed purchases will always be lower than total orders, because not every order comes from ads, and higher than UTM-tagged orders, because Meta counts view-through and cross-device conversions that UTMs miss. If attributed purchases are close to or above your total orders, Meta is taking credit for sales that came from email, search or word of mouth, and you should judge the program by blended revenue divided by total ad spend instead.

We also keep a simple rule for decisions: Ads Manager ROAS is for ranking ads against each other, and store numbers are for deciding whether to spend more. On Biocoiff, an organic hair-care brand, we tested 28 campaigns, cut 9 and scaled the best 4 by 20% a month, with purchase campaigns reaching up to 8x ROAS. Cutting and scaling that confidently only works when the purchases behind the ROAS are real.

Consent and privacy

Sending customer data to Meta from your server does not remove your privacy obligations. Email and phone are hashed before sending, but you still need a privacy policy that covers ad tracking and, depending on where your customers are, consent before tracking. Canadian stores should pay attention to Quebec's Law 25; stores with California customers to the CCPA/CPRA; and US state laws keep multiplying. This is not legal advice. Ask your platform what its consent tools pass to Meta, and if you are unsure, ask a privacy lawyer. A setup that respects consent and sends fewer events is better than one that sends everything and creates a liability.

A short checklist

One pixel source on the site; old snippets and duplicate apps removed.
Conversions API on, through your platform's partner integration where possible.
Purchase sent from browser and server with the same event name and event ID.
Value and currency on every purchase, matching your store's definition of revenue.
Email, fbc, fbp, IP and user agent sent with purchases where allowed.
Domain verified; event setup reviewed in Events Manager.
A test order shows up once, with the right value.
Weekly: store orders vs Events Manager purchases vs attributed purchases.

Once tracking is clean, the rest of the testing process in our e-commerce testing playbook becomes far more reliable, because every cut and scale decision rests on purchases that actually happened.

More on how we run ads for online stores: e-commerce ads.

FAQ

Do I still need the Meta pixel if I use the Conversions API?

Yes. Meta recommends running both. The pixel captures browser-side detail, the Conversions API fills gaps from blockers and privacy settings, and Meta deduplicates the two using the event name and event ID.

Why does Ads Manager show more purchases than my store?

Usually duplicate events: an old pixel snippet or second app fires Purchase without a matching event ID, so Meta counts it twice. Attribution can also credit ads for orders that came from email or search.

What Event Match Quality score should I aim for?

There is no universal target. Send hashed email, phone where you have it, the fbc and fbp values, IP and user agent with purchases, within what your customers consent to, and watch the trend in Events Manager.