The traffic increase we stopped celebrating
Growth reports depend on who was counted and how a session was defined.
Wolfe Services · · 5 min read
A rising traffic line makes for an easy opening to a marketing meeting. It can also make the next question surprisingly difficult to ask: who was actually counted?
In the JTNY analytics work, the answer included automated browsers that could execute the site’s measurement code. They did not identify themselves as simple crawlers. The user-agent filter could be working as written while those visits still appeared in the reports.
We also found a separate problem in how the site reused analytics identifiers. Together, the investigations made some historical growth comparisons unsafe to present without qualification. This note explains why we stopped treating the headline total as an answer.
A working filter had a limited job
The first-party analytics route included rules to handle known automated clients before forwarding their events. That is useful for tools that identify themselves clearly.
A browser controlled by automation can present a normal browser identity and run JavaScript. The investigation recorded traffic with that behavior. Passing a user-agent check therefore did not establish that the visitor was a prospective client, a professional reader, or even a person.
This is a different failure from the analytics delivery outage. During that incident, the delivery path was missing a required component. Here, events were arriving, but their meaning was being overstated. A release check can confirm delivery without validating the audience behind every event.
For the firm reading a report, the practical consequence is that an event count needs a definition and a known set of exclusions. “We filter bots” is too broad to explain what the report actually contains.
The investigation needed evidence outside the chart
The operations record describes recurring screen configurations, unusual browsing patterns, and traffic arriving through infrastructure associated with automated activity. The investigation compared those signals with request-level evidence at Cloudflare.
No one field was a universal test. A particular screen size can belong to a legitimate user. A visitor from another country can be a real reader. Direct traffic can include valuable inquiries. Treating any one of those categories as synonymous with automation would replace inflated numbers with a different measurement error.
The exclusion rules were tailored to the observed patterns on this property. They produced a more useful reporting view, with limits that had to travel alongside it. That is the right scope for the finding. It is not a recipe for filtering every law firm’s analytics by the same countries or display sizes.
We also had to separate a hypothesis from a verified explanation. An unfamiliar traffic burst invites stories about a campaign, a competitor, or a crawler. The useful work is finding evidence that can distinguish those stories. We needed the request evidence before accepting an explanation for the burst.
Then the meaning of a session changed
The cookie-parser defect was a separate issue. The site failed to read its analytics identifiers back correctly and could create new identifiers with each pageview. That changed what sessions, returning users, and some channel assignments meant in the affected period.
A person moving between pages could be represented as additional sessions rather than one continuous visit. After the correction, the reporting basis changed. A drop in sessions could therefore reflect more coherent counting rather than a loss of readers.
The same problem affects conversion rates. If the denominator becomes smaller because sessions are being counted differently, leads per session can rise without a corresponding change in the number of people who inquire. A monthly slide that celebrates the ratio but omits the definition change would give the firm the wrong explanation.
The operating response was to mark the boundary and re-establish a baseline. We do not compare those session measures across the fix as if they were produced under the same definition.
A report needs a measurement history
Many firms maintain a record of website changes. Fewer reports make it easy for the reader to see when the definition of a metric changed. The distinction matters whenever a team replaces analytics code, revises bot exclusions, changes consent behavior, or repairs identifier handling.
A small measurement log can carry the necessary context:
| Record | Why the reviewer needs it |
|---|---|
| What is counted | Defines a session, inquiry, call, or outcome |
| What is excluded | Explains the audience represented in the total |
| When the definition changed | Identifies comparisons that need a new baseline |
| What remains unknown | Prevents estimated human traffic becoming a census |
| Which business record can be reconciled | Connects the report to inquiries the firm actually received |
This is not an argument for abandoning analytics. It is a reason to make analytics easier to interrogate. A measure becomes more useful when the person using it can tell which decisions it supports and which it cannot.
The next question in the meeting
When a report shows a large traffic increase, ask which channels and pages account for it, whether the pattern matches recognizable readership, and whether inquiry records tell a compatible story. A discrepancy is a reason to investigate, not immediate proof of a bot problem.
Then ask whether any tracking or filtering change occurred during the comparison. If it did, have the team show a stable period or use a metric whose definition survived the change. Where that is impossible, write the limitation plainly.
The evidence in this note comes from internal operational records, not an independent audience audit. We have avoided repeating historical growth percentages whose interpretation is complicated by the session defect. The finding we can use is more practical: before assigning a business explanation to a rising line, establish what the line counted in each period.