When Meta Ads Manager and your back office don't match up, the cause usually comes down to one of three things: the event never fired, it fired twice, or it fired but Meta couldn't match it to an account. Here's how the system actually works, and what to check when the numbers don't line up.
What conversion tracking is
Conversion tracking links specific actions on your website or app back to the ad that drove them, so Meta can report on results and optimize toward more of them. Measurement is what you look at; optimization is what you're actually paying for — they're related, but not the same thing.
Three things make this work: an event source (the Meta Pixel in the browser, the Conversions API from your server, or both), a dataset in Events Manager where those events land, and an attribution setting in Ads Manager that decides which ad gets credit.
Meta Pixel vs. Conversions API
| Meta Pixel | Conversions API | |
|---|---|---|
| Where the event fires | In the visitor's browser | On your server, platform, or CRM |
| Blocked by ad blockers / Safari ITP | Yes | No |
| Event types | Web only | Web, app, offline, messaging |
| Setup effort | Low — paste a snippet | One click to more involved, depending on the route |
The Pixel is a snippet of code in your site's <head> that fires when someone takes a tracked action. It's easy to set up, but it's also the first thing blocked — by ad blockers, Safari's Intelligent Tracking Prevention, declined cookie consent, or slow-loading pages.
The Conversions API (CAPI) sends the same events directly from your server instead, so it isn't affected by any of that. There are a few ways to set it up, from a fully custom integration to Meta's one-click option, which mirrors your Pixel events server-side automatically.
Why you need both, not just one: the Pixel sees what happens in the browser; CAPI catches what the browser hides. Meta then removes the duplicates — but only if both sources send the same event name and event ID. Without that shared ID, the same purchase can get counted twice, which throws off both your cost-per-result and what Meta's algorithm optimizes toward.
The events worth knowing
Meta recognizes 17 "standard events" out of the box — named actions like ViewContent, AddToCart, InitiateCheckout, Purchase, and Lead. Using these standard names, rather than inventing your own, matters, since Meta's systems are trained on them across millions of advertisers.
| Event | Fires when | Used for |
|---|---|---|
| ViewContent | A product or key page is viewed | Retargeting, top-of-funnel signal |
| AddToCart | A product is added to cart | Mid-funnel optimization, cart abandoners |
| InitiateCheckout | Checkout begins | Strongest pre-purchase signal in e-commerce |
| Purchase | An order completes | Value optimization, ROAS, lookalike audiences |
| Lead | A form or inquiry is submitted | The primary event for lead generation |
Beyond standard events, custom conversions are rules built from your existing data without any code (e.g. "purchases over €200"), and custom events cover actions Meta has no built-in name for. Offline conversions — in-store purchases, deals closed weeks after a click — get sent through the Conversions API too, matched using hashed customer information.
Attribution windows
An attribution window decides how long after seeing or clicking an ad a conversion still counts toward it. The default is 7 days after a click, 1 day after a view. Since March 2026, only link clicks count toward click-through attribution — reactions, comments, shares, and longer video views now fall under a separate "engage-through" category instead. Nothing about your billing changes here, but it does shift which column a conversion shows up in.
iOS privacy settings still affect how much of this Meta can see directly — Apple's App Tracking Transparency requires explicit opt-in before Meta gets device-level data, so a meaningful share of iOS conversions arrive delayed or modeled rather than tracked in real time. This is one more reason server-side tracking (CAPI) matters: it isn't affected by what happens on the device.
Event Match Quality: the score worth checking
Event Match Quality (EMQ) is a 0–10 score showing how well the customer information your server sends actually matches to a real Meta account. Treat 6.0 as the functional minimum and 8.0 as the real goal — a declining EMQ score tends to show up in your cost-per-result days before anything else does.
The most common mistake: accidentally sending your server's IP address and user agent instead of the visitor's. That alone can cap an account's score around 4.0. To raise it: send hashed email and phone number (not just email), include an external ID, and use fresh tracking identifiers rather than cached ones.
Setting it up, in order
- Create or open your dataset in Events Manager.
- Install the base code — manually, through a platform integration, or via Google Tag Manager.
- Map your events to actual funnel moments before building anything — skipping this step means rebuilding later.
- Add your events, building Purchase manually so it carries value and currency.
- Turn on the Conversions API — the one-click option covers most cases.
- Set the same event ID on both the Pixel and CAPI copies of each event.
- Choose your attribution setting deliberately at the campaign level, rather than leaving it on the default.
- Verify everything is firing correctly before spending real budget.
What to optimize for, by business type
| Business type | Optimize for | Also send | The trap |
|---|---|---|---|
| E-commerce | Purchase (with value + currency) | ViewContent, AddToCart, InitiateCheckout | Under ~50 purchases a week, ad sets can get stuck without enough data — optimizing on InitiateCheckout instead can help |
| Lead generation | Lead | ViewContent, Contact | Meta can't judge lead quality on its own and will optimize for volume — send qualified leads back through CAPI |
| SaaS / subscription | StartTrial, then Subscribe | CompleteRegistration | Leaving this on "all conversions" can skew results toward renewing customers rather than new ones |
Testing before you trust it
Before relying on any of this: install the Meta Pixel Helper browser extension to confirm events fire, run real test conversions through Events Manager and check the parameters that arrive (value, currency, content IDs), compare browser vs. server event counts (they should be close, with deduplication showing as active), and check the Diagnostics tab weekly for dropped parameters.
One thing worth knowing upfront: Ads Manager reports a conversion on the day someone interacted with the ad; most back-office systems report it on the day the order was placed. A week-to-week comparison between the two will never match exactly — look at the trend, not a single day's numbers.
The most common mistakes
- Pixel and CAPI fire without a shared event ID — events get counted twice, and reported costs look artificially low.
- Purchase fires again on a page refresh or back-button return — it should trigger on order confirmation and deduplicate by order ID.
- Purchase is missing value and currency — the single most common gap, and it means there's nothing for value-based optimization to actually optimize.
- Account-level issues get overlooked — a restricted ad account or missing permissions stops events from reaching campaigns no matter how well the tracking itself is built.
Getting this right is part of how we run paid ads campaigns for clients, not an extra step — see real results from accounts where tracking was actually set up properly.
