Bots 10:1 on DDR5 cards: a blow to price monitoring

August 21, 2026 Jérôme Segura, Vice President of Threat Research at the anti-bot company DataDome, published a figure that quickly spread across tech publications: on DDR5 memory cards at one major retailer, bots account for 91% of all traffic — approximately ten automated requests for every one live visit. In the spring, the ratio was 6:1 for the same company. Over the course of a few months, the pressure from automation on product pages has nearly doubled.

For those who legally collect prices and stock — repricing, MAP control, assortment analytics — this is bad news not because "scalper competitors are getting ahead." It's because retail is now configuring defenses based on a behavior profile that looks identical for both standard price monitoring and scalper bots.

What was found and how much can we trust it

The public narrative is based on two reports from DataDome. The March analysis provided details on one campaign: over 50,000 requests per hour, 91 product items under observation, with an average of 551 requests per card — meaning a stock check every 6.5 seconds. One operation managed to make over 10 million requests before it was blocked. The August update added a share: 91% of traffic and a ratio of 10:1.

Now, some honest disclaimers without which the figure becomes marketing noise:

This is one unnamed retailer, not a market snapshot.
DataDome did not publish the sampling window or methodology — what exactly was considered a "bad bot" remains at their discretion.
The company sells a product that blocks exactly this traffic. The conflict of interest does not invalidate the data, but it requires adjustment.
Most importantly: requests to the page do not equal purchases. The metric shows the pressure of monitoring on the listing, not the share of the product actually purchased by bots.

The last point is more important than all the others. 91% of "bot traffic" does not mean 91% of scalpers. This share includes all automated activity: price aggregators, third-party repricers, discount tracking services, analytical crawlers, and your own monitoring. The retailer sees one overall wave and responds to it with one general rule.

Why this is happening: memory has become a scarce asset

The context is simple. A 32 GB DDR5-6000 kit that cost around $72 a year ago is now selling for an average of $392 in August. 64 GB kits have risen in price by about 485%, to $1118. The spot price for DDR4 chips hit a record in early August — $42.45. Top 128-gigabyte sets have increased nearly tenfold. The reason is not gaming modules: production capacities are being consumed by AI accelerators, HBM, and server memory — according to industry forecasts, data centers will take about 70% of the global memory chip output in 2026, and the shortage will last at least until the fourth quarter of 2027.

When a product's price increases fivefold and it disappears from shelves, the difference between retail price and resale price justifies any infrastructure for reselling. Hence the intensity. Moreover, the targets have expanded beyond consumer retail: automation is hammering the pages of suppliers like Micron and Apacer, as well as manufacturers of DIMM sockets and CAMM2 connectors — Amphenol, TE Connectivity. Resellers have moved up the supply chain.

The signature that affects legal monitoring

Here’s a description of bot behavior from the DataDome report — read it as a checklist for your own scraper:

Cache bypass. A unique parameter is appended to each HTTP request to get a fresh page rather than a cached response from the CDN.
Human-like rhythm. A day-night load profile that mimics normal hours of activity.
Tempo just below the threshold. The frequency is set so that volumetric alerts do not trigger.
Flat session. Accessing one product card — and exiting. No cart, no search, no browsing through the catalog.

Now, look at typical corporate price monitoring. It navigates direct links to SKUs from its database. It adds a parameter to avoid catching yesterday's cached price. It operates at a fixed interval, determined empirically "to avoid getting banned." And it never puts anything in the cart. This is the same signature. The only difference is the intent, and the anti-bot engine does not measure intent.

The practical conclusion is unpleasant: tightening defenses against scalpers automatically impacts legal data collection, and there’s no one to explain this. We’ve already discussed a similar effect on another platform — when Amazon began flagging regular customers as bots due to behavioral thresholds rather than IP.

What to change in your data collection right now

Changing the IP pool helps little here: the signal comes from behavior, not the address. The order of operations that genuinely reduces the share of blocks:

