Agent traffic 4.7x
analytics saw nothing

On a day in September, a browser called Muse started sending requests into DataDome’s network. Over twelve days it sent 29.1 million of them, and nothing in its user-agent said it was an agent. In the same stretch, agentic browser requests on that network went from 12.5 million in August to 58.2 million in September. A new client that does not name itself and a fourfold jump landing in the same month: the relationship between those two facts is more interesting than the growth on its own.

Read the numbers, then read what kind of numbers they are

DataDome published its Q3 2026 AI traffic report on 15 October. Its network recorded close to 25 billion agent requests between July and September, up 41.5 per cent from 17.7 billion in the second quarter. It also offered a more striking comparison: roughly 55 billion requests for the year to date, which means close to half of all the agent traffic it logged in 2026 arrived in the last three months.

The nature of those figures comes first. They are observations from DataDome’s own network, not independently audited, and the public material does not state how many sites the network covers, how large the sample is, or what the counting method is. The company sells bot-detection products, and its narrative strengthens as traffic grows. Independent coverage of the report makes the same point, so treat these numbers as directional rather than as a census of the web.

Flagging the vendor coordinate is not the same as dismissing it. Direction does not need a precise multiple: agent traffic growing faster than human visits shows up across several sources. Precision matters only when you are making a precise decision, and what matters now is what the shift changes structurally.

One undeclared client matching a whole month of the category before it

The most useful detail in the report is the breakdown. Agentic browser requests were 12.5 million in August, which works out at roughly 400,000 a day across 31 days. In September the same line reached 58.2 million, and even with Muse removed entirely it would have been 38.7 million. Muse itself sent 29.1 million requests between 22 September and 3 October, taking 33 per cent of September’s agentic browser traffic while being measured for only nine days of the month.

Set the two daily averages side by side and an unusual ratio appears: August’s entire agentic browser population ran at about 400,000 requests a day, while Muse alone ran at about 2.4 million a day on the same arithmetic. A newly arrived client produced several times the daily volume of the whole category before it. Note that this is our arithmetic on published figures rather than the report’s own conclusion, and it assumes an even spread across days, which the real curve may not follow.

Two details from the sampling matter more than the volume. Of the sampled Muse requests, 99.3 per cent originated from cloud infrastructure such as Cloudflare and Fastly rather than residential networks, and 8.9 per cent hit endpoints such as forms, logins, payments, account creation or shopping carts. The first point means the standard detection stack, which leans on declared identity and residential-proxy signals, does not see this class of client. The second means roughly one request in ten was aimed not at reading a page but at writing into a system.

Another change is hiding in the shares. Meta remained the largest single source at 12.4 billion requests and 49.7 per cent of the quarter, but its share fell from 51.5 per cent in Q2 as non-Meta agents grew faster, at 47 per cent against 36.5 per cent. Sources are diversifying. For a site owner that rules out the special case: block one vendor and the growth arrives from everyone else.

Your traffic now holds three populations

Put those threads together and the visitors to a site fall into three populations. The first is people: they run the page scripts, keep cookies, click, and buy. The second is declared crawlers, which state their purpose in their own name, from search engines to SEO tools to the retrieval bots run by AI vendors. The third is undeclared agents: they originate from cloud infrastructure, do not identify themselves, behave like a browser, and take away machine-readable results.

The trouble is that nearly all site analytics see only the first population. Browser-side measurement needs the client to execute scripts, so crawlers that do not run scripts never appear, while clients that do run scripts but keep no cookies get logged as a fresh session per request. We hit that exact distortion in our own site monitoring: before a filter was added to the analytics loader, the dashboard was inflated by roughly 15x. When the monthly visit number rises, you cannot tell from the number itself whether people grew or something else did.

So reporting has to become three series. Keep the human line next to revenue, because the commercially meaningful quantity is not the absolute count but which way the human share of traffic is moving. The declared-crawler line answers how widely you are indexed and cited. The undeclared-agent line answers what capacity and risk controls are costing. Blend them into one curve and every quarter-on-quarter comparison becomes misleading.

Actually measuring the three series

Splitting the three series sounds like a reporting exercise, but the real difference is the data source. Browser-side analytics sees only clients that run scripts. Origin access logs see every request but cannot recognise a person. Both are needed, and they cannot be added together: the same visit appears on both sides while identity, session and intent mean different things in each.

A workable first pass is to group the origin log by endpoint and by whether the request carries a session identifier, separating reads from writes, then checking how many requests in each group come from a client that declares itself. The first distribution usually surprises people, especially the small slice on write endpoints, which is modest in volume and carries an entirely different order of business impact.

One question only the logs can answer is which pages these clients read. If they cluster on product, pricing and documentation pages, they are answering other people’s questions for you. If they cluster on search and listing pages, they are harvesting structure in bulk. Those two behaviours call for different responses, and browser-side data shows neither.

The cost lands on three ledgers

The first is capacity and spend. Agent reads are mostly repeated requests for the same pages, so cache hit rates look good while origin egress, edge compute and risk-control processing climb, usually on different cost-centre reports. Only by putting agent traffic on its own line do you find out whether it is already setting the size of your infrastructure bill.

