Why do our analytics tools show different numbers?

Because the tools are not counting the same defined things. A visitor, a session, a conversion, and a channel each come with their own boundary rules, and those rules differ from product to product, so two correct counts of one set of events land on two totals. When a specific gap appears, the shape of the gap narrows the suspect list before you open a settings screen. A gap that grows or shrinks depending on which reporting period you pull points at the clock or at window length, since both turn on where a period's edges fall. A gap that stays at roughly the same percentage whichever period you pull points instead at sessionization, the bot list, or the deduplication rule, since those apply evenly across time. And a gap that shows up in one channel's row while the totals agree points at c

Which analytics number should we trust?

None of them universally — the question itself needs a source assigned to it. Pick one tool as the source of truth for a given decision, write down the definitions it uses, and hold that choice stable across every comparison you make with it. Swapping which tool governs a decision, or comparing numbers pulled from two different sources without naming which one is authoritative, is how a team ends up debating a gap that was never a disagreement about reality in the first place.

How do we reconcile ad platform and web analytics data?

You generally do not fully reconcile them, and that is fine: document each tool's definitions, decide which one governs which question, and stop trying to force agreement between systems built on different rules. A residual gap between an ad platform's self-reported numbers and a web analytics tool is close to structural, because the platform counts its own delivery against its own boundary rules while the analytics tool counts arrivals against a different set. That the platform also has a stake in the answer is a separate distortion with a separate mechanism, and it belongs to why marketing data flatters itself rather than to anything on this page. Treat the two as separate, individually useful readings rather than as one number that should have appeared twice.

Why analytics numbers never match

Guide · Continuous Intelligence · 5 min read · last verified 2026-08-11

Reviewed before publication Editorial board Independent commercial review

In shortTwo analytics tools rarely disagree because one of them is wrong; they disagree because each defines a session, a window, a bot, and a duplicate slightly differently, so identical events produce different totals — the fix is governance…

Two analytics tools reporting different numbers for what looks like the same metric are not necessarily disagreeing because one of them made an error — each may be answering a slightly different definitional question, and the mismatch is the visible evidence of that difference rather than proof that a tool is broken. A session, a conversion, a visitor, and a channel do not have one fixed meaning; each tool defines them with its own boundary rules, and two consistently applied definitions running over the same underlying events can land on two different totals with nothing miscounted on either side. Chasing the numbers until they match is not a support ticket away from resolution, because there may be nothing broken to fix.

A different disagreement than data flattering itself

This is a different failure from the one that makes marketing data flatter itself — that piece is about numbers distorted by which cases survive to be written up, who bothers to answer a survey, and a channel grading its own contribution. Every mechanism below instead assumes both tools are reporting their inputs in good faith, and shows why two faithful counts of the same reality can still disagree. Neither failure explains the other; a number can pass every test in this piece and still be the flattering kind, and a number free of survivorship or self-grading can still land nowhere near what a second tool reports for the identical event.

The same explanatory move turns up one level out, in why analyst market-size numbers disagree: research firms publish different totals for what sounds like one market because they drew the market's edges in different places. The object there is a category boundary and the answer is to read the spread with each source's definition annotated beside it. The object here is a counting rule inside a tool, and the answer runs the other way — name one tool authoritative for each question rather than keeping the range open.

A session does not mean the same thing to every tool

Sessionization is a boundary rule, not a fact about the visitor: how long a gap of inactivity ends a session, whether a session resets at a fixed daily boundary regardless of activity, whether a change in campaign parameters mid-visit starts a new one. Two tools counting the identical sequence of page views can produce different session totals purely from where each draws that boundary, with no event miscounted by either — the visitor did one thing; the tools simply drew different lines through it.

The clock itself does not agree between tools

Timestamps look objective and are not. One tool buckets events in UTC, another in the account's configured local timezone, a third in whatever timezone the visitor's own browser reports. An event near a day boundary lands in "today" for one report and "yesterday" for another, and any daily or period total that straddles the boundary shifts as a direct result, with nothing about the underlying event having changed at all — only which bucket it fell into. Made-up values, meant only to keep the mechanism visible and not a transcript of any real tool's log:

Event fires at 11:47pm in one timezone (06:47 the next day in UTC)

Tool bucketing in UTC        -> counted on Day 2
Tool bucketing in local time -> counted on Day 1

Neither tool made an error. Both applied their own rule correctly to the same event.

Windows and deduplication move the count a second and third time

What decides how long a touch stays eligible for credit is its own setting, configured independently inside each tool, and easy to leave unaudited against the other — a conversion a longer window still counts is a conversion a shorter-window tool has already excluded, a distinct mechanism from sessionization that produces the identical symptom of two totals for one underlying reality. Deduplication adds a third disagreement: deciding whether two events describe the same person or the same visit requires matching on something — a cookie, a logged-in ID, a device signal — and tools matching on different signals will merge some records one tool kept separate, and split some the other merged, in both directions at once. One instance of this family has a name of its own: a visit that began inside an AI assistant's answer often arrives with its referring source stripped away entirely, landing in whatever bucket a tool uses for unlabeled traffic — often labeled direct — the same disagreement playing out across an entire emerging channel rather than one boundary case.

Bot filters and crediting models add a fourth and fifth disagreement

Every analytics tool maintains its own bot and crawler filter list, updated on its own schedule; a filter update that removes a source of automated traffic in one tool but not yet in another opens a gap between the two that has nothing to do with the real audience and everything to do with which filter list happened to be current on which day. And a channel report showing different revenue per channel across two tools is often the same family of disagreement appearing somewhere else: which model each tool defaults to for splitting credit among touches is a policy decision, and two policies applied to one underlying path will, correctly, produce two different per-channel breakdowns that both sum to the same total.

The fix is governance, not a better integration

No integration reconciles two systems that were never measuring the same definitions in the first place; connecting them faster just moves the disagreement into one interface instead of two. The working fix is choosing, per question, a single source of truth and writing its definition down — this tool's session rule, this tool's window length, this tool's bot-list version, this tool's crediting model — so that everyone reporting a number is reporting the same defined thing rather than silently comparing two definitions and calling the gap an error. Some residual gap is close to permanent once two systems run side by side with different rules underneath them, and treating that gap as a problem still waiting to be solved wastes effort chasing a zero the two definitions were never going to produce together. How a dashboard then displays whichever number gets chosen — the denominator beside it, the method, the observation date — is a design question with its own separate fixes; nothing in that display work explains why two raw inputs disagreed in the first place, which is the gap this piece is about instead.

The same discipline applies to a measurement this site runs on itself. A Magrios scan re-run against an identical question set can return a different count from one pass to the next for reasons that have nothing to do with a changed reality, a property documented directly for that specific method — one more instance of a number moving for reasons that live inside the measurement rather than inside the world it describes. Two tools disagreeing and one tool wobbling from run to run are, underneath the different vocabulary, the same lesson: know what a number is actually a number of before deciding it disagrees with anything.