A discrepancy between two tools is not a fault; it is the default state of affairs. The problem begins only when a team spends a week looking for an ‘error’ instead of establishing what each number actually measures—and which one answers the question asked in the meeting.
Exact agreement is impossible—and is not the goal
Two tools measuring ‘visits’ do not measure the same thing. Each has its own definition of the unit, its own point at which the event is recorded, its own clock and its own filtering rules. Even if both worked perfectly, the result would not be identical—because they answer different questions.
- DefinitionWhat a session, user, visit and conversion mean in this particular tool.
- TimingAt which second of the visit the event is counted and recorded.
- SampleWhom the measurement sees at all after consent choices, blockers and bot filters.
- ClockWhen the reporting day begins and which time zone it follows.
The goal is not to force the two numbers to match, but to explain the difference well enough that it no longer blocks a decision. Agreement down to a single session would in fact be suspicious—it would mean the two tools count exactly the same thing, making one of them redundant.
Without an explicit definition and explicit coverage, you are comparing two numbers you know nothing about. See how Meetlead provides the metric-definition version and data coverage with every report.
Seven reasons the numbers diverge
Almost every discrepancy we have seen comes down to one of seven mechanisms, or a combination of them. It is worth knowing not only the reason but also the direction—which system overcounts and which undercounts when that mechanism takes effect. A newer example is visits from AI assistants, which one tool attributes to a referrer or UTM parameter and another to direct traffic; we show how to check them in our guide to AI referral traffic.
Scroll the table sideways to see all columns.
| Reason | What it means | Which way it moves the number |
|---|---|---|
| Different definitions of a session and user | One tool ends a session after a period of inactivity, another after the traffic source changes, and each may equate a user with a browser identifier | Up where the session window is shorter and one visit is split into several |
| Different counting points | One tool counts the visit on the first page request, another only after a script runs, consent is granted or the first interaction occurs | Down where counting starts later, because quick exits fall outside the measurement |
| Different time zones | The reporting day begins at a different hour, so the same ‘Tuesday’ includes a different set of events | Either way, especially over short ranges and with evening traffic |
| Different handling of consent and blockers | Some tools record nothing without consent, some collect technical events, and some model the missing portion | Down where measurement waits for consent and does not model the remainder |
| Bot filtering | Each provider has its own list of automated agents and its own rules for filtering non-human traffic | Up where the filter is more permissive or updated less often |
| Sampling | Across broad date ranges and narrow segments, a report may be calculated from a subset of events and scaled | Either way, with error increasing in small segments |
| Processing delay | Data continues to arrive for hours after an event, so a report retrieved in the morning shows an incomplete previous day | Down for the most recent days, then evening out after processing completes |
There is also an eighth and particularly mundane reason: different date ranges. One report covers the last thirty days counting back from today; another covers a complete calendar month. Before looking for anything else, check whether both windows truly contain the same days.
We deliberately do not provide an ‘acceptable’ percentage discrepancy. Such a threshold depends on traffic volume, device mix, the share of rejected consent requests and the particular systems being compared—a figure copied from someone else’s article would mislead more than it helps. The only credible baseline is your own recorded difference from a period when measurement was working correctly.
Which differences are normal—and which are suspicious
Since there is no universal threshold, a different test is needed. A meaningful criterion concerns not the size of the difference, but its behaviour over time. A stable discrepancy is a feature of the configuration. A discrepancy that suddenly changes size or direction is an event and needs an explanation.
Scroll the table sideways to see all columns.
| Symptom | More likely a difference in definitions | More likely a measurement failure |
|---|---|---|
| Behaviour over time | The difference has remained within the same order of magnitude for weeks | The difference appeared or jumped on a specific day |
| Distribution across segments | Visible evenly across all pages and devices | Concentrated on one page, one browser or one source |
| Direction | The same tool always reports more | The direction reversed without a configuration change |
| Coincidence with a change | No relationship with deployments | The start coincides with a deployment, template change or consent-banner change |
| Scale | A predictable, measurable portion of traffic | An entire category of events disappears or the number is exactly zero |
Zero is the most important signal here. Measurement tools rarely miss by an order of magnitude, but they very often stop collecting a specific event type after a deployment. If a metric that previously had a value is now exactly zero, the issue is almost certainly not a difference in definitions.
- Monday
Tool A reports more visits than B; the difference has persisted for a month
- Tuesday, deployment
The page template changes and the measurement script moves lower in the code
- Wednesday
The difference grows, but only on mobile devices and only on one page
- Thursday
Conversions from that page fall to zero in tool B but remain in A
- Friday
A check of session recordings confirms that the event is not sent before the visitor leaves
It is also worth ruling out the rhythm of the calendar. If the difference grows on the same days of the week or in the same month as a year earlier, first check the method for distinguishing fluctuation from change described in our article on seasonality in traffic and enquiries.
The most common point at which a difference stops being normal and becomes a failure is the deployment of a new website version. We collected the things that tend to stop working at that point in our article on website redesigns and measurement.
How to check whether it is a failure rather than a difference in definitions
This procedure takes several dozen minutes and settles most disputes. The order matters because each step eliminates one group of explanations. Reversing it leads to digging through code before anyone has checked the dates.
- Align the time window.Use the same date range, the same time zone and the same start of the reporting day. Ideally, choose one complete week that ended at least two days ago.
- Check data freshness.If either report is still processing, the comparison is worthless. Wait or move the range further back.
- Write the definitions side by side.Use both tools’ documentation to state what the unit you are comparing means. The dispute very often ends at this step.
- Narrow it to one segment.One page, one device, one traffic source. A difference across the whole dataset mixes several mechanisms together.
- Compare the shape, not the level.Overlay both series day by day. A matching shape at different levels indicates a difference in definitions. Diverging shapes indicate an event.
- Find the boundary date.If the shapes diverge, identify the exact day it began and compare it with the list of deployments and consent-banner changes.
- Inspect individual cases.Perform a test visit and check whether it appears in both systems. One missing case tells you more than a week of debating percentages.
The final step is the one that truly settles the matter, and it requires a tool that lets you drill down from a metric to specific sessions, conversations and tickets. In Meetlead, every metric leads to a list of the individual cases behind it, for today, seven, thirty and ninety days, or a custom date window.
A dispute about percentages is settled by one visit that can be opened and inspected. See how Meetlead links a metric to specific sessions, conversations and tickets.
If one page appears under several URLs, use the guide: URL parameters in reports: when one page becomes many rows.
One source of truth for one decision
The most durable solution is not to reconcile the numbers, but to assign each decision to a source. For every recurring question, choose one tool, record that choice and stick to it even when another tool shows a more convenient number.
Scroll the table sideways to see all columns.
| Question | Authoritative source | Why this source | Do not use it for |
|---|---|---|---|
| How many visits were there and where did they come from? | Traffic analytics | It has the broadest view of visits and campaigns | Assessing the course of an individual visit |
| What did the user do on the website? | Session recordings and heatmaps | They show the journey, not just totals | Counting total traffic |
| How many conversations and tickets were there? | Customer service panel | It records every contact together with its history | Accounting for advertising campaigns |
| How much did acquisition cost? | Advertising platform plus customer service panel | The cost is on one side and the outcome on the other | Assessing the quality of website content |
This principle works only when the chosen source states explicitly what it cannot see. Alongside the figures, Meetlead reports provide the metric-definition version, data freshness, and coverage of page views, session identifiers, traffic sources and callback-completion dates; all dates are calculated in the Europe/Warsaw time zone. Sessions without a recorded source are marked as uncovered instead of being given an invented origin, so the comparison with another system concerns the same documented sample.
- For every recurring metric in the report, it is clear which tool it comes from.
- The date range and time zone are stated explicitly rather than defaulting separately in each tool.
- The metric-definition version used to calculate the figure is known.
- Coverage and the share of uncovered cases are visible next to the number, not in a footnote.
- The typical difference from the second source is recorded from a period when measurement worked correctly.
- Every metric can be expanded into a list of individual sessions, conversations or tickets.
When building a permanent set of metrics, it also helps to limit the number of items—we explain this principle in our article on the customer service report. The fewer numbers in the document, the less room there is to argue about which one is true.
A definition, coverage and time zone shown next to a metric end most discussions before they begin. Schedule an implementation—we will show you using your reports.
How to discuss the difference with an agency and your team
A discrepancy between numbers has an unpleasant property: it very quickly turns into a question of who made the mistake. The agency hears an accusation that it inflated the results, the internal team hears an accusation that measurement is broken, and the conversation stops being about the data. Changing the opening sentence is enough to avoid this.
- Instead of ‘your data is wrong’‘I have two different numbers for the same time window—let’s establish what each one counts.’
- Instead of ‘which one is true?’‘Which one do we use for which decision—and what do we record as the authoritative source?’
- Instead of ‘fix it’‘Let’s check whether the difference is stable or appeared on a specific day.’
- Instead of ‘I do not trust the report’‘Show us the metric definition and the coverage of the data used to calculate it.’
A shared language matters more here than the outcome of one check. If both sides accept that a report without a stated definition and coverage is incomplete, the next discrepancy will take fifteen minutes instead of a week. It is also worth agreeing in advance that a difference is not, in itself, an accusation against anyone.
The limits of quantitative analytics are a separate subject—we examine consent, data thresholds and misleading metric names in our article on what Google Analytics will not show you. We discuss selecting the events to measure in our article on website micro-conversions, and linking individual visits into one history in our guide to the customer journey on a website. Search Console and advertising platforms should be treated in the same way: as sources with their own definitions, not as checks on the correctness of analytics.
