Bot Traffic IndexThe bot problem, quantified

Sep 15, 2026 - Bot Traffic Index

The Economics of Inventory Bots: Who Pays When Bots Buy First

On paper, a sellout is a sellout. If bots clear your limited release in ninety seconds, the revenue looks identical to a human sellout. The damage shows up everywhere except the top line.

The real costs

Customer trust. Genuine shoppers who repeatedly lose drops to bots learn that your store is not worth trying. That is a churn event that never appears in churn reporting. Data quality. Bot purchases pollute customer records, sizing curves, and demand forecasts - you start planning inventory for a buyer mix that does not exist. Support load. Drops followed by waves of 'order canceled' and 'why did this sell out' tickets cost real hours. Marketplace leakage. Your product immediately appears on resale platforms at a markup, training your best customers to shop there instead.

Why simple defenses fail

Rate limits and CAPTCHAs catch crude bots and frustrate real customers at exactly the wrong moment - during the drop. Modern purchasing bots route through residential proxies, rotate device fingerprints, and solve challenges faster than humans. Queue systems help fairness but do not stop automated buyers from joining the queue.

What works

The effective stack is behavioral: detection at the network edge that scores sessions on signals bots cannot cheaply fake, applied before the storefront ever sees the request. Blocking scraper and hoarder traffic at the edge also restores analytics accuracy as a side effect - fake sessions never reach your pixels. Post-purchase order screening is the second line, not the first.

The takeaway

Inventory bots are not a security footnote; they are a customer-experience and data-integrity problem with a revenue-shaped hole in the middle. Measure them, block them at the edge where possible, and stop counting bot demand in your forecasts.

Build a Bot Baseline: Weekday and Weekend Patterns Are Not the Same Traffic

A single average bot share hides the pattern that identifies automation: bots keep office hours or ignore weekends entirely. How to baseline bot traffic by hour and day before judging any spike.

Human traffic has a week. It dips in the small hours, swells at lunch and in the evening, and changes shape at the weekend. A surprising amount of automated traffic has a week too, but a different one: some operations run on schedules set in another time zone, some run flat out around the clock because nobody pays their electricity bill by the hour, and some go quiet at weekends because the operator does.

An index built on daily averages cannot see any of that, and so it keeps misreading Tuesday. This post sets out a baseline method, bot share by hour of day and day of week, that turns the vague sense that traffic looks odd into a picture with a shape you can compare against, week after week.

What the baseline reveals

Compute bot share, however your tooling classifies it, in hourly buckets for a month, then lay the seven days over each other. Human driven invalid traffic, the misclicks and internal testing and known crawlers, follows the human curve at a roughly constant share. Scheduled automation stands out as geometry: a block of elevated share from 02:00 to 05:00 your local time that repeats to the minute, a share that doubles at weekends when human volume halves but the machines do not, a ramp that starts exactly on the hour, every hour.

That last pattern, share rising at weekends, fools teams repeatedly. Absolute bot volume is flat; the human denominator fell. A store that reports only volume concludes the weekend is clean, while its conversion rate and analytics for Saturday describe a store where bots were a third of the room.

Using the baseline to judge events

With a baseline in hand, a spike stops being a vibe. Compare any incident, a launch, a sale, a suspected attack, against the same hours on the same weekday in the baseline: the excess over expected share, in the hours it persisted, is the size of the event, and its shape, spiky and vertical versus a step change that stays, separates a scraper run from a credential stuffing campaign from a marketing success. Each of those wants a different response, and the baseline is what lets you choose in the first hour instead of the postmortem.

Refresh the baseline quarterly, not weekly: it must be stable enough to be a reference, and it should be rebuilt after any change in how traffic is classified, because a new detection rule redraws the past it is compared against.

Related reading: Glossary, About, How to Tell If Bots Are Skewing Your Store Analytics.

Frequently asked questions

Why does bot share rise at weekends if bot volume is constant?

Because share is a ratio. Human traffic falls at weekends on many stores while scheduled automation runs unchanged, so the same absolute bot volume becomes a larger fraction. Reporting volume alone hides this; reporting share alone overstates it. A baseline tracks both.

What time patterns most strongly suggest automation?

Exact repetition: activity starting on the hour, blocks at identical times daily, steady volume through the local night, and no weekend variation where your human traffic clearly varies. Humans are rhythmic but sloppy about it. Schedules are not.

How long a period should a bot baseline cover?

A month of hourly data is the practical minimum, enough to show each weekday several times and smooth out one off events. Refresh quarterly, and rebuild it whenever your detection or classification rules change, since the baseline is only comparable within one measurement regime.

What do we do with a deviation from baseline?

Size it first: excess share, hours persisted, and which pages or endpoints it touched. The target decides the response, login and checkout concentration suggests credential or card testing, catalogue concentration suggests scraping, site wide suggests a blunt crawl. The baseline tells you something happened; the distribution tells you what.

Frequently asked questions

Who pays when bots buy limited stock first?

Almost everyone except the bot operator: genuine customers pay resale prices or miss out, the store pays in support, returns, and reputation, and the market pays as launch data and pricing signals fill with automated demand.

Why do stores tolerate inventory bots for so long?

Because bot purchases still record as sales, and the costs land in other budgets: support time, chargebacks, customer anger, and distorted demand data. The revenue is visible immediately. The costs are diffuse and delayed.

What is the real cost beyond the sold out product?

Corrupted information. Launches read as more popular than they are, waitlists inflate, and stock and pricing decisions get made on demand that was never human. The store optimises for an audience of scripts.

What actually reduces inventory bot economics?

Raising the cost per attempt: verified accounts for limited drops, queues that reward patience over speed, per customer limits enforced across identities, and detection aimed at behaviour. Defences work when they make botting unprofitable, not merely harder.