How to Spot AI Agents in Your Analytics Before They Warp Your Conversion Rate
AI agents now browse, click, and buy like customers. Field notes on identifying agent sessions in your logs, segmenting them at collection, and keeping conversion rates honest.
On this page
- Three visitor classes, one honest one
- What the log lines actually say
- The distortion math nobody runs
- Authentication is arriving. Capture it at the first mile
- A segmentation scheme that survives contact with real logs
- Edge cases from the field, filed for the skeptics
- How we stand up agent classification on engagements
- When is edge classification more plumbing than the traffic justifies?
- Sources
At 3:14 a.m. last Tuesday, a "visitor" landed on a client's pricing page, scrolled to 92% depth in under 400 milliseconds, opened four PDPs in eleven seconds, added nothing to cart, and left. Chrome user agent. Residential-looking IP. GA4 counted it as a session, and the CRO dashboard counted it against conversion rate. It was almost certainly an AI agent running an errand for a human who will show up Thursday with a decision already made.
That session is no longer an anomaly. Per Cloudflare Radar, automated systems crossed 57% of HTTP requests to web content in June 2026, the first time bots have outnumbered humans in the company's data. And the fastest-growing slice is exactly the kind that behaves like a customer: HUMAN Security measured 7,851% year-over-year growth in traffic from AI agents and agentic browsers in 2025, with automated traffic overall growing eight times faster than human traffic. More than 95% of that AI-driven traffic concentrated in three verticals: retail and ecommerce, streaming and media, travel and hospitality. If you run a store, you are the target demographic.
Three visitor classes, one honest one
Field observation number one: "AI traffic" is a lazy bucket. In the logs it resolves into three populations that need opposite treatment.
Crawlers and fetchers. GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot. They request HTML, skip your JavaScript, and never fire a tag. Client-side analytics literally cannot see them, which sounds convenient until you realize your server logs and your GA4 property now describe two different websites. This class distorts infrastructure costs and SEO logs, but leaves your funnel alone.
Full-browser agents. Agentic browsers and operator-style tools drive real Chromium, execute your tag manager, fire pageviews, trigger consent banners, sometimes complete checkouts. These are counted as humans by every default analytics setup I have audited this year. This is the class that bends conversion rates.
AI referrals. Humans who clicked out of ChatGPT, Perplexity, or Gemini. Real people, real intent. Adobe tracked AI-sourced traffic to U.S. retail sites growing 393% year over year in Q1 2026, up 1,324% since the company started counting in October 2024. Adobe's data also shows these visitors converting better than average. Mislabel them as bots and you throw away your best-performing referral channel.
The reporting failure mode is treating all three the same. Block them all and you lose the referrals. Count them all and you corrupt the denominator. The only defensible move is classification.
What the log lines actually say
Some of this traffic announces itself, if you look at the raw headers instead of a GA4 report. Here is the short version of what I keep seeing across client logs:
| UA token | Operator | Job | Runs JS? | Hits client-side analytics? |
|---|---|---|---|---|
| GPTBot | OpenAI | Training crawl | No | No |
| OAI-SearchBot | OpenAI | Search indexing | No | No |
| ChatGPT-User | OpenAI | User-triggered fetches | Rarely | Rarely |
| ClaudeBot / Claude-User | Anthropic | Crawl / user-triggered fetch | No | No |
| PerplexityBot / Perplexity-User | Perplexity | Indexing / user fetch | No | No |
| Agentic browsers (Atlas, Comet, operator-style) | Various | Full sessions, forms, checkout | Yes | Yes, as a human |
Two caveats that matter more than the table. First, user agents are self-reported strings; anyone can send GPTBot from a laptop, and plenty of scrapers wear it as a disguise, so a UA match without IP verification (OpenAI and Anthropic publish their ranges) proves nothing. Second, the most consequential class, the full-browser agents, mostly ships a stock Chrome UA. The declared bots are the easy 80% of volume and the trivial 20% of the analytics problem.
For the undeclared ones, behavior is the tell. Patterns I flag in session-level review: zero pointer events between pageviews, scroll depth milestones firing faster than a human can physically scroll, deterministic navigation (the same six URLs in the same order across "different" sessions), default headless viewports, form fields completed in one paint, and datacenter ASNs paired with consumer user agents. HUMAN's report adds a nastier wrinkle: agents increasingly operate inside authenticated sessions, handed off mid-journey by the actual account owner. Hybrid sessions are the edge case that breaks every binary bot flag I have seen.
The distortion math nobody runs
Take a store at a 2.5% sitewide conversion rate. Suppose full-browser agents quietly become 6% of measured sessions and convert at roughly zero because they are price-checking for a human who buys elsewhere or later. Measured CVR drifts to about 2.35%. That is a 6% relative decline with no change in human behavior, and I have watched a team burn three weeks re-testing a PDP template over exactly this kind of ghost.
Now flip it. Adobe's Q1 2026 data had AI-sourced visitors converting 42% better than non-AI traffic. If your agent-plus-referral blob skews toward those buyers, your CVR inflates and your paid media team starts writing victory memos about a lift they didn't cause. The direction of the error is unknowable without segmentation, and that is the actual problem. Your A/B tests suffer the same disease: agents don't respond to your treatment, so they dilute observed lift and push real winners below significance thresholds. Remarketing pools fill with sessions that will never see an ad. If your attribution already looks strange, run it through the attribution doctor before blaming the agents, but keep them on the suspect list.
Authentication is arriving. Capture it at the first mile
The good news is that agent identity is becoming a protocol feature instead of a forensics exercise. Cloudflare has been driving Web Bot Auth, under which agents cryptographically sign requests using HTTP Message Signatures (RFC 9421) with an Ed25519 key and declare their key directory in a Signature-Agent header. The IETF formalized the architecture in a draft and chartered a working group in early 2026, with OpenAI, Amazon, and Akamai among the backers. Spoofing a user agent string is free; forging a signature is math.
Here is the part most analytics stacks miss: those signatures live in request headers, and client-side JavaScript never sees them. A GA4 tag cannot record a Signature-Agent value it has no access to. This is the core of MetaRouter's argument that "server-side data collection must capture and route agent authentication signals", making the first mile the place where verified agents get fast-tracked and impostors get scrutinized. Whether or not you buy their stack, the architectural point stands: agent identity is a collection-time fact, and if you don't write it down at the edge, it is gone. The GA4 versus server-side tracking tradeoff used to be about ad blockers and Safari's cookie window; agent signals are now the third reason, and arguably the most durable one. If the plumbing is unfamiliar, start with what server-side tracking actually is.
A segmentation scheme that survives contact with real logs
What we deploy for clients, condensed from several messy implementations:
Classify at the edge, before reporting. Every request gets an agent_class verdict at collection time: verified_agent (valid Web Bot Auth signature or CDN verified-bot flag), declared_bot (known UA token, IP-verified against published ranges), suspected_agent (behavioral heuristics past a threshold), ai_referral (human session with an AI platform referrer), or human. Store the raw evidence too: UA string, signature status, ASN, referrer. You will want it when a vendor changes behavior without a changelog, which they do, constantly.
Stamp it everywhere. Push agent_class as a custom dimension into GA4 and as a column into the warehouse, on every event. Do it server-side so declared bots that never execute JS still land in your logs with the same schema. GA4's own IAB-list bot exclusion will not save you here; most AI agents are simply absent from that list, and our GA4 guide covers what the platform filters by default, which is less than most teams assume.
Report with split denominators. Default dashboards get human + ai_referral only. Agents get their own report: which routes they hit, what they fetch, whether they reach checkout. Watch agent CVR separately; when agentic checkout protocols mature, that number becomes a revenue line instead of noise. And decide your exclusion policy per surface: agents out of A/B test analysis and remarketing audiences immediately, but kept in merchandising and content reports, because an agent reading your spec sheets is a proxy for a human's purchase intent.
Feed the clean signal downstream. Ad platforms optimizing toward conversions should learn from human sessions. Poisoned training data makes expensive algorithms confidently wrong. This is the same first-party data hygiene argument as always, with a new adversary; the first-party data playbook covers the pipeline side.
Edge cases from the field, filed for the skeptics
A few entries from the notebook, because the clean taxonomy above never survives fully intact. An agent that logs in with the customer's own credentials inherits the customer's identity graph; we now flag mid-session behavioral discontinuities (typing cadence collapsing to zero, navigation going deterministic) rather than trusting session-level labels. A price-monitoring "agent" from a competitor is functionally a scraper wearing better clothes; verified signatures will eventually separate the two, but today it is ASN reputation and rate patterns. And at least one client discovered that a chunk of "suspected agent" traffic was their own uptime monitoring, tagged by an intern in 2023 and forgotten. Check the boring explanation first. It is usually the boring explanation.
How we stand up agent classification on engagements
This is data and analytics engineering work, and it runs in the same order as any collection rebuild we do. First we follow every tag, event and log line from the first request to the order table and put a dollar figure on what the agent share is distorting: which A/B tests, which remarketing pools, which CVR targets. Then we write the tracking plan, and the agent_class dimension with its values, the raw-evidence fields (UA string, signature status, ASN, referrer) and the per-surface exclusion rules are specified there before anything ships. The build moves collection server-side so declared bots and full-browser agents land in one schema, with the classification checked against known-bot sessions in staging and confirmed against production logs before the GA4 dimension goes live. Finally the split-denominator reports and the clean conversion feed to ad platforms go into the client's own warehouse and BI, documented so the rules can be revised when a vendor changes behavior.
When is edge classification more plumbing than the traffic justifies?
The scheme above is what we deploy, and it is not free. Situations where it needs a different answer:
-
A low-volume site. Edge classification means server-side collection, ASN lookups and signature verification. If agents are a sliver of sessions, that plumbing costs more than the distortion it removes. Do the cheap version first: exclude datacenter ASNs and known monitors with a GA4 filter, and revisit when the agent share is visible in the logs.
-
Heuristics tuned too tight. Zero pointer events and fast scroll milestones also describe keyboard users, screen-reader sessions and reduced-motion mobile browsers. The downside of an aggressive threshold is that you strip real, often disabled, humans out of the denominator and call the result honest. Score rather than gate: flag at collection and decide per report.
-
Excluding agents from experiments once they buy. Today, agents dilute test lift because they ignore the treatment. The catch is that when agentic checkout matures, an agent that converts is revenue, and excluding it understates the winning variant. Re-evaluate the exclusion rule whenever agent CVR moves off zero.
-
Blocking as the policy. We would not recommend it. In September 2026 we audited the homepages of 54 well-known B2B SaaS vendors with our AI Visibility Checker: none blocked an AI answer crawler, and only 2 of 54 blocked GPTBot. Those are large, well-resourced sites, so the audit says what they do rather than what works for a smaller store, but it makes clear that blanket blocking is the outlier.
-
Capturing signatures early. The drawback is a schema you maintain for a trickle until Web Bot Auth adoption spreads. That said, in practice retrofitting header capture into a collection layer is worse than carrying an empty column, so we still store it from day one.
The web's traffic mix crossed a line this year, and the measurement stack largely hasn't noticed. The teams that add an agent dimension now will spend 2027 reading clean funnels and negotiating with verified agents as a channel. Everyone else will spend it arguing about why conversion rate moved. The logs already know which kind of team you are.
Sources
- Cloudflare Radar, bot vs. human HTTP request share, June 2026 (linked above)
- HUMAN Security, 2026 State of AI Traffic & Cyberthreat Benchmark Report (linked above)
- Adobe, AI traffic to retail sites, Q1 2026 (linked above)
- MetaRouter, Agentic Commerce Trends and Statistics for 2026 (linked above)
- IETF, draft-meunier-web-bot-auth-architecture
- Digital Commerce 360, analysis of Adobe's AI-referred retail traffic data, June 2026