Avoid uniform timing. A request every 6.5 seconds with metronomic precision is not "human-like," it's a signature. Jitter is needed over a wide range (e.g., 20–180 seconds for one item) and varied distribution throughout the week.
Stop breaking the cache on every request. A unique cache-buster in the URL is the cheapest marker of automation. Freshness should be checked selectively and only for volatile SKUs; others should be taken as is.
Give the session depth. Enter through a category or search, one or two neighboring products, then target the specific card. This is more expensive in terms of traffic but eliminates the "flat" profile.
Prioritize SKUs by volatility. A product whose price changes once a week does not need to be queried every thirty seconds. The frequency should follow the volatility, not the size of the list.
Separate pools by task class. Retail monitoring, checking search results, and collecting reviews should not come from the same addresses: triggering protection on one scenario should not kill the others. For product cards of large chains, residential proxies work most reliably, while the data center pool should logically be reserved for public APIs and internal checks.
Count successful records, not gigabytes. As protection tightens, the share of retries increases, and the price per gigabyte no longer reflects reality — why $/GB lies and how to calculate the cost of a successful record has been discussed separately. In conditions where 9 out of 10 requests to a listing are automated, the metric "cost of a valid price in the database" becomes the only honest one.

How to tell if you're already being cut off

Blocking on product pages rarely looks like an honest refusal. More often, it’s silent, and monitoring continues to write garbage to the database. Signs that this is happening:

Increase in the share of 429 and 403 errors with unchanged task volume — the simplest indicator if you are logging response codes at all, not just parsing results.
Always "out of stock." A classic soft response: the page is served, the price is in place, but the stock block is replaced. Monitoring sees valid HTML and raises no alarm.
Price has "stuck." A cached version from a week ago is returned — the same effect that caused bots to start breaking the cache with parameters.
Response delay is increasing specifically on product cards, while categories and search load normally: throttling has been applied to the suspicious segment.
Sharp discrepancy in sampling. If data for some SKUs is updating while others are stuck — you are already partially in the filter, just not completely.

A practical approach is to keep several "control" products whose prices can be checked manually or from a second independent source, and compare them once a day. A discrepancy between the control group and what is visible in the browser means that the parser needs fixing, not the request profile.

Why simply rotating IPs no longer solves the issue

The reason why changing addresses is becoming less effective is that the decision to block is made across several layers at once, and IP is only the first of them.

Network layer. The reputation of the address and autonomous system, the share of data center ranges, the density of requests from one subnet. Here, rotation really helps.
Transport and client layer. TLS fingerprint, order of headers, client version. A 2021 library with a rare combination of ciphers reveals itself before it even reaches business logic.
Behavioral layer. The very one described by DataDome: intervals, session depth, absence of a cart and search, cache-buster. This layer is not tied to the IP at all — you can change the address on every request and still remain the same bot.

Hence the main practical thesis of the August story: investing in the quality of the pool yields returns only when combined with correcting behavior. Separately, the first is just paying for traffic that will still be filtered out at the third layer.

Where this is heading next

The memory shortage will last for years, meaning the pressure on product cards will not subside. Retail will respond with obvious measures: purchase limits, queues, mandatory authorization to view stock, behavioral scoring instead of simple IP limits. Some of these measures are already standard in ticketing and sneaker verticals — now they are coming to computer hardware and, further, to industrial components.

For teams relying on external data, this means a shift in approach: the era of "set up IP rotation and collect" has ended where the product is scarce. What works now is a realistic pace, meaningful session depth, pool separation, and a sober accounting of result costs. If you are just starting to build price collection, begin with the basic scheme from our analysis of proxies for e-commerce: price parsing and competitor monitoring, and then layer behavioral adjustments from this material on top.

And finally. The figure of 91% in itself is not a signal that there are too many bots, but rather that the product pages of scarce goods have become a field where automation competes against automation. In such an environment, the winner is not the one who queries more frequently, but the one who is less likely to trigger the filter.