Skip to content
Webclat | Goods

SIGNAL RECOVERY

Your numbers do not match because some of them were never collected

Every ecommerce measurement stack loses a share of what it is supposed to record. The share is not small, it is not random, and it is not evenly distributed across your channels - which is why the losses show up as an argument about attribution rather than as an obvious gap. Below, put in your own numbers and see the size of yours.

Start with the symptom

Meta reports 400 conversions, GA4 reports 250, and the argument repeats every month.

Different attribution windows over differently incomplete data. Neither number is a lie and neither is right, which is why the argument never resolves on the evidence available.

Your order management system counts more orders than your analytics does.

The most direct evidence of collection loss there is. Your finance system counts money that arrived; your analytics counts events that survived a browser.

Direct and unassigned traffic is your largest and best-converting channel.

Usually not a channel at all. It is where conversions land once their first touch has fallen outside client-side storage.

Conversion rate drifted down over eighteen months with no change in the funnel.

A denominator problem. Agent and bot sessions inflate session counts while contributing almost no orders, so the rate falls while the business does not.

What this calculator will not do

It will not tell you that you are losing 23%. We have never seen your site, and a figure like that depends entirely on your traffic mix, your consent rates and your ad-block exposure - none of which we know. A calculator that produces a confident number from inputs it invented is the exact failure this property exists to criticise, so this one does not have a hidden default anywhere.

What we can do is the mechanics. What a consent gate withholds, what a same-origin collector recovers that a blocked vendor tag loses, how a protocol checkout differs from a browser session - those are properties of how collection works, and this property demonstrates them live. So: the model is ours, the inputs are yours, and every assumption is stated and adjustable. Four of them are ours to supply; two of those four are placeholders and say so.

The largest number the model produces is the one it tells you is not recoverable. Visitors who declined consent stay uncounted, because server-side collection changes what a browser can block and never what a visitor agreed to.

This page practises what it preaches: your interactions with the calculator are measured as events - open the tracking plan in another tab and watch them fire - but the numbers you type never leave this page. The events carry which control you touched, not what you entered, and the event schema caps the field so a value cannot ride along. Your traffic and spend figures are your business. The one exception is one you create yourself: the “send these figures” button makes a link that carries your numbers in its fragment - never transmitted to us, but readable by anyone you give the link to. It says so again next to the button.

Your numbers

Your traffic mix

Our assumptions

Four numbers the model supplies rather than you. Every one is adjustable, and every one says where it came from - including the two that are placeholders because nobody has measured them for your site.

Read this before quoting anything below

  • Protocol-checkout orders are zero, which is the correct answer for most merchants today. That line exists because the channel is growing quickly, not because it is currently large.

Conversions nothing records

518

orders / month

Additive. These orders happened, the money arrived, and no client-side destination holds a record of them. This is the only bucket whose conversions are genuinely missing from your totals.

Orders from sessions whose vendor tag never randemonstrated518

A blocker stops a third-party script, or its request to a vendor host. A same-origin collector is not a third party, so the event is captured and the fan-out happens server-side where no extension is in the path.

true human sessions x ad-block share x consent-permitted share x human conversion rate x blocked-visitor index x first-party recovery rate

Orders through protocol checkout (ACP, UCP)scoped0

The agent never requests a page. Discovery runs off a structured product feed and checkout through REST endpoints with delegated payment tokens, so there is no DOM and no JS engine at any point. It behaves like a marketplace channel: nobody is surprised that their own GA4 stays silent on an Amazon order.

entered directly - an invisible channel cannot be estimated as a share of a visible one

Revenue already earned, currently invisible$44,045

Conversions credited to the wrong channel

360

orders / month

NOT additive - these orders are already inside your reported total. Nothing here changes your revenue; it changes which channel gets the credit, which is what distorts every ROAS decision built on top of it.

Orders whose first touch fell outside client-side storagescoped360

Client-side attribution storage is capped at seven days on these browsers. A conversion outside that window keeps its revenue and loses its origin, so it lands in direct or unassigned - which quietly credits the worst-performing channel with the best one’s work.

recorded orders x Safari and iOS share x truncation share

Revenue whose source is wrong, not missing$30,600

Rates measured against the wrong denominator

Agent sessions run your tags and almost never buy, so they inflate session counts while leaving order counts alone. No conversion is lost or moved - every rate computed from them is simply wrong, in a direction that makes your site look worse than it is.

Agent sessions in your reported total
12,500
Conversion rate as reported
1.60%
Conversion rate among humans
1.68%

Your true conversion rate is understated by 5.3%.

What it costs in media

Cost per order, as reported
$30.00
Cost per order, in reality
$26.56

Your reported cost per order is overstated by 13.0%. Every bid, budget and pause decision made on the reported figure is made against a channel that performs better than your dashboard says.

Spend allocated on incomplete signal
$13,763
Arithmetic, no behavioural assumption: the share of conversions that is invisible, applied to spend. A ceiling, not a loss.
Of which a bidder recovers
$3,441
The one figure here that predicts behaviour instead of describing arithmetic, and the weakest number on the page. Set its assumption to zero and read the line beside it instead.

And what we cannot recover for you

Consent-denied sessions per month
21,883
Their orders, permanently invisible
369

Not recoverable, and not a gap in the fix. These visitors declined analytics consent, so their orders are deliberately invisible and must stay that way. Server-side collection changes what a browser can block, never what a visitor agreed to. Any vendor quoting this number as recoverable is describing a compliance problem.

Send these figures

Creates a link that opens this page with the numbers above already in place. Be deliberate about where you send it: the link itself contains your figures. They ride in the URL fragment, which your browser never transmits to us - not to our server, not to our logs, and not into the measurement events this page emits - but anyone who has the link has the numbers.

The working, so you can check it

Human sessions your analytics can see
237,500
Human sessions that actually occurred
291,769
Share of humans your tags reach
81.4%
Conversion rate used for projection
1.68%

Consent-denied and tag-blocked populations are treated as independent, which understates their overlap and therefore understates the true session count - the conservative direction for every recovered figure above. The full model, comments and all, is one file in the repository.

How the number gets replaced with a measurement

Everything above is an estimate built on figures you typed in. The next step is not a better estimate, it is a measurement: a server-log-to-analytics reconciliation on your own traffic, which turns the ad-block input from a guess into a count, and a consideration-window distribution from your order data, which does the same for the truncation share. Two of the four assumptions stop being assumptions at that point.

Figures on this page are computed from your inputs and nobody else’s. This property publishes no client outcomes, and the numbers in its own exhibits are generated from a synthetic population with known ground truth - which is deliberate and stated.