The camera pointed at an aisle can, in principle, answer two very different questions: is the shelf right, and what are the people in front of it doing. Those two questions look adjacent. They are not the same project, and the most common way a retail computer-vision programme dies is by being scoped as though they were.
A shelf-execution pipeline answers fixture questions — planogram compliance, on-shelf availability, price-tag accuracy, promotional placement. Footfall counting, dwell-time heatmaps and shopper-behaviour analytics answer people questions. The frames may overlap. The approvals, the retention rules, the stakeholder set and the success metric do not.
What the carveout means in practice
The divergence point is not model architecture. Both workloads can run on the same detector family, the same CUDA runtime, the same ONNX-exported weights on the same edge box. The divergence is what the pipeline is permitted to retain, and who has to sign that off.
A shelf-scoped pipeline can be built to look at fixtures, discard or never process people-containing regions, and ship inside an operations sign-off. Add shopper profiling and the same pipeline acquires a privacy review, a data-protection impact assessment, and a stakeholder set — legal, works council in some jurisdictions, group privacy — that has no reason to prioritise the shelf work it has been bolted onto. In our experience the technical build is rarely what slips; the approval chain is.
| Question | Shelf-execution pipeline | Footfall / dwell-time programme |
|---|---|---|
| Is this SKU facing the customer? | In scope | Out of scope |
| Does the fixture match the planogram? | In scope | Out of scope |
| Is the price tag and promo material correct? | In scope | Out of scope |
| How many people entered the store? | Out of scope | In scope |
| How long did shoppers linger at the endcap? | Out of scope | In scope |
| Which shoppers looked at what? | Out of scope | In scope, with a legal basis |
| Primary approver | Retail operations | Privacy / legal, then operations |
| Accountable metric | On-shelf availability rate, planogram compliance rate, time-to-restock | Traffic and engagement metrics |
Read the table as a scoping document, not a capability list. The rows in the right-hand column are legitimate retail questions. They are simply a different commission.
Why not just use the same feed?
Because “the same feed could support it” is a statement about pixels, not about governance. Two consequences follow from ignoring that.
The first is schedule. Scope kept to shelf execution is signed off by retail operations; adding people analytics pulls in privacy and legal review cycles measured in months, not weeks. That is the honest trade: a narrower programme delivered on time beats a broader one that never clears approval. We have watched otherwise healthy planogram-compliance pilots sit idle for a quarter because a dwell-time slide was added to the business case by someone who thought it strengthened the pitch.
The second is measurement corruption. Footfall dashboards do not tell you whether availability improved. Once both live in one programme, the reporting drifts toward the metric that moves most visibly — traffic and dwell curves — and the metric the programme is actually accountable for, on-shelf availability rate, gets reported as a secondary chart. The shelf work then gets judged against numbers it does not control. The same discipline applies to interpreting the model’s own output; we discuss the quieter version of that failure in where shelf-execution AI still degrades in production.
How you keep people out of a shelf pipeline
The boundary has to be engineered, not asserted in a slide. Four levers do most of the work:
- Framing. Point the capture at the fixture face. Shelf-edge and rail-mounted positions with a tight field of view see facings, not aisles of shoppers, because the geometry does the exclusion before any software runs.
- Region masking. Where wider coverage is unavoidable, apply a fixed shelf-region mask at ingest so anything outside the fixture polygon is never handed to the detector. Masking at ingest, not after inference, is the part auditors care about.
- Retention rules. Persist derived facts — SKU present/absent, compliance state, timestamp, fixture ID — rather than frames. If frames must be retained for model error review, retain the masked crop only, with a stated retention window.
- No identity or tracking features. No re-identification embeddings, no cross-camera person tracking, no demographic inference. Their absence is a design constraint written into the scope, not an option deferred to later.
Written down, these become the artefact that unblocks the conversation. When a scoping exercise runs — the same step where capture spec and detection classes get pinned down, as covered in our retail computer-vision practice — the shelf-only boundary is recorded explicitly: which frame regions the pipeline is permitted to process, and what it keeps. Operations can approve that. So can legal, quickly, because there is nothing in it for them to litigate.
If the business genuinely wants footfall analytics
Sometimes it does, and that is fine. Commission it alongside, not inside. That means a separate scope document, its own legal basis and DPIA, its own success criteria, and — critically — its own timeline that is not a dependency of the shelf programme. Shared infrastructure is acceptable; shared scope is not. The two can run on the same edge hardware and the same orchestration layer while remaining separate programmes with separate approvals.
The structural causes of why shelf execution needs this kind of narrow, defensible framing in the first place are developed in our retail AI practice, where on-shelf availability is treated as an execution problem rather than a general analytics one. The same discipline shows up in industrial settings: a production vision line scoped to one inspection class holds up, and a general-purpose factory vision platform rarely does.
The failure mode, stated plainly
A retail CV programme that describes itself as a store analytics platform has no owner for its numbers. Operations does not recognise the metric, privacy has not cleared the retention, and finance is looking at a dwell-time chart while the stock-out rate is unchanged. The recoverable version of this is caught at scoping. The unrecoverable version is caught six months in, when the pilot is quietly not renewed.
So the useful question to put to a sponsor is not “could the cameras also do footfall?” — they probably could. It is: which single metric is this programme accountable for at the next review, and who signs off on what the pipeline is allowed to keep?
Frequently Asked Questions
What does the shelf-execution vs footfall / dwell-time / behaviour-analytics carveout mean in practice?
Retailers often confuse perfect shelf execution with high footfall, yet stores with immaculate displays routinely underperform locations where customers simply spend more time browsing. It means the pipeline is scoped to fixtures — planogram compliance, on-shelf availability, price-tag and promotional checks — and is not built to observe people. In practice the carveout is enforced through camera framing, ingest-time region masking, and retention of derived shelf facts rather than frames. It is written into the scope document, not left as an intention.
Which questions does a shelf-execution pipeline answer, and which is it deliberately not built to answer?
It answers whether a SKU is present and correctly faced, whether the fixture matches the planogram, and whether pricing and promotional material are right. It is deliberately not built to answer how many people entered, how long they lingered, or what they looked at. Those are legitimate questions belonging to a separate programme.
If the same aisle camera feed could support people-counting, why keep the programmes separate?
Because the constraint is governance, not pixels. A shelf-scoped pipeline ships inside a retail-operations sign-off; adding people analytics pulls in privacy review and a data-protection impact assessment with cycle times measured in months. Keeping them separate protects the shelf programme’s schedule and its metric.
How does scope creep into behaviour analytics distort the on-shelf-availability metrics the programme is measured on?
Reporting drifts toward whichever numbers move most visibly, and traffic and dwell curves move more visibly than availability rates. The shelf programme then gets judged against metrics it does not control, while on-shelf availability rate, planogram compliance rate and time-to-restock demote to secondary charts.
If the business genuinely wants footfall analytics, how should that be commissioned?
As its own programme: separate scope, its own legal basis and DPIA, its own success criteria, and a timeline that is not a dependency of the shelf work. Shared edge hardware and orchestration are fine; shared scope and shared approval gates are not.
Compliance gaps versus shopper intent: separate the signals
Footfall heatmaps answer merchandising questions; shelf compliance catches operational failure—conflating them guarantees the wrong dashboard. The teams that do tend to ship the boring, correct version first.
