Bots in Your Wishlist Data: When Favourites Stop Meaning Demand
Wishlist and favourite actions are cheap to automate and rarely protected. Bot activity there distorts demand signals that merchandising teams use for buys and restocks.
Merchandising teams read wishlist adds as intent, and they should: a save is a shopper telling you what they want at a price or moment they have not reached yet. That signal is worth money in a buying meeting. It is also generated by an action that costs a bot nothing, requires no checkout, often needs no account, and sits on pages scrapers already visit to harvest prices.
So the wishlist count for a product can be part demand, part automation exhaust, and the dashboard does not label which is which.
How the inflation usually looks
Scraper operators favourite items to track price and stock changes through the stores own alert systems, letting the retailer notify them when a price drops. Competitor monitoring, deal aggregation, and reseller tooling all have versions of this. The pattern in the data is tempo and concentration: saves arriving in bursts, at machine regular intervals, spread evenly across a catalogue in a way human shoppers, who cluster on new and promoted products, never are.
Account behaviour gives more away. Accounts whose entire history is saves, with no browsing depth, no purchases, and sessions that hit product pages at a constant rate are not shy shoppers. They are instruments, and their saves should be counted in a different column.
Separate the signal before it reaches a buyer
Do not wait for perfect bot detection at the edge. In the analytics layer, segment wishlist activity by account and session behaviour you already capture: purchase history, session depth, save rate per session, catalogue spread. Report a human weighted wishlist figure alongside the raw one, and make the buying team look at both for a season. The gap between them is itself information.
Alert based features deserve the same scrutiny. If back in stock and price drop alerts are being driven substantially by automated saves, your alert send volumes, and the conversion rates you attribute to them, are telling a story about tooling, not customers.
Protect the action lightly, measure first
Rate limit save actions per account and per session, and require an account for alerts, which most stores already do. Heavy challenges on a wishlist button will punish real shoppers for a data quality problem they did not cause, and a CAPTCHA is the wrong first response to almost every bot pattern that does not involve checkout or accounts.
Measure, segment, then decide what to block with the merchandisers in the room, because they carry the cost of both errors: blocking real demand signals, and buying stock against automated noise.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Scrapers That Hit Size Guides, Stock Feeds, and the Quiet Corners, Reading Bot Traffic in Search and Filter Navigation Logs, and Credential Stuffing Patterns on Store Accounts and What They Look Like.
Frequently asked questions
Why would bots wishlist products?
To use the stores own price drop and stock alerts as a monitoring service. Scrapers, resellers, and competitor tools save products so the retailer notifies them of changes.
How can bot wishlist activity be spotted?
Look for machine regular timing, bursts, even spread across the whole catalogue, and accounts or sessions with saves but no browsing depth or purchases. Human demand clusters on new and promoted products.
Should wishlist buttons get a CAPTCHA?
Not as a first response. Rate limits and requiring an account for alerts are lighter. Segment and measure the activity first, then block with evidence about how much is automation.
How should merchandising teams use wishlist data?
Alongside a behaviour weighted version that separates likely human saves from automated patterns. Buying against the raw figure alone risks stocking for bots.