Pixel, CAPI and event match quality: getting conversion data back to Meta

Tracking problems come from a short list: events that never fire, a domain that is not configured, consent banners blocking the script, or a server connection and a pixel that are not deduplicating against each other. The symptom is the same in every case, which is why people guess, and guessing here is expensive because everything downstream depends on it.

1. Use the Pixel Helper on your key pages and confirm each event fires once, with the parameters you expect. Once matters: a tag manager installed twice is a common and invisible cause of inflated numbers.
2. Verify your domain and check Aggregated Event Measurement is configured, with your most valuable event prioritised. An unverified domain silently limits what can be optimised for.
3. Confirm deduplication between server and browser events, and that Event IDs are being sent. The deduplication section covers what to look for.

Consent banners deserve their own check. If your banner blocks the pixel until a visitor accepts, everyone who declines or ignores it is invisible, and how much traffic that represents depends on your market and your banner design. The events are not lost because something is broken; they were never permitted to fire.

The Conversions API sends conversion events from your server to Meta directly, instead of relying on a script in the visitor's browser. It is not optional if you are serious about advertising on Meta. Browser-only tracking loses a meaningful share of conversion signal by default, and the server path recovers it.

Why the browser path leaks: script blockers, privacy settings, consent refusals, and the tracking restrictions covered below. None of those affect a call made from your own server, because there is no browser in the way. A purchase recorded in your backend is a fact you control.

What it changes in practice is optimisation quality rather than reporting vanity. More complete conversion data means the model is learning from more of your actual customers, so the same budget finds better people. That is why this is worth engineering effort in a way most tracking work is not.

It does need doing properly. A server connection sending events the browser is also sending, without a shared identifier, produces double counting rather than better data, and the algorithm optimises toward a number that does not exist.

When the browser pixel and the server connection both send the same conversion without a deduplication mechanism, Meta counts it twice. That inflates your reported conversions and feeds the algorithm incorrect signal, which is the more expensive half of the problem: your reporting looks better than reality while your optimisation gets worse.

1. Open Events Manager and check the Deduplication Diagnostics section. It is the authoritative view, and it is easy to run an account for years without opening it.
2. Check the proportion of server events matched with a browser event. Above 80 per cent is the target.
3. Look through the event log for the same event appearing twice with different IDs.
4. Compare All Conversions against your own order count. A gap above roughly 50 per cent is unusual and worth investigating.
5. Check for multiple pixel IDs, or an integration app quietly sending events alongside your own implementation.

The mechanism is an Event ID shared between the two sources for the same action. With it, Meta recognises the pair and keeps one. Without it, both are real as far as Meta is concerned, and no amount of reporting adjustment fixes what the optimiser already learned.

Event Match Quality measures how well Meta can connect the conversions you send to actual people. A purchase it cannot attach to anyone teaches it nothing, so match quality is the difference between reporting a conversion and learning from one.

1. Check which parameters you send. Email, phone and an external ID do most of the work; more parameters give more chances to match.
2. Confirm hashing and formatting are correct. A correctly hashed but badly formatted phone number matches nothing, and this fails silently.
3. Improve server-side coverage and deduplication, since the same identifiers sent through both paths reinforce each other.

What makes this worth doing before campaign-level work is that it improves every campaign at once rather than one ad set, and the work is done once. It is also invisible in the places people usually look, so it goes unexamined.

The score runs from 0 to 10, and the threshold that matters is 6. Meta's own analysis of more than 28,000 weekly campaigns found that advertisers above an Event Match Quality of 6 averaged a 5 per cent reduction in cost per purchase. Where you hold customer email and phone, 7 to 9 is achievable and should be the expectation rather than a stretch.

iOS 14 changed Meta advertising permanently by requiring apps to ask permission before tracking activity across other companies' apps and sites. Enough users declined that Meta lost a substantial part of the signal it had been optimising on, and the effects are still visible in accounts today.

Most of the platform-level adaptation happened years ago: modelled conversions, a shorter default attribution window, Aggregated Event Measurement, and the push toward server-side data. What remains undone is usually at account level, and that is where the recoverable performance sits.

The practical consequences worth understanding:

• Reported conversions became partly modelled. Some of what you see is estimated rather than observed, which is correct behaviour but means the number is not a receipt.
• Attribution windows shortened, so long consideration cycles are systematically under-credited in platform reporting.
• Server-side data became the main lever, which is why CAPI stopped being optional.
• Blended measurement became necessary, because no platform number is complete enough to run a business on alone.

If your platform numbers and your own accounts disagree, that is now expected rather than a fault. Attribution windows covers reconciling them, and the MER and nCAC calculator gives you a figure that does not depend on attribution at all.

Do I still need the browser pixel if I have CAPI?

Yes, and running both is the intended setup. The browser catches things your server does not see, the server catches what the browser cannot report, and together with a shared Event ID they cover more than either alone. Removing the pixel to avoid double counting solves the wrong problem.

My conversions dropped overnight with no other change. Is it tracking?

Check tracking first, because it takes minutes to rule out and everything downstream depends on it. A site deployment, a new consent banner, or a tag manager change can stop events without touching the ad account. If events are firing normally, the cause is elsewhere and sudden drops covers it.

Is a low Event Match Quality score worth fixing before anything else?

It has a strong case, because it improves every campaign at once rather than one ad set and the work is done once. Weigh it against conversion volume: on an account too small to leave learning, budget structure is the binding constraint first.

What do I do about visitors who decline consent?

Respect the decline, and understand what it costs you in measurement so you do not misread your own numbers. Server-side events for people who did consent, plus blended reporting across your whole business, gets you a usable picture without pretending the declines did not happen.

How do I know whether my numbers are modelled or observed?

Meta does not label them line by line, which is the honest answer and an uncomfortable one. Treat platform conversions as directional and reconcile against your own sales data on a regular cadence. The gap itself is information: a stable gap is fine, a changing gap means something moved.