The second is conversion metrics. A conversion rate divides by visits, and the visits now include clients nobody needs to persuade. The denominator grows, the numerator does not, and the rate falls on its own. A team that responds by optimising the landing page is fixing the wrong end. Split the denominator so the conversion rate is computed inside the human well only.

The third is distribution. Two kinds of agent matter here. A retrieval bot from an answer engine brings citations and referral traffic, which is a marketing asset. An undeclared request aimed at a write endpoint brings risk and compliance exposure instead. Both sit under the same label of agent traffic, one is wanted and one is not. Govern them with a single allow-list and you are running two opposite things off one switch.

One number deserves separate tracking inside distribution: referral traffic arriving from answer engines. It is usually small and unusually well-intentioned, and the evidence for it is the referrer field in the log rather than the visit total. Collapsing all machine traffic into one number puts a distribution channel and a risk-control cost on the same line, and both decisions go wrong.

Work the numbers a little finer and the ratio matters more than the volume. Growth in agent traffic mechanically depresses any conversion rate computed on visits, and the first reaction in most teams is to blame the campaign or the page. Fix the denominator first: compute the conversion rate only inside sessions that carry an identifier, and carry agent traffic as a load metric on its own. Both trends are worth watching; do not watch two different things through one denominator.

Capacity works the same way. Agent reads concentrate on the same pages, so cache hit rates look healthy while the numbers actually rising are edge requests, risk-control evaluations and origin fetches. Those three usually sit under different cost lines, so only a combined agent-load line shows what changed over a period.

Draw the policy on endpoints, not on identity

For a decade the axis of bot management has been identity: allow what you want by user-agent, block the rest. The most practical information in this report is that the axis is failing. The largest new source does not declare itself, comes from mainstream cloud infrastructure, and points roughly a tenth of its requests at write endpoints.

Move the policy from identity to endpoints and the decision rests on three observable things: which endpoint the request targets, at what rate, and whether it completes a step only a human should complete. A line drawn that way holds whether or not the client declares anything. Reading a page and submitting a form are different acts, and the cost of a casual crawl is not the cost of account creation, whoever is sending them.

One counter-intuitive corollary follows. Cloud infrastructure should not be treated as a suspicious signal by itself: 99.3 per cent of sampled requests came from CDN networks, which is exactly why this traffic resembles normal traffic, and IP reputation would sweep plenty of legitimate business into the block list along with it. The usable signal is the behaviour sequence, not the address.

The whole sequence fits into a week. Day one, pull the origin log and split endpoints into reads and writes. Day two, group by declared identity and session identifier to get three traffic lines. Day three, pull the write-endpoint requests into their own table and mark which sources breached a rate ceiling. Day four, recompute historical conversion rates on the new denominator and see whether the trend changes. A week later you know what denominator your previous capacity budget was standing on.

What these numbers cannot support

Three limits. First, every figure comes from one vendor’s telemetry with no independent audit and no disclosure of network size or sample size, so none of it generalises to the whole web; it supports direction only. Second, Muse’s sampling ratio is unpublished, so 99.3 per cent and 8.9 per cent are sample results rather than full counts. Third, comparing August’s daily average with September’s assumes an even spread across days, and the real curve may be concentrated.

Two claims do hold: undeclared agent traffic is growing fast, and the mainstream way of identifying it, declared identity plus IP ownership, does not work on this class of client. Every multiple beyond that should be cited with its source attached, including the daily-average ratio we calculated ourselves.

Our judgement

Our judgement is that site visitors have split into three populations, and the fastest-growing one happens to be invisible to the tooling most teams trust. That is not a security problem first; it is a measurement problem. It distorts the report before it distorts the capacity and conversion decisions built on top of the report. The first step is not buying protection, it is recording three separate series.

Three moves follow. First, split the traffic report into three lines, people, declared crawlers and undeclared agents, and place the human share of traffic beside revenue, because that ratio is the number that survives a quarter-to-quarter comparison. Second, check whether your current analytics can see clients that do not execute scripts; if they cannot, add a machine-traffic series from origin access logs and keep the two datasets apart. Third, replace identity allow-lists with endpoint and behaviour rules: reading, form submission, account creation and payment each get their own line, and write endpoints get their own rate ceiling.

The question worth leaving with a buyer is this: can you say how much of last month’s traffic to your site was human? If the number cannot be produced, then your capacity budget and your conversion targets rest on a denominator nobody has measured.

References

DataDome press release (via Business Wire, carried by Yahoo Finance), "DataDome Report: Agentic Browser Traffic Surged Nearly 5x in a Month, as Meta’s Muse Arrived Unannounced From the Cloud", 15 October 2026 — source for the 25bn, 41.5%, 55bn, 12.5m to 58.2m, 38.7m, 29.1m, 33%, 99.3%, 8.9%, 49.7% and 51.5% figures

PPC Land, "Meta’s Muse gains a 33% share of AI browser traffic in 9 days, DataDome finds", 15 October 2026 — notes that the report does not state its network size or sample size and that the figures are not independently audited