Almost every tracking conversation I have starts the same way: someone is convinced the pixel is broken, because the platform reports fewer purchases than the store does.
The pixel usually is not broken. It is working exactly as designed, in a browser that has stopped cooperating. Ad blockers drop it outright. Privacy settings in Safari and Firefox shorten or discard the storage it depends on. A slow page means some visitors leave before the script has fired at all. None of that is a configuration error, and none of it is fixable by reinstalling the pixel.
What closes the gap is sending events from your server instead of, or alongside, the browser.
What server-side tracking actually is
Browser tracking works like this: a visitor buys something, a script in their browser sends an event to Meta or Google, and the platform matches it to an ad click.
Server-side tracking moves the sending step. The purchase happens, your server — or a server-side container — sends the event directly to the platform. Nothing in the visitor's browser has to survive for the event to arrive.
On Meta this is the Conversions API. On Google it is enhanced conversions and server-side tagging. The names differ, the idea does not.
What it fixes, and what it does not
It is worth being precise, because this gets oversold.
It does fix events lost to ad blockers, events lost to browser storage limits, and events lost because the page was abandoned before a script ran. In most accounts I have moved over, reported conversions rise meaningfully — the exact figure depends entirely on your traffic mix, and anyone quoting you a universal percentage is guessing.
It does not fix attribution. Server-side tracking tells the platform that a conversion happened; it does not settle which ad deserves credit. Your platforms will still disagree with each other and with your store, because they are answering different questions.
It does not make you exempt from privacy law. Sending data from a server rather than a browser changes the mechanism, not the obligation. Consent still applies, and in the UK and EU it applies before you send anything. If your cookie banner says analytics load only on acceptance, your server-side setup has to honour the same choice.
Match quality is the number that matters
Once events are arriving server-side, the thing that decides whether they are useful is match quality — how reliably the platform can tie your event to a real person who saw an ad.
On Meta, open Events Manager and look at the event match quality score for your purchase event. Below about seven out of ten means you are sending weak signals, and weak matching gets punished hardest exactly when competition is highest.
What raises it is sending more identifying parameters with each event, hashed: email, phone, first and last name, city, postcode, country, and the platform's own click identifiers. Most setups send email and stop. The click identifiers in particular — fbclid for Meta, gclid for Google — are the strongest signal available, and they are routinely dropped because nobody captured them when the visitor first landed.
Capture them on arrival, store them with the order, and send them with the event.
Deduplication, or you will double-count everything
If you run browser and server events together — which is the recommended setup, not an either/or — both will fire for the same purchase. Without a shared event ID, the platform counts two.
I have seen accounts celebrate a sudden fifty percent lift in conversions that was entirely this. Reported returns looked wonderful, scaling decisions were made on it, and the bank balance disagreed for three months.
Send the same unique event ID from both sides. Then verify it actually deduplicated rather than assuming: compare platform-reported purchases against your store's own order count for the same period. They will not match exactly, and attribution means they should not, but a platform reporting double your real orders is a deduplication failure, not attribution.
How to tell it is working
Four checks, in order.
- Events arriving. The platform's event testing tool shows them in real time. Place a test order and watch it land.
- Deduplication confirmed. One purchase should produce one counted conversion, not two.
- Match quality acceptable. Seven out of ten or better on Meta; enhanced conversions reporting a healthy match rate on Google.
- Reconciled with the store. Platform purchases against store orders over fourteen days, within a range you can explain.
If you cannot do the fourth one, the rest does not matter. Every optimisation decision afterwards rests on that number being approximately true.
Do this before Q4, not during
Black Friday is five weeks out. Tracking work belongs in the next fortnight, not in November.
The reason is specific: installing or changing conversion tracking resets what the algorithm has learned, and the learning phase is most expensive exactly when auction prices are highest. A change that costs you a slightly worse fortnight in October costs you the sale in late November.
Fix it now, let it stabilise, and leave it alone once the expensive window opens. That is the whole argument of the five-week plan.
The short version
The pixel is not broken; the browser stopped cooperating. Server-side sending recovers events that were being lost, and it makes the data you optimise on closer to true — which is the entire point, because a return on ad spend calculated from incomplete data is just a number.
Send the click identifiers. Deduplicate properly. Reconcile against your store before you trust any of it.
This is the first thing we do on every account we take over, before touching a budget. The free growth audit includes a tracking review and tells you in writing how far your reported numbers are from your real ones.