Home/Research

Measurement · conversion tracking

An inactive pixel was not a warning. It was an outage.

On cash-on-delivery stores running a third-party checkout, the advertising platforms were receiving no purchase event at all. The only visible symptom was a pixel marked inactive, and we read that as a warning for a long time before we read it as an outage. What follows is the mechanism, the fix, and the check anyone can run.

Published 2026-06-20

What we found

On stores that take payment cash on delivery and run their orders through a third-party checkout, the advertising platforms were receiving no purchase event. Not a delayed event. Not one attributed to the wrong campaign. Zero purchase events reached the platform for those orders.

The only visible symptom was that one platform showed the tracking pixel as inactive. That is a quiet line in an interface full of advisory notices, and it reads as something to tidy up when there is time. It does not read as the sentence it actually means, which is that the campaign is being optimised on nothing.

Nothing else in the stack reports this. Errors get reported. Absences do not. Spend reports fill in, traffic reports fill in, and the conversion column is simply low or empty, which is a shape any account can produce for many ordinary reasons.

Why a missing signal is worse than a broken one

An ad platform with no conversion signal does not stop. It keeps spending and it keeps optimising, towards whatever proxy is available to it. The auction still runs. The budget still empties on schedule.

That is what makes the failure expensive rather than merely untidy. The campaign shows every outward sign of working: money going out, traffic coming in, a live dashboard. The one thing missing is the only thing the optimisation was supposed to be steered by.

The mechanism is ordinary. The purchase is completed on a checkout we do not own, so the moment that counts as a conversion happens where our browser tag never runs. The shop's own records know about the order. The platform never hears about it.

Where we were wrong

The pixel had been showing as inactive for a long time before anyone treated it as an outage rather than a warning. The symptom was visible the whole time. We had seen it and we had filed it under the wrong heading.

This was not a detection failure, which is the comfortable version of the story. It was a triage failure. A field saying that a measurement channel was not live sat in the queue behind things that felt more urgent because they were louder.

The rule we apply now is blunt. Any status that says a measurement channel is not receiving data is an outage until someone proves otherwise. Warnings are allowed to wait. Outages are not, and a measurement outage is worse than most, because it silently invalidates every decision taken downstream of it.

What the fix has to do

The fix was server-side. Orders feed the advertising platforms' server-side conversion APIs from our own records, keyed on the real order rather than on a browser session that may never have existed.

It has to be idempotent. The same order can be sent more than once, on a retry or on a reconciliation pass, and a duplicated purchase teaches the platform the wrong thing just as effectively as a missing one. Keying on the real order is what makes a second send harmless.

It has to be reconciled on a schedule. A server-side feed fails silently in exactly the same way the browser pixel did, unless something counts what was sent against what exists. Fired and forgotten, it reproduces the original bug in a new place, with the added disadvantage that it now looks fixed.

How to run the same check

Count the purchases in the shop's own database for a closed period. Count the purchases the platform says it received for the same period. Compare them.

The discipline is in the second source. Do not compare the platform against itself. Reported conversions and attributed revenue inside the same interface come from the same pipeline, so their agreement proves only that the pipeline is consistent with itself, including when it is consistently receiving nothing.

Read the result conservatively. Zero at the platform, against a database that plainly holds orders, is the failure described here. A partial gap is ordinary under-reporting, which has many causes, from attribution windows and time-zone boundaries to consent, and it needs a different investigation. Run the check per store: checkout configuration is a property of the store, not of the account.

Limitations

This describes cash-on-delivery stores on a third-party checkout. A standard hosted checkout with a working pixel does not have this problem, although it can still under-report, and under-reporting is a different problem with different remedies.

We are not reporting a size. No spend figure, no recovery figure, no claim about how the campaigns would have performed had the signal been present. That counterfactual cannot be measured after the fact and we are not going to estimate it.

The check tells you whether purchase events arrive. It does not tell you whether they are attributed correctly once they do, and it does not validate the values attached to them. Those are separate checks. Passing this one is a precondition for them, not a substitute.

Questions and answers

What does it mean when an ad platform shows my pixel as inactive?

An inactive pixel status can mean the advertising platform is receiving no purchase events at all, not merely fewer. On cash-on-delivery stores using a third-party checkout, the purchase completes on a checkout where the browser tag never runs, so the platform never hears about the order. Treat an inactive pixel as an outage until someone proves otherwise, because the campaign is being optimised on nothing.

Why don't purchases from a third-party checkout reach ad platforms?

Purchases from a third-party checkout do not reach ad platforms because the moment that counts as a conversion happens on a checkout the store does not own, where the store's browser tracking code never runs. The shop's own records know about the order, but the platform never receives the event. Nothing in the stack reports this, because errors get reported and absences do not.

What happens to ad campaigns when no conversion data arrives?

When no conversion data arrives, ad campaigns do not stop. The platform keeps spending and keeps optimising towards whatever proxy is available, the auction still runs and the budget still empties on schedule. The campaign shows every outward sign of working, with money going out and traffic coming in, while the one signal meant to steer optimisation is missing.

How should a server-side conversion API feed be built?

A server-side conversion API feed should send orders from the store's own records, keyed on the real order rather than a browser session. The feed must be idempotent, because the same order can be sent twice on a retry and a duplicated purchase misleads the platform. The feed must also be reconciled on a schedule against existing orders, or it can fail silently like the pixel did.

How can I check whether my ad platform receives purchase events?

Check whether an ad platform receives purchase events by counting purchases in the shop's own database for a closed period and comparing them with the purchases the platform says it received for the same period. Do not compare the platform with itself, since its reports share one pipeline. Run the check per store, because checkout configuration belongs to the store, not the account.

Is a partial gap between platform conversions and real orders the same problem?

A partial gap between platform conversions and real orders is not the same problem as a missing purchase signal. A partial gap is ordinary under-reporting, with causes ranging from attribution windows and time-zone boundaries to consent, and it needs a different investigation. Zero purchases at the platform, against a database that plainly holds orders, is the outage. Attribution and event values need separate checks.

All research