Product cannibalization: when a new SKU eats an old one's demand
Product cannibalization explained from your own data — a before/after dataset, how to detect a new SKU eating an old one, and when that's fine.
InventoryX is in development and not available today. ClearStock is the live Shopify app.
Product cannibalization is what happens when a new SKU's sales don't come mostly from new customers — they come out of an existing SKU's demand. You launch a second phone case, total case sales rise less than the new case sells, and the old case quietly drops. Nothing is broken, no alert fires, and both SKUs look individually healthy on a sales report; the loss only appears when you read the two rows together. For a small catalog, cannibalization matters twice: it distorts your demand forecasts (the old SKU's history is suddenly a lie), and it eats the margin math you used to justify the new product in the first place. Short answer: you detect it by comparing the incumbent SKU's demand after the launch against what its own history would have predicted, and the response depends on whether the cannibalization is a bug or the strategy.
A before/after dataset: what cannibalization actually looks like
Realistic illustrative numbers — a store selling spices sells one chili blend, CHILI-ANCHO-80G, steadily for a year. In March they launch a hotter blend, CHILI-OROUR-80G. Here's the same quarter, before and after the launch:
Before launch (Q4 prior year, quarterly demand):
| SKU | Q4 units | Trend | Notes |
|---|---|---|---|
| CHILI-ANCHO-80G | 612 | stable ±5% | Only blend in the line |
After launch (Q2, same-length quarter):
| SKU | Q2 units | Expected without launch | Actual vs. expected |
|---|---|---|---|
| CHILI-ANCHO-80G | 402 | ~610 (stable trend) | −208 (−34%) |
| CHILI-OROUR-80G | 291 | — (new) | +291 |
| Blends total | 693 | ~610 | +83 (+14%) |
Read the last row first: the new blend sold 291 units, but the category only grew 83. The other 208 units didn't materialize from thin air — existing ancho customers switched. That 71% cannibalization ratio (208 of 291 new-unit sales) is the number a per-SKU sales report never shows you.
Now the forecast damage, which is the part that bites later: if you forecast the ancho blend from its trailing-year history, you'll expect ~610/quarter and order for it — while actual demand runs ~400. The excess lands as slow stock, the SKU starts looking weak on aging reports, and unless you know about the launch event, you'll misread a deliberate assortment change as mysterious demand decay. Any forecasting approach built on trailing history carries this same blind spot across a launch; the correction is a manual one — mark the launch date and treat pre-launch history for the affected incumbent as no longer representative.
The detection method: expected vs. actual, one SKU pair at a time
You don't need a statistics package. The workable routine for a small catalog:
- Pick the candidate pair. When you launch a new SKU, name its most likely incumbent victim at launch time — the SKU you'd guess it competes with hardest. (You already know; you designed the new product against something.)
- Establish the incumbent's expected demand. Take the incumbent's trailing 6–12 months, note its trend, and write down one number: "expected quarterly demand absent any change." Rough is fine; the method's power comes from having written it before looking at post-launch data.
- Wait one full replenishment cycle after launch — shorter and you'll read launch-promo noise as cannibalization.
- Compare, then compute the overlap ratio: (expected − actual incumbent demand) ÷ new SKU units sold. Near zero means the new SKU found genuinely new demand; approaching 1 means it mostly relabeled existing demand.
- Check price and margin, not just units. If the new SKU's unit margin is higher, cannibalization can be profitable on purpose (the trade-up case below). If it's lower, you've built a machine for converting margin into volume.
The subtlety worth respecting: some incumbents dip for reasons that have nothing to do with the new SKU — seasonality, a period spent out of stock, a price change. Before attributing the dip, check the incumbent's in-stock record over the comparison window; a SKU that spent three weeks unavailable has its own explanation for soft demand, and it's not cannibalization. This is the same read-your-data-honestly discipline behind separating zero-sales days caused by no stock from zero-sales caused by no demand.
When cannibalization is the strategy (and when it's a leak)
Not all cannibalization is a mistake. The honest framing: cannibalization is bad when it moves demand from a higher-margin SKU to a lower-margin one for no market gain; it's fine — sometimes the whole point — when it captures demand that would otherwise go to a competitor, or trades up.
| Pattern | What the data shows | Verdict |
|---|---|---|
| Trade-up | New SKU has higher margin; incumbent dip is smaller than new gains; total category margin up | Good cannibalization — keep it |
| Defensive | A competitor's product would have taken the sale; new SKU holds a customer you'd otherwise lose | Good — invisible in your data but real |
| Me-too duplication | Two SKUs, nearly identical, splitting one demand pool; combined units ≈ old single-SKU units; added operational cost | Bad — you paid for a second SKU's carrying cost and attention to stand still |
| Margin leak | New SKU is cheaper per unit and pulls down-mart; category margin falls | Bad — you're discounting yourself via assortment |
The me-too pattern deserves a blunt note: every SKU carries real costs beyond its product cost — a shelf or bin location, count attention, reorder attention, minimum-order exposure. Two SKUs sharing one demand pool means paying those costs twice to serve the same customers. If that's where your catalog is drifting, the pruning side of the conversation — which SKUs to cut and how to decide — belongs to the SKU rationalization process; this article stops at the diagnosis.
The forecast and buying fallout — the operational half
The reason a merchandising topic sits in an inventory library: undetected cannibalization quietly corrupts every number you buy with.
- The incumbent over-orders. History-based forecasts say ~610; reality is ~400; the gap becomes slow stock and an aging problem that shows up two quarters later, decoupled from its cause.
- The new SKU under-orders. If the new product pulls more demand than expected because it's taking share from the incumbent, its own thin history makes it look slower than it is — and a stockout on the new SKU mid-halo sends its new customers back to the incumbent, muddying the data further.
- Category-level buying hides both. If you reorder at the category level ("blends total"), a stable category total can mask a healthy mix shift — or an unhealthy one. Category totals are where cannibalization hides; SKU-level attention is where it shows.
The discipline that fixes the fallout costs almost nothing: a launch log. One list — SKU, launch date, named incumbent, expected-vs-actual check date. When you review any SKU's demand history, the log is where you go to know whether a dip is a decay signal or an assortment decision wearing a decay costume.
A caution about reading too much into small pairs
With a small catalog, one quarter of data on one pair can mislead. A 30% incumbent dip can be cannibalization, or seasonality, or a rising competitor, or randomness over a short window. The defenses: compare against the same quarter last year where the category has seasonality, watch two consecutive periods before acting, and weight pairs with more history more heavily than new ones. Cannibalization analysis at small scale is directional evidence for a judgment call, not a verdict — and the judgment call (keep both, merge, cut one, reprice) draws on margin, operational cost, and positioning, not the overlap ratio alone.
Common questions
What is product cannibalization? It's when a new product's sales come largely out of an existing product's demand rather than from new customers — total category sales grow less than the new SKU's sales, because the two products share a demand pool. Nothing looks wrong on per-SKU reports; the effect appears only when incumbent and new SKU are read together.
How do I detect cannibalization in my own data? Before launch, write down the incumbent SKU's expected demand from its trailing trend. One full replenishment cycle after the launch, compare actual demand against that expectation and compute the overlap: (expected − actual) ÷ new SKU units. Check the incumbent's in-stock record first — a dip caused by stockouts isn't cannibalization.
Is product cannibalization always bad? No. If the new SKU carries higher margin, trades customers up, or captures demand that would have gone to a competitor, cannibalization can be profitable by design. It's a problem when it shifts demand from higher-margin to lower-margin SKUs for no market gain, or when two near-identical SKUs split one demand pool while doubling carrying and operational costs.
How does cannibalization affect inventory forecasting? The incumbent's trailing history stops being representative the day the new SKU launches — forecasts built on it over-order the shrinking incumbent and under-order the growing newcomer. Log launch dates against affected SKUs, and treat pre-launch history for the incumbent as retired from forecasting until a new stable trend forms.
What should I do about a cannibalizing product? First establish which pattern it is — trade-up, defensive, duplication, or margin leak — because the right action differs. Duplication and margin-leak patterns feed the pruning decision, which is a separate process involving margin, operational cost, and catalog strategy; the diagnosis here just puts the pair on that agenda with numbers attached.
Next step
Look at your last product launch and name its incumbent — the SKU it competed with hardest. Pull that incumbent's trailing-year trend, write down its expected quarterly demand, and compare it to the last full quarter of actuals. If the gap is more than the noise band the SKU normally runs in, you've found the launch's real cost — or its real success — and either way it belongs in a launch log before the next one.