When the Three Systems Disagree, Which ROAS Is Real?

Every month your ad platforms, your analytics and your commerce platform report three different revenue figures for the same business, and every month someone tries to reconcile them into one. They do not reconcile, because they are not three measurements of one quantity. They are three answers to three different questions, and only one of them counts money that actually arrived.

The three questions

The ad platform asks: can this order be associated with my inventory, inside my window, under my rules? It answers about itself, using data it controls, in service of a number it also sells against.

Analytics asks: which resolvable source preceded this session? It answers about traffic it could identify, and files everything it could not under Direct or Unassigned.

The store asks: was an order placed and paid for? This is the only one of the three that is money.

Once the questions are separated, the disagreement stops being a data-quality problem to fix and becomes a structural fact to work with.

The two ratios that relate them

Coverage is attributed conversions divided by store orders. It tells you what fraction of your business your analytics can see at all. Because reported cost per order is the real figure divided by coverage, a coverage of 0.6 inflates every cost figure by 67% before any media price moves. The Price of Being Found reports its publisher's own census at 48.6% of sessions with no resolvable source over 17 October 2025 to 2 September 2026, one company's data and not a population estimate.

The claim ratio is summed platform claims divided by store orders. Above one, the platforms collectively claim more orders than happened, and at least the excess share cannot each be a distinct sale.

Two numbers, one hour, computed from data you already hold. The one-hour audit is the procedure.

Why the reconciliation project always fails

Teams spend quarters trying to make the platform number match the store number through better tagging, server-side tracking and consent recovery. Those projects raise coverage, which is worth doing. They cannot close the gap, because the platform is not attempting to count distinct orders. It is attempting to count orders it can associate with itself, and two platforms can honestly associate themselves with the same order.

You are not fixing a broken join. You are asking two bookkeepers with different mandates to produce one ledger.

The number to put in the plan

The store's orders and the store's revenue. Anchor everything to them: express channel performance as a share of real orders, quote cost per real order, and treat platform figures as directional and diagnostic. That single discipline removes most of the argument from a budget meeting, because the denominator stops being contested. How to prove incrementality in budget meetings is the script.

What still is not answered

None of the three tells you what a channel caused. Association is not causation and the store total is not attributable by itself. For the channel carrying the most budget, a randomised holdout answers it. Between holdouts, a causal read estimates it from the variation already in the export, reports an interval, and states its coverage. Unified marketing measurement covers how the methods fit together.

What to do this week

• If you own the budget: pick the store as the single source of orders, in writing, and re-express last quarter against it before the next plan.
• If you have to defend the number: bring coverage and the claim ratio to the meeting. They convert an argument about whose dashboard is right into arithmetic anyone can check.

The interactive demo shows a causal read on a sample store, no signup.

Product facts as stated on causalityengine.ai on 9 September 2026. The three-systems identity, the coverage census and the claim ratio are from The Price of Being Found (Edition 2.10), Chapters 8 and 9, with the book's caveats.