Browser analytics will never capture every order. Some visitors decline measurement, some block it, and some orders never happen on the web at all. The gap is typically ten to thirty per cent, and it is not a malfunction — it is how measurement works. What matters is what you do with that gap: either distribute it across channels and get numbers that look precise and are not true, or admit it and keep what you know separate from what you do not.
Two truths that are not the same thing
Commerce truth is what was actually sold. It comes from shop orders and it is complete — every order is in it, including the one taken over the phone.
Analytics truth is what browser measurement captured. It is always smaller. A customer who declined measurement still bought; their order is in the shop and not in analytics.
When the two are swapped, revenue in the report is lower than revenue in the bank. Nobody notices the difference until a budget decision is made on it.
Why distributing the missing orders is worse than admitting them
There is an easy fix on offer: split the missing orders across known channels in the same proportion as the captured ones. The result looks complete — the total adds up and no row is missing.
The problem is that a measurement outage is rarely uniform. It typically hits one channel: after a change to the website, after a consent-banner change, after a browser update. Proportional distribution smears that outage across every channel and hides exactly what should have been visible.
An unattributed order is the correct result. It is not an error; it is an honest answer to a question measurement cannot answer.
What can be learned without browser measurement
Some orders carry a trace that has nothing to do with the browser. Most often it is a discount code: when a customer used a partner code, you know where they came from regardless of whether analytics saw the transaction.
One condition matters: the code must be unambiguously assigned. Inferring meaning from a code name — that "JURAJ10" belongs to Juraj — is guessing. When the code is recorded as a specific partner code, it is evidence. When it is not, it is a question.
And when nobody has decided about the code yet? Even then you know something certain: the order used that code. That is a fact, and it belongs in the report — not in an anonymous bucket whose revenue cannot be traced.
Zero and "we do not know" are different things
When analytics is not connected, printing a zero is tempting. It looks like a number and the chart draws.
But "0 % coverage" means "measurement failed on every order". "Analytics is not connected" means "measurement never ran". The first sends someone hunting for a fault; the second just needs connecting. On screen the two look identical — which is why the system has to tell them apart.
How MitoOps handles it
Revenue and order counts always come from the shop, so the total matches reality. Measurement is compared against it, and the result is coverage: how many of the orders where a trace can be expected analytics actually captured.
Orders are split into layers by what is known about them: captured in analytics, attributed from an unambiguous code, code known but not yet classified, and finally those with no evidence at all. The layers always add up to the commerce total.
A manually created order is not counted as missing measurement. It was never shown to the customer in a browser, so no trace could exist — calling it an outage would be wrong.
- revenue and orders always from the shop, never from analytics
- missing orders are never distributed across channels
- a discount code with an unambiguous assignment is evidence; a code name is not
- unconnected analytics never shows as zero coverage