On-shelf availability (OSA) is the share of expected SKUs that are actually available on the shelf: available expected SKUs divided by total expected SKUs, multiplied by 100. The formula is the easy part. What makes one store’s figure comparable with another chain’s is the denominator and a written set of measurement rules. A number that survives a challenge from a store manager or a retail buyer also needs three things: chronic out-of-stock scored over a rolling window instead of a single audit date, a coverage flag that separates thin data from low availability, and an evidence trail back to the images that produced it.
The on-shelf availability formula and the rules that make it comparable
The denominator matters more than it looks. Inspector Cloud describes the assortment matrix (the list of products contractually required to be on the shelf) as the baseline denominator, so a store with 40 SKUs in its matrix and 36 present during an audit scores 90%. Pazo adds that a useful OSA report documents at least which products were expected, when availability was observed and what exactly qualifies as unavailable, because without those rules two teams can inspect the same stores and produce different numbers.
Timing and aggregation level also move the result. Lemon Dots makes the point that 98% measured at 11 AM at brand level is a worse position than 93% measured at 7 PM at pack level. The 2002 GMA worldwide study by Gruen, Corsten and Bharadwaj found out-of-stock rates consistently highest in the evening (after 8 PM) and lowest in the early afternoon, which means a chain that audits in the morning and a chain that audits at night are not measuring the same thing.
“OOS rate” is also ambiguous on its own. Gruen and Corsten (2008) separate an out-of-stock event from the rates that describe collections of events, and recommend that every use of “OOS rate” carry an adjective naming the attribute being measured. They recommend the industry adopt their seven named rates as its vocabulary:
| Item OOS event rate | Number of OOS events for an item over a unit of time |
| Category OOS event rate | Items in the category OOS at the moment of measurement, as a percentage of items intended for sale |
| OOS duration rate | Total time the item is OOS divided by total selling time in the period |
| Shelf availability rate | 100 percent minus the OOS duration rate |
| OOS lost unit sales rate | Lost units divided by (units sold plus lost units) |
| OOS sales loss rate | Lost monetary sales divided by (total sales plus estimated lost sales) |
| OOS customer impact rate | One minus the shortfall in baskets the item should have appeared in, relative to the expected baskets |
The category OOS event rate is the most commonly reported because it is easy to calculate during a manual audit, and it is a snapshot. A camera-based OSA percentage computed from one capture per day is the same kind of number, whatever the technology behind it.
Worked example: a snapshot score and a duration score for the same item
Gruen and Corsten’s own example uses a store open 24/7 where an item was out of stock for 20 hours in a week: the OOS duration rate is 20 divided by 168 selling hours, about 12%, so the shelf availability rate is 88%. A single audit during those 20 hours would have recorded the item as unavailable, and a single audit outside them would have recorded it as available; neither snapshot gives 88%. The 2002 GMA study calls duration a critical but under-used measure, closer to the consumer’s perspective than a snapshot.
The 8.3% benchmark depends on measurement rules
The widely quoted 8.3% worldwide average comes from the 2002 GMA study’s 40 studies that reliably reported OOS extent, with average highs of 12.3% and lows of 4.9%. The same study lists the factors that move reported extent: the definition of an out-of-stock item, the frequency and timing of counts, the velocity of the items examined, how new and discontinued SKUs are handled, and promotions. Comparing a chain’s figure against 8.3% only means something when those rules match, so we treat it as context for the problem, not a target.
ECR Community notes that various methodologies exist across countries for measuring OSA, with Italy, France, Spain and the Czech Republic holding robust national databases. Before any cross-chain comparison, write down and freeze these rules:
- the denominator (assortment matrix, active listed SKUs, promotional SKUs) and how discontinued or unauthorised items are excluded;
- the availability rule, applied identically across auditors and stores;
- observation time of day and day of week;
- aggregation level (pack or brand);
- which named rate is being reported;
- the canonical store and SKU keys, covered in the next section.
Clobotics puts the requirement plainly: the definition must stay consistent across stores and reporting periods if the measure is to support meaningful comparison.
How do we match store IDs and SKU codes when each chain’s audit vendor reports them differently?
Matching store and SKU codes across chains takes a crosswalk: a maintained mapping from each chain’s native store ID and item code to one canonical store/SKU key, applied before any KPI is aggregated. Gruen and Corsten note that a single incorrect digit in a product code can cause a mismatch that leads to a necessary product not being ordered.
For products, anchor the crosswalk on the GTIN. The GS1 US trade item guideline (2015) requires a one-to-one relationship between a GTIN and the trade item it identifies; when a key field is wrong, the complete GTIN record is reissued (code 18) and all retail data linked to the original key fields is re-linked to the revised ones. GS1 US also says errors should be corrected internally and wherever they were transmitted, including third-party catalogue services and every buyer the GTINs were shared with. A crosswalk should behave the same way: when a chain re-codes an item, map the old code to the new one and re-link the history, rather than overwriting the old row and losing the trend.
Temporary packs get a parent-child rule. Gruen and Corsten describe tying bonus packs to a base item code (for example a base code ending in 0 and pack variants ending in 1 and 2) so all sales for the SKU aggregate under a single code. For OSA, the decision to settle is whether a bonus pack on the shelf counts as the base SKU being available; either answer is defensible as long as every chain uses the same one.
| Crosswalk table | Key fields | Maintenance rule |
|---|---|---|
| Product | canonical SKU (GTIN), chain, native item code, parent SKU, pack variant, manufacturer owner | Re-link history on re-code; never overwrite a mapping in place |
| Store | canonical store ID, chain, native store ID, valid-from, valid-to | Close a mapping on store closure or renumbering; open a new one rather than editing |
The canonical store key is something the reporting team owns and dates, not something a chain feed supplies. If the third-party data provider already supplies a standardised cross-chain store/SKU key, use it directly, after checking that it covers all four chains equally and stays current as chains add stores or re-code SKUs; otherwise build and maintain the custom crosswalk.
When does an out-of-stock count as chronic rather than occasional?
An out-of-stock is chronic when it persists or recurs: either the SKU was missing on a set number of consecutive audits, or its share of out-of-stock observations across a trailing window passes a threshold. Both definitions are scored per store and SKU and recomputed each period, which turns a quarter of audits into a trend line instead of the latest snapshot.
Snapshots do not measure duration. The 2002 GMA study observes that physical audits measure out-of-stocks at specific moments and do not give a precise measure of duration, the attribute that indicates the true damage to sales. Gruen and Corsten’s POS-based measurement of 1,084 events on a US retailer’s 200 fastest-moving items over 14 days, with durations including closed hours, found 40% lasted one day or less, while almost one quarter lasted three days or more. Pazo frames the same point operationally: a shelf gap observed once is not equivalent to a SKU that repeatedly disappears for several hours, so frequency, duration, repeat failures and time to correction should all be tracked. Lemon Dots adds that going empty often and recovering in a day is a better position than going empty rarely and staying out for nine, which is why recovery time belongs next to incidence.
Two rule shapes cover most needs, and the audit cadence decides between them:
- Consecutive-miss rule: a store-SKU is chronic if it was out of stock on each of its last k valid audits. Use it when audits are frequent and evenly spaced.
- Frequency-over-window rule: a store-SKU is chronic if out-of-stock observations divided by valid observations in the trailing W days reaches a threshold, and only if the number of valid observations reaches a stated minimum. Use it when cadence is irregular, so a sparsely audited store is not penalised for the gaps between visits.
The minimum-observations clause in the second rule is what links chronicity to coverage: a store with too few valid audits gets “insufficient data”, not a chronic score. Thresholds need calibrating to each store’s audit frequency, and a quarterly trend view needs at least a full quarter of history behind it. FieldPie’s vendor guidance (daily measurement for high-velocity SKUs, at least three audits per week for long-tail SKUs) is a reasonable starting point for setting cadence, not a standard.
The shape of the recurrence also matters. Gruen and Corsten use a weekly calendar view in which short gaps on any day point to restocking frequency, gaps recurring at the same point each week point to the replenishment schedule, and near-daily gaps point to inadequate shelf space for a fast mover. A chronic score that keeps the day-level pattern behind it is far more useful to a field team than one number per store.
Ranking stores by chronic out-of-stock on the manufacturer’s own SKUs
A manufacturer can rank all of its stores by chronic out-of-stock once it has several audits per store: compute the chronic score over a trailing window, filter to its own SKUs and rank on that; with a single audit date, the honest report is a point-in-time OOS figure and nothing more. Gruen and Corsten recommend building both a product ranking and a store ranking by OOS lost sales.
Weighting by velocity points the ranking at the largest lost sales. Gruen and Corsten found high-demand items had almost six times the lost sales from out-of-stocks of low-demand items, and recommend focusing on the SKUs that make up 70-80% of a store’s sales. A chronic score weighted by each SKU’s sales share ranks a store missing a top seller above one missing a slow line.
The manufacturer filter is a scoping decision with its own trap. Lemon Dots points out that a retailer’s 98% target is set for the retailer’s shelf, not for a brand’s own SKUs. Filtering on ownership is only as accurate as the ownership tag in the product crosswalk, so the tag belongs to the crosswalk’s maintained fields rather than to a one-off spreadsheet.
Treat the chronic threshold as a hypothesis to check. Gruen and Corsten validate POS-based detection by asking how many flagged out-of-stocks actually appear as a hole when store staff go to address them. The same check applies to a chronic ranking: compare the stores it sends reps to against what the reps find, and adjust the threshold when the hit rate is poor. Stores near the bottom of the list on sparse audit history should show their coverage state next to their rank, so a low-confidence position is not read as a firm one.
Can each store’s OSA number carry a coverage or confidence flag?
Yes. Report each store’s OSA alongside a coverage score built from capture frequency and detection quality, and replace the percentage with an explicit “insufficient data” state when coverage falls below the agreed floor. Clobotics lists what shelf data trust depends on: valid evidence, sufficient shelf coverage, reliable product recognition, current master data, consistent KPI definitions, transparent confidence handling and review of uncertain findings. It also asks whether a system can distinguish recognition confidence from evidence integrity.
The floor will need periodic recalibration as layouts and assortments change.
| Report state | Condition | What the reader sees |
|---|---|---|
| Reported | Coverage at or above the floor for the store-period | OSA % plus coverage score |
| Low confidence | Coverage above “insufficient” but below the floor, or a high share of low-confidence detections | OSA % visibly flagged, excluded from rankings |
| Insufficient data | Too few valid captures to support a figure | No percentage; the state itself is reported |
Capture frequency on its own makes a weak coverage score, because a store can upload many unusable images and look well covered. A sturdier score combines the share of scheduled captures that arrived and passed image-quality checks, the share of expected facings actually visible in frame, and the share of detections above the confidence threshold. Agree the definition with store managers before it goes live.
This is reliability work, separate from improving the detector itself: model accuracy says how good a single prediction is, while coverage and confidence reporting says whether the aggregated number deserves trust this week. The empty-shelf pipeline described by Jha et al. (2022) makes the related point that model quality depends heavily on proper data collection, cleaning and annotation.
Camera failure or genuinely empty shelf?
Low-confidence detections should be reported separately, neither folded into the KPI nor silently dropped. Clobotics notes that low-confidence or commercially important exceptions may need human validation before they become business data. Excluding them wholesale has its own cost: if too many uncertain gaps are discarded, real stockouts disappear from the report along with the noise. Classify the true empty positions as well, since an out-of-stock, a planogram non-compliance and a void (an item never set up at that store) call for different fixes, as Vision Group Retail describes, and Gruen and Corsten separate shelf OOS (product in the store but not findable) from store OOS (product not in the building).
A coverage-aware pipeline can tell a camera or detection failure from a genuinely empty shelf, provided the detector’s accuracy and confidence thresholds are validated against manual audits for that store environment, and gaps below the threshold are booked as coverage failures rather than out-of-stocks. At chain scale the difficulty lies in thousands of imbalanced and look-alike SKU classes, constrained edge hardware and a steady flow of unknown products that off-the-shelf models misclassify instead of flagging. TechnoLynx builds that side of the pipeline: framing the gap-classification problem, choosing the confidence-scoring approach, optimising the detector for the required latency on the target hardware and validating it against ground-truth audits before rollout.
If a store manager disputes last week’s number, what evidence do you pull?
Pull the per-image log for that store, category and week: each shelf image, its capture timestamp and camera, the model version, the detector’s outputs and confidence, and the rule that turned them into the reported percentage. TechnoLynx designs that capture-and-scoring log and its retention policy against the existing OSA pipeline and store workflow, integrates the logging and retrieval with the detection pipeline, and validates that the logged records reconstruct the reported KPI correctly.
Superlinked’s shelf-audit example shows what makes such a trail checkable. Its pipeline links a detected gap to the adjacent price label purely by geometry, with no hardcoded product names, so a reviewer without domain knowledge can follow the detected gap, the overlapping boxes, the crop and the OCR text from saved artifacts. If the system had been told which product to look for, a sceptical reviewer could not separate detection from confirmation bias. The same write-up observes that a percentage such as “shelf availability 94%” is only as good as the evidence behind it.
The log should also prove correction, not only detection. Pazo notes that recording a completed store visit or audit does not prove the availability issue was resolved, and that photo evidence with follow-up verification shows whether the shelf was actually corrected.
A 2026 guide to storing security camera footage for compliance cites PCI DSS Requirement 9.1.1 as a 90-day minimum for footage covering payment card areas, and recommends setting retention per camera zone rather than system-wide. Start from that floor, then extend the shelf-evidence window to the longest dispute window the business recognises. The same guide holds that chain-of-custody logging (who accessed footage, when and why) is what turns raw video into evidence an auditor will accept.
Three practical constraints follow. The log has to be tamper-evident, which in practice means append-only storage with hashed records, or it will not hold up when the number is contested. Raw full-resolution frames are expensive at chain scale, so keeping gap crops and detector outputs for the full window and full frames for a shorter one is a reasonable split. And shelf cameras can capture shoppers, so retention length is a privacy decision as well as an evidentiary one.
What to report monthly so chains can see the fix is holding
A one-off fix is proven by a recurring report, not a sign-off: a root-cause-to-fix trace, before-and-after metrics, and a monthly report of false-alert rate, detection power, coverage and OSA that stays within agreed tolerance across several consecutive months. TechnoLynx assembles that evidence through Production AI Reliability, starting from the current detection pipeline and the manual-audit ground truth it can be checked against, and producing the evaluation harness, regression checks and drift monitoring that keep the monthly figures honest.
Montoya and Gonzalez (2019) define type I error (non-OOS observations classified as OOS), the false-alarm rate and power of detection (the share of true OOS correctly identified). They also spell out the trade-off: pushing detection power up means sending alerts at lower probability, which raises false alarms, while a conservative system leaves many out-of-stocks undetected. Their POS-based model reached a 15.12% false-alarm rate and 63.48% detection power on average across products, which shows that even a published detector carries both errors at once. Report both error rates, never one.
Be explicit about what is not measured. Gruen and Corsten report that 85-90% of POS-flagged items proved OOS or a shelf-tag error in manual audits, while the false-negative rate stayed unmeasured. A camera-based report should state the same way which error rates come from audited samples and which are unknown.
| Monthly metric | Source of truth | Stability test |
|---|---|---|
| False-alarm rate | Alerts checked against audits or rep visits | p-chart control limits |
| Power of detection | Audited sample of shelves | Within agreed tolerance for consecutive months |
| Coverage share and insufficient-data stores | Capture and quality logs | Trend per store and category |
| OSA and chronic OOS by store | Reported KPI | Against prior months, same rules |
| Monitoring pipeline uptime | Pipeline logs | Gaps disclosed in the report |
For proportions like the false-alarm rate, the NIST/SEMATECH e-Handbook gives the p-chart: centre line p, with control limits at p ± 3√(p(1−p)/n), where p is estimated from preliminary samples when it is not known. A month outside the limits triggers re-investigation before renewal discussions, and a single clean month is not evidence of durability. Breck et al. at Google frame production ML tests as assertions to check as often as possible and to fix the system when one fails, which is the right posture for these monthly checks.
The reason to keep reporting is behavioural as much as statistical. Gruen and Corsten observe that when measurement stops, people return to their old way of operating and out-of-stocks return to previous levels. Proving that a shelf-execution system raised availability at all is a different design problem, covered in our piece on measuring on-shelf availability lift from shelf-execution AI.
Who can build an OSA pipeline that keeps detection failures out of the KPI?
TechnoLynx builds the retail AI engineering behind a defensible OSA number: detection with validated confidence scoring, coverage-aware KPI logic, the per-image audit log and, through Production AI Reliability, the monthly evidence that it is holding. On build versus buy, an in-house team is the right owner of the KPI definitions, crosswalk and thresholds, since those are business rules; specialist help pays where the detector, the validation against audits and the drift monitoring are the weak link. When choosing a partner, ask to see how they validate detection against manual audits and how a reported figure is reconstructed from logged evidence.
This work is engineering, not regulatory sign-off. Teams that only need a dashboard over a vendor’s existing OSA feed are better served by that vendor’s reporting, and teams whose detection is already trustworthy may need only their own data team to implement the crosswalk and chronic scoring.
FAQ
What does OSA stand for in sales?
OSA stands for on-shelf availability. ECR Community defines it as the availability of product for sale to a shopper, in the place they expect it and at the time they want to purchase it.
What happens when a product is out of stock?
Shoppers buy elsewhere or skip the purchase. The 2002 GMA study found that, depending on category, 21 to 43 percent of consumers buy the item at another store and 7 to 25 percent do not buy it at all.
