E-commerce conversion tracking: from 35% event coverage to nearly complete

Who the client was and what was wrong

An online beauty retailer was spending a meaningful monthly budget on Meta ads. The problem was easy to see: purchases reported by the pixel did not match the store’s own figures. Meta saw roughly one third of conversions. The rest were missing.

This is about more than tidy reports. Meta’s algorithm learns from the events it actually receives. If it gets one in three, it optimises campaigns against only part of reality and spends money in places no one would knowingly choose. The client was paying twice: first for missing data, then for worse decisions by the algorithm.

Three related issues also needed to be solved together. The pixel fired before a visitor had made a choice in the consent window. That creates both a penalty risk and data Meta cannot use anyway—the worst of both worlds. Second, browser and server events needed shared identifiers; otherwise the same purchase is counted twice and reported revenue grows only on paper. Third, server events carried too little data, so Meta’s dashboard understated match quality.

What we did

We started by measuring the store’s actual consent rate. Event coverage turned out to be practically identical to that rate. The problem was not the event code itself, but the order in which it ran: the pixel fired too early, and Meta rejected those events.

We put a consent gate in place across both channels. The browser layer runs through Google Tag Manager; the server layer uses server-side GTM hosted on Stape. Consent Mode v2 and the consent platform determine what can be sent and when. Once a visitor gives consent, events from before that decision are sent again in the same form through both the pixel and Conversions API.

To prevent an event from being counted twice, we set stable, shared identifiers. We identify a purchase by the store’s transaction number rather than a random string generated on every page refresh. Meta can then deduplicate the browser and server pair, and reported revenue matches reality.

Finally, we improved data quality. We added user identifiers already held by the store to server events and removed junk events: bot traffic, previews and accidental cart reloads.

How it works today

The work took about a week. The store now handles six standard Meta events in parallel in the browser and on the server. Measurement does not start until the visitor makes a choice in the consent window; once they consent, nothing from their visit is lost—we send the queued events.

Each event has one identifier shared by both channels, so Meta removes duplicates itself and counts revenue once. User data is enriched and the stream is cleaned up, so Meta’s dashboard rates match quality higher than before. Marketing sees the same figures as accounting. That is a low bar, but it was not met before.

What changed

Coverage of standard Meta events rose from about 35% to nearly complete. All six standard events now work through both channels at once. Measurement complies with GDPR because nothing is sent without consent. Match quality in Meta’s dashboard improved.

What we would do differently

We lost the first day looking for a bug in the event code because we assumed incomplete coverage meant something was not being sent. We could have immediately compared coverage with the consent rate: the figures were practically identical and pointed straight to the cause. That is now the first thing we check in every measurement audit.

We initially treated filtering junk events as cosmetic and left it until the end. It turned out those events were pulling match-quality ratings down the most. On the next implementation like this, we will start by reviewing the raw event stream before touching the consent configuration.