Why Your Numbers Do Not Match, and Which One Is Wrong

Every operator has sat in the meeting. The ad platform reports one number of orders. The analytics tool reports another. Finance pulls from the order system and gets a third. Somebody suggests the data is broken, somebody else suggests the agency is inflating, and the next hour disappears.

The numbers were never going to agree. Three systems, three definitions, three collection mechanisms. The useful work is not forcing them together. It is being able to explain, line by line, why each one differs and which one answers the question you are actually asking.

The goal is explanation, not agreement

Start by accepting that only one of these systems is a system of record. The order system knows what was ordered, paid for, cancelled and refunded. It is the only one with a legal and financial obligation to be right. Analytics and ad platforms are observational tools measuring behaviour, and they are structurally incapable of matching an order ledger.

Once that hierarchy is fixed, the question changes shape. You are no longer asking which number is correct. You are asking how much of the gap between platform and ledger you can account for, and whether the unexplained remainder is small and stable. A gap that you can decompose is a working system. A gap that moves around unpredictably is a broken one.

The six reasons the numbers diverge

Almost every discrepancy in Indian ecommerce reduces to one of six causes, usually several at once.

Attribution windows. Ad platforms credit conversions to the day of the click or impression, not the day of the order. Your ledger counts the day money moved. When spend is rising, platform numbers lead the ledger. When spend falls, they lag. This is not error, it is a different time axis, and it alone explains a large share of day level mismatch.

Client side loss. Browser based collection depends on a script running to completion on a real device on a real Indian network. Tabs close, connections drop, blockers intervene, app webviews behave differently. The order system does not depend on any of that, because the order was written server side. So analytics will systematically undercount relative to the ledger, and the size of that undercount varies by device mix and traffic source.

Deduplication. The same conversion often gets reported through more than one path: a browser event and a server event, or a page that fires twice on refresh. If the identifiers used to deduplicate are missing or inconsistent, you double count. Order confirmation pages that a customer reloads are a classic source of inflated purchase counts.

Timezone and currency. Ad platforms and analytics properties each carry a timezone setting, and they are frequently not set to Indian Standard Time. A day boundary offset moves conversions between days and destroys any day on day comparison. Currency does the same to value: a property configured in one currency while events send another produces revenue that is arithmetically wrong in a way nobody notices, because the shape of the chart looks fine.

Test and internal traffic. Your own team browsing the site, QA running checkout tests, warehouse staff placing sample orders, agency users clicking their own ads. The ledger usually flags or excludes these. Analytics almost never does unless someone configured it to.

Refunds and cancellations. This is the largest gap in India and the least discussed. Cash on delivery orders that are refused at the door, returns, and cancellations are removed from the ledger and generally not removed from platform reporting. A channel with high cancellation rates will look far better on the platform than it is. That difference is not a data quality problem, it is a commercial one hiding inside a data quality conversation.

A diagnostic order to work through

Work these in sequence. Each step removes a class of explanation, so the remaining gap gets smaller and more interpretable as you go. Do not skip ahead, because a later check run on an uncorrected earlier problem produces nonsense.

One. Fix the time axis. Confirm the timezone setting in every reporting surface and make them identical. Then compare on a rolling seven day window rather than a single day, which absorbs boundary effects while you work.

Two. Fix currency and value. Confirm what unit values are sent in, what unit each system displays, and whether taxes, shipping and discounts are included. Decide one definition of order value and note where each system deviates from it.

Three. Establish the ledger baseline. Pull orders from the order system for the window with clear rules on what counts: placed, paid, shipped, delivered, net of cancellations, net of returns. Pick one and write it down. This is the denominator for everything after.

Four. Strip internal and test traffic. Exclude office networks, known internal accounts and QA order patterns from both sides. Then recompare.

Five. Check deduplication. Confirm that every conversion carries a stable unique identifier and that duplicate identifiers within a window are collapsed. Look specifically at repeated purchase events with identical order identifiers and at confirmation page reloads.

Six. Quantify client side loss. Compare browser observed purchases against the ledger for the same identifier set. The difference is your collection shortfall. Segment it by device type and traffic source, because the shortfall is never evenly distributed and knowing where it concentrates tells you what to fix.

Seven. Apply the returns and cancellation adjustment. Recompute platform reported performance against net orders rather than gross. This usually reorders your channel ranking, which is the whole reason to do the exercise.

What to do with the residual

After all seven steps there will still be a gap, driven by attribution windows and by conversions the platform claims that your data cannot see. That is expected. What matters is that the residual is documented, roughly stable week to week, and understood by everyone who reads the report.

Write it down as a standing note attached to the reporting. State which system is authoritative for which decision: the ledger for revenue and finance, analytics for on site behaviour and funnel diagnosis, platform reporting for in platform optimisation only. Anyone comparing across those boundaries needs to know they are comparing different instruments.

Then set a tolerance. If the unexplained gap moves outside its usual band, that is an alert worth investigating, because it usually means something broke: a deployment dropped a script, a setting changed, a new checkout path shipped without instrumentation. Reconciliation is not a one time cleanup. It is a monitor.