A visitor opens a help article, finds the answer and leaves. Another opens the same page, fails to understand it and leaves just as quickly. A dashboard may place both visits in the same category, even though one was successful and the other was not. Web analytics records traces of a visit; interpreting those traces requires some knowledge of what the visitor came to do.
Web analytics measures website activity through data such as page views, events, sessions, traffic sources and conversions. It helps teams understand patterns across recorded visits, locate changes and investigate where journeys appear to break down.
Start with the question behind the report
For a fictional pricing page, the useful question might be whether visitors can identify the appropriate plan and begin a trial. Page views alone cannot answer it. A more relevant measurement plan would define the actions involved, the period in which they count and the population included in each rate.
Keep the unit clear. One person may generate several sessions, use more than one device or share an account with colleagues. “Users”, “sessions” and “accounts” are not interchangeable labels for the same count. Tracking gaps, consent choices, blockers and platform modelling can also affect coverage, so a report should not be described as a complete record of every visitor.
Check definitions before comparing numbers
Familiar metric names can hide different calculations. Google Analytics 4, for example, defines bounce rate in relation to sessions that do not qualify as engaged, rather than simply counting single-page visits. Google’s engagement and bounce-rate documentation explains the relationship. Verify the definition and configuration in the system being used before comparing it with another platform or an older report.
Document changes to tracking alongside releases. An apparent rise in conversion may reflect a duplicate event or a revised definition rather than a better experience. Test the event path and check whether missing or repeated events could explain the result before developing a product theory around it.
Use the pattern to focus an investigation
Break down a surprising result by meaningful audience or device groups, taking care with very small segments. A mobile-only problem may disappear in an overall average dominated by desktop traffic. Clickstream analysis can then help inspect the recorded routes into and out of the affected step.
Follow up with research suited to the uncertainty. Usability testing can explore whether people understand a page, while a focused survey can ask what they came to accomplish. Neither automatically establishes the prevalence of a particular cause across all traffic.
When evaluating a proposed fix, distinguish an observed improvement from evidence that the change caused it. A suitable A/B test may support the latter. Analytics supplies the measurements, but the study design determines how confidently the team can explain their movement.