One Session, Half Human, Half Agent: Analytics Breaks

Hybrid human-agent sessions are the measurement problem nobody budgeted for. On August 7, 2026, Cloudflare published telemetry from Precursor — its session-scoped behavioural detection system — and reported something that quietly invalidates a core assumption in every analytics stack: inside a single session, behaviour often shifts from human to agentic and back again. Not two visits. One visit, two kinds of visitor.

The example Cloudflare gives is mundane enough to be uncomfortable: a person browses a store, then hands the checkout process to an automated shopping assistant. Under the rules your stack runs today, that session gets one classification, assigned once, and keeps it. Either the whole thing is a human — in which case your conversion metrics now include work a machine did — or the whole thing is a bot, and you have just filtered out a real customer with real intent.

This piece covers what Cloudflare actually reported and how far it can be trusted, why point-in-time detection structurally cannot see a mid-session handoff, exactly where each layer of a typical stack goes blind, and a concrete alternative: treat agent-touched sessions as their own reported segment rather than folding them into human traffic or throwing them away.

The source is a Cloudflare blog post titled Unveiling good and bad behaviors on the Agentic Internet, published August 7, 2026 and credited to the company's Web Integrity & Trust team rather than a named author. Its headline data point: in a single 24-hour window at the time of writing, Cloudflare recorded 206 million Precursor evaluation events across 73,438 zones on its network.

Precursor itself was introduced on July 13, 2026 as a client-side, session-based verification system that uses dynamically injected JavaScript to continuously collect behavioural signals as visitors interact with an application. It sits inside Enterprise Bot Management as an optional complement to Turnstile — which Cloudflare says runs nearly 3 billion times per day, but only on high-sensitivity endpoints such as login, signup and checkout, leaving the rest of the session unobserved.

Cloudflare says the volume above let it validate two things at scale. The first is that suspicious behaviour often happens mid-session, which point-in-time detection would not catch. The second is the one with the wider blast radius, because it is not really about security at all.

Take that seriously for a moment and a lot of standard measurement practice stops making sense. A session is the unit almost every report is built on. Bounce rate, pages per session, average engagement time, session conversion rate, assisted conversions, channel attribution — all of them assume the thing being measured has one nature for its duration. If a person browses six product pages and then delegates the checkout, the engagement metrics describe a human and the conversion describes a machine, and they are averaged into the same row.

It is worth being precise about whose claim this is. The human-to-agentic-and-back framing is Cloudflare's characterisation of Cloudflare's telemetry, published by a company whose bot management business benefits directly from operators believing that only continuous, session-level detection can see the problem. That does not make it wrong. It does mean the honest posture is to treat it as a well-evidenced vendor observation worth designing against — not as an independently established fact about the web.

The reason a challenge at the door fails is not that the challenge is weak. It is that the question it asks — is this visitor a bot right now? — has a different answer at minute one and minute nine. Cloudflare's stated design response is to scope evaluation to the session rather than the request, specifically so that, in its framing, a bot cannot reset its behavioural signature by refreshing the page or starting over with a new challenge.

What Precursor collects is narrower than people assume: pointer movement, keyboard activity described as timing and rhythm rather than the keys pressed, focus changes and visibility events. Those are buffered client-side and sent to Cloudflare's edge for evaluation. Cloudflare states the resulting signals are consumed internally by its bot-detection systems and are not exposed to customer dashboards or tied to user accounts, login identities or persistent profiles — which, as we will come back to, is precisely why this does not solve your analytics problem for you.

The company names three behavioural tells it treats as hard to fake over time. Read them as a description of the detection thesis, not as published accuracy figures — Cloudflare has not shipped false-positive rates for any of them.

Notice what these tells are good at and what they are not. They distinguish genuine human input from simulated human input. They do not, on their own, tell you whether an agent acting openly on a person's behalf should be welcome — which is a policy question, and one we worked through separately in our decision matrix for deciding which agents get access at all. Detection and permission are different problems, and conflating them is how sites end up blocking the assistants their customers actually use.

Vendor coverage of this stays inside vendor framing. The more useful exercise is to lay your own stack out and ask, layer by layer, what signal it evaluates, how often it evaluates it, whether it could detect a handoff in principle, and what it drops on the floor without telling you. The table below does that for the five layers most marketing and engineering teams actually run.

Read down the fourth column and the shape of the gap is obvious. The only layer designed to see a handoff is the one whose output is deliberately not exposed to you. Cloudflare built session-scoped behavioural evaluation to make a security decision, and it keeps the signals inside its own detection systems. Nothing in that pipeline arrives in your reporting as a dimension you can segment on.

The pragmatic consequence: if you want agent-touched sessions in your reports, you are going to build that yourself, and raw request logs are the most honest starting material you have. That is the premise behind our work on server-log analysis that sees what GA4's tag never fires for and a 30-day site-log study of agentic crawler behaviour. Neither of those solves the handoff problem on its own, but both give you the one thing the tag cannot: a complete record of what was requested, in order, with timestamps.

Every GA4 property ships with an exclude-all-hits-from-known-bots filter, on by default, that matches the request's user-agent string against Google's maintained known-bot list and drops matching hits before they reach reports. It is a good filter for the problem it was designed for: declared crawlers that identify themselves politely and consistently, which is most of the classic search and SEO crawler population.

