A basket analysis dashboard reports that shampoo and conditioner co-occur in 38% of transactions. It looks authoritative. What it does not show is the private-label bottle the recognition model never learned, silently dropped from every basket it appeared in — so the real co-occurrence, and the attach-rate figure a merchandiser is about to plan around, is quietly wrong. That gap is the whole story of shopping basket analysis with computer vision. The technique is usually pitched as a self-contained analytics feature: point a camera at the cart or checkout, count what goes in, report on associations. But basket analysis is not a measurement — it is a downstream consumer of a recognition pipeline, and its numbers inherit every strength and every blind spot of the layer beneath them. Basket insights are only as trustworthy as the recognition it sits on top of, which is why what happens to an unrecognized item determines whether basket analysis stays accurate as the assortment changes. How does shopping basket analysis actually work? At its core, basket analysis answers a merchandising question: which products travel together, and how often? The classic form is association-rule mining — support, confidence, lift over sets of items — but the modern retail version replaces the receipt as its data source with a computer vision pipeline that observes what physically enters a cart, a checkout lane, or a self-scan station. Mechanically, the CV side is a chain. A detector (a YOLO-family model or an RT-DETR variant) proposes bounding boxes for items in frame. A classifier or an embedding lookup assigns each box to a SKU. A tracker links detections across frames so one bottle picked up, put down, and picked up again is not counted three times. Only after all of that does the analytics layer assemble a “basket” — the set of SKUs attributed to one transaction — and compute associations across thousands of them. The important thing to hold onto: the basket the analytics sees is not the basket the shopper filled. It is the basket the recognition pipeline reconstructed. Every step in that chain can add, drop, or mislabel an item, and the analytics layer has no independent way to know it happened. What signals does basket analysis capture, and where do they come from? The signals are more layered than “a list of products.” A well-instrumented CV pipeline emits, per item, at least four things worth naming: Identity — the SKU assigned by the classifier or the nearest-neighbour match against a product embedding index. Confidence — a calibrated score for how sure the model is about that identity. This is the single most under-used signal in most deployments. Spatial and temporal context — where in the frame, in what order, and how the item moved. This is what lets a tracker separate distinct items from re-observations of the same one. The unknown flag — whether the item was recognized at all, or fell below the threshold where the system is willing to name it. That last signal is the one naive deployments throw away. If you are unsure how a detector arrives at that number, our explainer on what a confidence score in computer vision means and how to use it is the right primer — because basket analysis lives or dies on how you treat low-confidence and no-confidence detections, not on the high-confidence ones everyone gets right. What happens to basket accuracy when the system meets an item it was never trained to recognize? This is the divergence point between a naive and an expert design, and it is worth being precise about. A retail assortment is not static. New SKUs launch, private-label lines swap in, seasonal packaging changes the look of a product the model already “knows,” and a supplier quietly redesigns a label. Every one of these produces an object the recognition model was not trained on. The model does not know that it does not know — it either forces the item into the closest class it has (a misclassification) or scores it below threshold (an unknown). The naive system treats every recognized item as ground truth and silently discards what it cannot classify. The consequence is not a visible error. It is a slow, invisible understatement: that private-label bottle never enters any basket, so its co-occurrences never appear, and the attach-rate for the category it belongs to reads lower than reality. The dashboard stays confident and green while the ground truth drifts away underneath it. The expert system does the opposite. It treats the unknown as the most valuable event in the pipeline, not the least. The item is not dropped — it is surfaced: routed to a review queue, flagged in the basket record as “present but unidentified,” and captured for labelling. The basket is marked as incomplete rather than reported as complete-but-wrong. This is the same discipline that anti-drift systems in other domains rely on; the unknown-pattern loop that prevents alert drift in anti-money-laundering systems is structurally the same idea applied to transaction monitoring rather than shelves. The distinction matters because a dropped item and a flagged item produce opposite trajectories. One degrades silently; the other creates the feedback that keeps the system honest. How does the unknown-object loop keep basket analysis accurate as SKUs and packaging change? The unknown-object loop is the mechanism that closes the gap. It has four moving parts, and each one is a design decision, not a default: Detect the unknown. Use calibrated confidence and, where possible, an out-of-distribution signal rather than a single hard threshold. An item can be detected as present (a clear bounding box) while being unidentified (no class clears threshold). Those two facts must be recorded separately. Surface it, don’t swallow it. Route unidentified items to a human review queue and mark the affected basket as incomplete. The analytics layer must be able to distinguish “empty basket” from “basket with an item we couldn’t name.” Label and fold back in. Reviewed unknowns become training examples. New SKUs and reworked packaging get added to the classifier or the embedding index. Building this reference set is real work — our note on what it takes to build an SKU dataset for retail product recognition covers why the intake side is harder than the model side. Track the recovery rate. Measure the share of formerly-unknown items that are correctly classified after retraining. This is your loop’s health metric. The measurable outcome of running this loop is the share of basket items correctly classified over time. A system with a working unknown-object loop holds or improves that rate as the assortment turns over. A system without one degrades toward exactly the manual reconciliation the CV was supposed to remove — someone comparing camera baskets against receipts to figure out what the cameras missed. This is an observed pattern across retail recognition deployments, not a benchmarked rate; the direction is reliable even where the specific numbers are site-specific. Basket-item classification health: a quick self-check Signal Healthy loop Silent drift Correctly-classified share of basket items Flat or rising quarter over quarter Declining, or not measured at all Unknown / low-confidence items Routed to review, counted, labelled Dropped from the basket record Basket completeness flag Distinguishes “empty” from “incomplete” Every basket reported as complete New-SKU time-to-recognition Days to weeks via the labelling loop Never — model degrades until manual retrain Reconciliation against POS Periodic audit, gap trending down Growing manual reconciliation to catch misses If you cannot fill in the left column for your own deployment, the basket metrics you are reporting are more optimistic than the ground truth. That is the failure class our A2 recognition-reliability assessment exists to catch — it checks specifically whether the pipeline feeding basket analysis has a designed unknown-object surfacing loop, so the metrics do not silently drift as the assortment changes. What merchandising decisions does trustworthy basket analysis actually support? The point of getting the recognition layer right is that the decisions downstream are consequential. Trustworthy basket analysis supports cross-sell and bundle design (which products to place or promote together), planogram and adjacency decisions (what to shelve near what), attach-rate targets for accessories and consumables, and promotion-effect measurement (did a discount actually pull the associated item into more baskets). It also feeds replenishment logic when combined with shelf data — the connection our piece on how automated replenishment works with retail CV develops in detail. Every one of those decisions consumes association and attach-rate figures. Every misclassified or dropped item is a distortion in exactly those figures. A merchandiser who moves shelf space based on a co-occurrence that is understated by 15% because a private-label line is invisible to the model is making a real decision on a corrupted signal — and will never see the corruption, because the dashboard has no way to show what it never recognized. How is CV-based basket analysis different from receipt or POS-based basket analysis? Traditional basket analysis reads the receipt or the POS transaction log. Every item has already been scanned, so identity is essentially given — the barcode is ground truth. CV-based basket analysis reconstructs the basket from observation instead, which buys you signals the receipt cannot provide but introduces a recognition problem the receipt never had. Dimension POS / receipt-based CV-based Item identity Barcode scan — near-perfect Model inference — subject to unknowns and misclassification Timing / sequence Scan order only Real pick-up order, dwell, put-backs Un-purchased items Invisible Observable (considered-but-abandoned) Self-scan / no-checkout N/A Native use case Failure mode Missed scan (rare) Silent drop of untrained SKUs (systematic without a loop) What keeps it accurate The scanner The unknown-object loop The comparison makes the dependency explicit. POS basket analysis is accurate because the barcode does the recognition for you. CV basket analysis has no barcode — the recognition is the model’s job, and the thing that keeps it accurate over time is the loop, not the model’s launch-day accuracy. A model that was 97% accurate the day it shipped is 97% accurate on the assortment it was trained on, which is not the assortment it will be looking at six months later. FAQ How should you think about shopping basket analysis in practice? It answers which products travel together and how often, using association metrics like support, confidence, and lift over many transactions. The CV version replaces the receipt as its data source: a detector, classifier, and tracker reconstruct the set of SKUs in each cart or checkout, and the analytics layer computes associations across those reconstructed baskets. In practice, the basket the analytics sees is the one the pipeline rebuilt — not necessarily the one the shopper filled. What signals does basket analysis capture from a retail CV pipeline, and where do they come from? Per item, a well-instrumented pipeline emits identity (the assigned SKU), confidence (how sure the model is), spatial and temporal context (position, order, and movement that let a tracker de-duplicate), and an unknown flag (whether the item was recognized at all). These come from the detector, classifier or embedding lookup, and tracker. The unknown flag is the signal naive deployments most often discard. What happens to basket accuracy when the system meets an item it was never trained to recognize? A naive system silently discards it — the item never enters any basket, so its co-occurrences vanish and attach-rates read lower than reality, with no visible error. An expert system surfaces it: the item is flagged as present-but-unidentified, the basket is marked incomplete, and the item is captured for labelling. The two approaches produce opposite trajectories — silent degradation versus a feedback loop that keeps the system honest. How does the unknown-object loop keep basket analysis accurate as SKUs and packaging change? The loop detects unknowns using calibrated confidence, surfaces them to review instead of dropping them, folds labelled examples back into the classifier or embedding index, and tracks the recovery rate. Its health metric is the share of basket items correctly classified over time. Running the loop holds or improves that share as the assortment turns over; skipping it lets the metric degrade toward the manual reconciliation the CV was meant to remove. What merchandising decisions does trustworthy basket analysis actually support? Cross-sell and bundle design, planogram and shelf-adjacency choices, accessory and consumable attach-rate targets, and promotion-effect measurement — plus replenishment logic when combined with shelf data. All of these consume association and attach-rate figures, so every dropped or misclassified item distorts exactly the numbers driving the decision. How is CV-based basket analysis different from receipt or POS-based basket analysis? POS/receipt analysis gets item identity for free — the barcode is ground truth — but sees only scan order and only purchased items. CV-based analysis reconstructs the basket from observation, which adds real pick-up sequence, dwell, put-backs, and considered-but-abandoned items, and works for self-scan and no-checkout formats. The trade-off is that recognition becomes the model’s job, and the unknown-object loop, not launch-day accuracy, is what keeps it correct over time. The honest question to ask of any CV basket-analysis deployment is not “how accurate is the model?” but “what happens to the item it cannot name?” If the answer is that the item disappears, the basket metrics are already drifting — you just cannot see it yet. That is the failure class the A2 recognition-reliability assessment is built to surface before it reaches a merchandising decision.
