The leaks that cost a large retailer the most are the ones no dashboard flags, because the rate is stable and the cause sits between three teams. Here is where to look, and how to put a dollar figure on what you find.
To find revenue leaks on a large retail website, stop looking only for metrics that moved and start looking for steady rates nobody owns: product-page visits that land on items shoppers cannot buy, measurement that has quietly broken, releases that degraded one platform, traffic shifting toward surfaces that convert worse, and customer flows that stopped running. Then size each one in dollars, because a leak only gets fixed once someone can say what it is worth. The hard part is not any single check. It is that the evidence for most leaks sits in two or three systems owned by different teams, so no single dashboard ever shows an anomaly.
A revenue leak, in this post, means money a retailer should be earning from traffic it already has, and is not, because something between the visit and the order is broken or misrouted. It is different from a sudden drop. A drop gets a war room. A leak gets a line on a slide that everyone has seen for months.
Alerts and anomaly detection look for change. The most expensive leaks do not change. They sit at a stable rate for months, so they look like the normal shape of the business.
At one large retailer we work with, between 7% and 9% of product-page visits were landing on items that were fully unavailable, up to 282,000 sessions a week at the measured peak. The rate had been stable for months, no alarm fired on it, and merchandising owned it as a chronic inventory problem. At the same time, the metric leadership actually watched, mobile-web add-to-cart rate, was falling and being investigated as a page-design problem.
Those two facts were the same problem, and nobody had connected them. The unavailable-page rate was an inventory metric, the add-to-cart decline was a product metric, and the automated bidding that linked them was a marketing system. Three functions, three dashboards, and no anomaly in any single one of them. (The full case study.)
That is the pattern to expect: a leak is usually a stable number in one system that explains a moving number in another.
We check five places, in this order. Each comes with the question to ask and the systems you need to read together to answer it.
Ask: what share of product-page sessions land on items that are out of stock or otherwise unavailable, and where does that traffic come from?
Read together: web analytics, paid media reporting, inventory.
In the case above, the chain was simple once it was laid out. Automated bidding bought clicks on items that had just gone out of stock. Those clicks landed on product pages with nothing to buy. Mobile-web visitors recovered from that dead end far less often than desktop visitors did, so the leak surfaced first in the metric leadership was watching. Most of the affected traffic came from two places: paid search, and the retailer's own category pages, whose availability information lagged the product pages.
That second source matters, because it is the part a retailer controls directly. The team shipped fresher inventory information on category pages, which addressed about 30% of affected sessions and was live two days after the investigation started. A second change fed current inventory into the paid media feed, so bidding stops buying clicks on items that have just sold out. Two of the retailer's own product managers independently reproduced the analysis from their own tools before anything shipped.
Ask: can the number be trusted? Do related metrics agree with each other?
Read together: clicks or sessions, attributed revenue, exposure, and the implied conversion rate those numbers produce.
A KPI that is wrong and believed is more expensive than one that is missing. At the same retailer, clicks on product recommendations appeared to be down 85% year over year and had been carried through several weekly business reviews. Attributed revenue from the same placements was down only about 10%, and the conversion rate those two numbers implied had more than tripled. No shopper behavior produces that. The cause was a tracking variable that had stopped firing on recommendation interactions. (The full case study.)
Two lessons from it apply to any leak hunt. First, broken tracking can point a team at a leak that does not exist, and the redesign that an 85% decline would reasonably have triggered would have spent real money fixing nothing. Second, fixing the tracking did not close the question: in the first clean week, attributed revenue was still down by roughly a quarter against the trailing period. That was carried forward as its own open item rather than folded into the good news. A measurement fix and a revenue recovery are two different things, and a leak audit should report them separately.
We cover the measurement checks in more detail in Why did our ecommerce conversion rate suddenly drop?
Ask: did anything ship in the 48 hours before a metric stepped down, and is the change confined to the platform that changed?
Read together: the metric by platform, the release or change-management log, the tag manager history.
At the same retailer, every web placement for recommendations later stepped down by about two-thirds overnight while the mobile app barely moved. That web-only signature pointed at a site-wide front-end framework release the previous night, recorded in the retailer's own change-management system. Nobody had connected the release to the metric. The release log and the analytics live in different tools, which is exactly why release-driven leaks persist.
Ask: has the mix of traffic moved between devices, channels or entry pages, even if each segment's own conversion rate looks healthy?
Read together: conversion rate and traffic share for each device and channel, over the same periods.
A mix shift can hide a leak inside a number that looks fine, or make a healthy segment look sick. In one investigation at the same retailer, desktop accounted for 88% of a conversion decline, even though desktop conversion was actually up close to a full point on the year. Its share of visits had fallen from roughly 23% to 17%, so traffic reallocating from the best-converting surface to the worst was swamping a real rate gain. (The full case study.)
Ask: are the automated flows that bring revenue back, such as replenishment, win-back and abandoned-cart emails, still sending at their usual volume?
Read together: messaging platform logs, change logs, order history.
This leak is common after a platform migration. For example, a company switches email platforms and a campaign that brings lapsed customers back is left paused. Emails stop, those customers do not return, and revenue drifts down slowly enough that no weekly comparison flags it. The explanation is spread across the change log, a ticket, the message logs and order history, and each system only holds one piece.
A leak without a dollar figure loses every prioritization meeting to a project that has one. Size it with a model simple enough that anyone can check it, and state the assumptions next to the number.
Two worked examples from the published case studies show the method. For dead-end traffic, the stated recoverable value was the controllable share of those weekly sessions converting at site conversion and average order value instead of at zero. For investigation speed, the steady state at that account went from about a week to two days from question to resolution, and on the daily revenue exposure of a KPI that size, the five days removed are worth roughly $200K for each investigation that turns out to matter, assuming exposure holds while the issue persists and about one investigation in five is consequential.
Both figures carry their assumptions in the open. That is deliberate. A sized leak that hides its assumptions gets argued about. One that states them gets fixed.
The most expensive mistake in a leak hunt is a confident wrong answer. Three checks prevent most of them.
Not because teams are careless. Large retailers have good analysts and good tools. Leaks survive because each team can half-explain the symptom from its own dashboard, and nobody owns the question across all of them. Merchandising sees an inventory rate, product sees an add-to-cart decline, marketing sees a bidding algorithm doing its job. Every system is working. The leak lives in the gaps between them.
That is the problem Augmeta was built for. Each important KPI gets its own AI Operator, a practice we call Agentic KPI Ops. The Operator watches every cut of the number around the clock and asks of each one whether it is a leak or an opportunity. It reads across analytics, session replay, ticketing, release logs and the warehouse a team already has, sizes what it finds in dollars with the evidence attached, and keeps the question open until the fix is measured. It also reports refuted theories as plainly as confirmed ones, so a team does not spend a week fixing the wrong thing.
How do I find revenue leaks on a large retail website?
Look for stable rates nobody owns, not just metrics that moved. Check five places in order: traffic landing on unavailable products, broken measurement, releases that degraded one platform, traffic shifting to surfaces that convert worse, and customer flows that stopped running. Then size each one in dollars.
Why doesn't anomaly detection catch revenue leaks?
Anomaly detection looks for change. Many of the largest leaks are stable for months, so they look like the normal shape of the business and never trigger an alert.
How much revenue is lost to out-of-stock product pages?
It depends on the share of traffic affected. At one large retailer, 7% to 9% of product-page visits landed on fully unavailable items, up to 282,000 sessions a week at the measured peak. Those sessions convert at close to zero.
How do I measure revenue lost to out-of-stock paid clicks?
Split the unavailable-page rate by traffic source, then multiply the affected paid sessions by site conversion rate and average order value, on the assumption that they would have converted at the site average if they had landed on a buyable page.
How do I size the revenue impact of a website issue?
Multiply the affected traffic or revenue by the size of the effect and the time it persisted, and write the assumptions next to the number so anyone can check it.
Can broken tracking look like a revenue leak?
Yes. A tracking variable that stops firing can make a placement look like it collapsed. At one large retailer, recommendation clicks appeared to be down 85% while revenue from the same placements was down about 10%, which pointed to measurement rather than shoppers.
Who should own revenue leaks at a large retailer?
Someone has to own the question across teams, because the evidence usually spans marketing, merchandising, product and analytics. One way is to give each important KPI an AI Operator that owns the question, with people setting the goals and making the decisions.
Next step: If there is a rate in your weekly review that everyone has accepted as normal, that is where to start. Book a demo and bring it, and we will show you how an Operator would work it.