Shrink localised to a store, a category, a week.
You find out about shrink in January. It started in August.
Shrink is measured at physical inventory counts, so it arrives months late as one aggregate number with no date attached. The daily data that would have localised it is already being collected. Shrink watches that data and returns a store, a category, and a date range worth investigating.
A location and a date range for investigation. It identifies no individual and assigns no cause.
Sixteen real series, one store-department pair, detection computed live in your browser.
The problem
One number, twice a year, with no date and no location.
A physical inventory count tells you that a store lost product. It does not tell you which weeks, which categories, or what changed. By the time the number lands, the schedules, the CCTV retention window, and the staffing records that would explain it have mostly aged out, and the investigation starts from nothing. Meanwhile the chain-wide shrink rate on the executive dashboard cannot move at all: one department in one store out of hundreds is a rounding error in the aggregate, which is exactly why the aggregate has never localised anything.
The insight
The count is the lagging indicator. The leading ones are daily.
Shrink itself is only observable at a count, but the behaviours that produce it are observable every day and already logged. Unexplained unit variance at cycle count, void transaction rate, no-sale drawer opens, and the gap between units that left the shelf and units that were sold all live in POS and inventory systems that every chain already runs. None of them means anything on its own, because every store has its own baseline for all four. What means something is four of them changing together, in one store-department pair, on one date, while sales volume and foot traffic at that store hold flat. That is a changepoint problem across a large grid of store by category series, and the grid is what makes multiple-comparison control mandatory rather than optional: a five hundred store chain with twelve departments is six thousand combinations, and testing six thousand things at five percent without correction sends three hundred teams to the wrong building.
CUSUM on day-over-day percentage changes and Bayesian Online Changepoint Detection (Adams & MacKay 2007) per store by category by measure, with Benjamini-Hochberg FDR control across the entire grid so the surviving alerts are the ones that survive knowing how wide the grid is.
How it works
Four steps, no data science team
Transaction log, cycle count adjustments, receipts, and a daily traffic count if you have one. NCR, Toshiba, Oracle Retail, Lightspeed, or a nightly warehouse export.
Unexplained unit variance, void rate, no-sale drawer opens, sell-through gap, and refund rate, each held per store and per department with its own baseline and its own weekly shape.
Every cell runs through CUSUM and BOCD. Benjamini-Hochberg then prices in the width of the grid, which is the difference between a queue of three hundred locations and a list of one.
Store, department, start date, which measures moved and which did not, delivered while CCTV and scheduling records for that window still exist. It names a place and a period. It does not name a person and it assigns no cause.
Who it is for
The loss prevention director who gets one number per store per year
Retail loss prevention and asset protection teams at chains of fifty stores and up, with a central POS data warehouse and a physical count cadence measured in months. Usually the team already knows shrink is concentrated somewhere and has no way to prove where.
Pricing
- –Full detection engine
- –Weekly digest
- –One data export
- –Every store and department cell
- –Daily detection with FDR control
- –Case-file export with the statistical trace
- –Slack, email, and case-management webhook
- –Three years of history
- –VPC deployment
- –Custom measures and category hierarchies
- –Multi-banner rollups
- –SSO and audit log
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Appriss Retail | Exception reporting and return-fraud scoring across the transaction log. | Scores transactions and associates against rules and models built for that purpose. Strong at the transaction question, and structurally not asking the inventory question: whether a location started losing product. |
| Agilence | Retail exception reporting with configurable rules over POS data. | Rules over thresholds, tuned by an analyst, per rule. Nobody tunes six thousand cells, and a fixed threshold cannot tell a store that changed from a store that was always high. |
| Everseen / computer vision at the lane | Camera-based detection of scan avoidance at self-checkout. | Catches one mechanism at one point, in real time, and it is good at it. It sees nothing in the stockroom, the back door, or the receiving process, which is where a lot of the units go. |
| The count, plus a district manager’s judgement | What most chains under a few hundred stores actually run. | Twice a year, one number, no date. It is not wrong, it is just the slowest possible feedback loop, and it cannot be acted on because everything that would explain it has expired. |
The honest failure mode is misuse. This product identifies a location and a window; the moment a customer treats an alert as evidence about a specific employee, it has been used for something it cannot support, and both the customer and this company have a serious problem. Product copy that says so is necessary and not sufficient, and enforcing it in a customer’s investigation process is not something a vendor can do. The commercial failure mode is quieter: chains that already run exception reporting will ask why this is not a rule in the tool they own, and the answer, that thousands of simultaneous tests need a correction their tool does not apply, is a real answer that takes ten minutes to explain to somebody who has nine.
Market
Priced per store, against a loss line that is already measured
At $18 per store per month a 400-store chain pays $86k a year, which is a small fraction of what that chain writes off to shrink annually. There are several thousand North American and European chains above fifty stores. Fifteen hundred chains averaging 200 stores is $65M ARR, sold to a loss prevention function that already has budget and already reports on this number.