It is a string match. That single fact bounds what it can ever do. It cannot see an agent that declines to self-identify, because there is nothing in the string to match. And it cannot see a session that starts human and later hands off, because the string does not change when the driver does — the browser is the same browser, the user-agent is the same user-agent, and by the time behaviour shifts, the classification has already been made and applied to the whole session.

The second-order problem is the session model itself. GA4 buckets a continuous engagement into one session with one set of dimensions — a single default channel grouping, a single device category, a single source and medium. There is no dimension in the model whose value is allowed to change mid-session because the nature of the visitor changed. That is not a bug being fixed in the next release; it is the shape of the data model.

Cloudflare has also started reporting on the other side of this — whether AI assistants can see and cite your content at all — in the dashboard we covered in our look at Cloudflare's Agent Readiness dashboard.

The organising frame behind both Precursor and BotBase is a split Cloudflare draws between Risk — the ephemeral, per-request likelihood that something causes harm — and Trust, which accumulates over time and behaves like reputation. Its argument is that a static allow-or-block rule of the form reject anyone who does X cannot hold context the way a trust-over-time model can. Whatever you think of the commercial motivation, the underlying observation matches what the hybrid-session data implies: a verdict that is correct at request one can be wrong at request forty.

BotBase is where that shows up as a product. It started as a directory of known good bots and has been expanded into a catalogue that also tracks less-than-good and unverified bots and agents — Cloudflare's reasoning being that once its systems validate behaviour for known-good actors, they can also detect when expectations are not met. The Verified standard now reduces to two tests, which the company states as: declare yourself honestly, and do not abuse the trust you have earned. BotBase itself is an Enterprise Bot Management feature, though every tracked bot plus select metadata is mirrored publicly in Cloudflare Radar's bots and agents directory.

One detail in BotBase is worth flagging for anyone about to build reporting on it. Its Requests column tracks Successful versus Unsuccessful over the trailing 24 hours per bot, where Successful means a 2xx or 3xx edge HTTP status. That is a response-outcome metric, not a mitigation-outcome metric — a bot can be recorded as successful while having been served a decoy or a challenge. If you report that column as blocked versus allowed, you will be reporting the wrong thing.

There are only three things you can do with a session that changed character halfway through, and two of them are wrong in opposite directions. Laying them out side by side makes the choice uncomfortable enough to actually get made, rather than inherited from whatever your tag defaulted to three years ago.

The implementation principle that matters is the one Cloudflare arrived at from the security side: classify continuously, not once. In analytics terms, that means an agent-touched flag should be written at the moment behaviour shifts and should apply forward from that event — not be back-stamped onto the session's opening classification, and not overwrite it. You want to be able to ask how many sessions began human and ended agentic, which is a different question from how many sessions were agentic, and a completely different question from how many were bots.

Practically, that lands as three artefacts. A session-scoped custom dimension with three values rather than two. An event fired at the handoff, carrying a timestamp so you can measure where in the funnel delegation happens. And a reporting convention that every behavioural average in your dashboards is explicitly computed on human-only sessions, stated in the dashboard rather than assumed. If your reporting layer cannot express a mid-session dimension change, that constraint is itself the finding, and it belongs in the measurement plan — not in a footnote.

Our own view is that this becomes routine reporting hygiene within a year or two rather than an advanced technique, for a simple reason: the number of interfaces that can complete a purchase on a person's behalf is going up, and none of the parties adding them have any incentive to make that visible to your analytics. Teams that start keeping the three-way split now will have a trend line when the question gets asked in a board meeting. Teams that do not will have an averages problem they cannot decompose, and no history to reconstruct it from. If you want help wiring that into an existing stack, that is the kind of work our analytics and measurement practice does, alongside the agentic SEO work that deals with the other half of this shift.

A large share of the August 7 post is forward-looking, and it is worth separating cleanly from what exists. Precursor was free to use pre-GA at launch in July 2026, rolling out from the Cloudflare dashboard, with general availability promised later this year. No GA date has been announced, and the August follow-up post does not give one. Everything below is announced intent, not a live feature you can plan a Q4 rollout around.

The queuing idea is the one worth watching, because it is the first of these that treats a user-directed shopping agent as a customer with a scheduling problem rather than as an attacker. That is the same conceptual move this whole piece argues for on the measurement side: stop asking whether the traffic is human, start asking what it is trying to do and on whose behalf. Cloudflare also shipped a public interactive demo alongside the August post that shows how Precursor would assess a visitor's own cursor movements — a useful intuition-builder, though it is a vendor simulation of the vendor's own logic, not independent evidence of accuracy.

Our forecast, stated as a forecast: the block-or-allow binary has perhaps a year left as the default mental model, and what replaces it is a graded response — verified agents queued, unverified agents rate-limited, simulated humans challenged — with an identity layer like Web Bot Auth carrying the declaration. The measurement stack will lag that by longer, because analytics vendors move slowly and because the signals that would inform a three-way split currently live inside security products that do not export them. The gap between what the edge knows and what your reports say is likely to widen before it narrows.