How does AI camera analytics work? Computer vision in grocery stores and its limits
Who it is forGrocery chain operations and loss prevention teams, IT and data owners, data protection officers, managers deciding on a camera analytics purchase
AI camera analytics is often described at one of two extremes: an eye that sees everything, or a toy that does not work. The truth lies in between. The system finds the person in the image, follows them from frame to frame and produces events according to the lines and zones you draw; in doing so it makes mistakes, and the rate of those mistakes can be measured. This guide explains the basic steps of computer vision without drowning in jargon, shows how video becomes an event record and how accuracy is measured with precision and recall in a worked example, discusses how anomaly alerts and till matching should be set up, privacy by design under Turkish data protection law and where footage should be processed, and lists the questions to ask before buying. The sections touching on data protection law are general information, not legal advice.
How does AI turn camera footage into events?
In camera analytics, the job of AI is to turn footage into events that a person has described. Five basic steps are used. Detection marks with a box where an object such as a person is in each frame; object detection is regarded as one of the most fundamental and challenging problems in computer vision. Tracking links boxes in consecutive frames to the same person and produces a track; whose track it is remains unknown, only that the same track continues.
Line crossing looks at which direction a track crosses a virtual line drawn on the image; that is entry and exit counting. Zone dwell measures how long a track stays inside a defined area; waiting time in front of the till and zone density come from here. Event classification decides whether a given moment fits a defined event type, such as movement in the till area or a movement pattern outside the usual.
None of these steps requires knowing who the person is. For counting and queues it is enough to know where a box goes from frame to frame. Recognising a person, that is turning a face or body into a template and matching it with another image, is a separate and much heavier operation; the data protection section explains why it is avoided.
The known difficulties of computer vision come out of these steps too. The tracking literature lists objects occluding each other and abrupt changes in appearance among the main difficulties. In a grocery store the equivalents are plain: two customers standing side by side at the till, someone coming through the door with a trolley, evening reflections from the shop window. That is why the same software can work well in one store and badly in another; accuracy is measured for each camera separately.
- A frame is takenImage frames are taken from the camera recorder or directly from the camera. How often frames are examined determines accuracy for fast events such as line crossing.
- People and objects are detectedIn each frame people are marked with a box; every box has a confidence score.
- A track is builtBoxes are linked from frame to frame; the track carries only a sequence number, without knowing whom it belongs to.
- A rule is appliedDid the track cross the line, did it stay in the zone longer than the threshold, does the moment fit a defined event type; rules and thresholds come in here.
- An event record is writtenThe event is recorded with store, area, event type and time. What goes to reports and alerts is this record, not the footage itself.
| Step | What it does | Grocery example | Typical error |
|---|---|---|---|
| Detection | Marks a person or object with a box in each frame | People in front of the till, a person at the entrance | Missing an occluded person, taking a life-size cardboard display for a person |
| Tracking | Links boxes in consecutive frames to the same track | A track from the entrance to the till | Mixing up two people's tracks, breaking a track and starting a new one |
| Line crossing | Counts which direction a track crosses a virtual line | Entry and exit counting | Counting someone who pauses on the line twice |
| Zone dwell | Measures how long a track stays in an area | Till waiting time, aisle density | Counting staff waiting at the zone boundary as customers |
| Event classification | Decides whether a moment fits a defined event type | Movement in the till area, movement outside the usual pattern | Treating ordinary movement as an event, or missing a real one |
How accurate is AI: precision, recall and the threshold
Every event system makes two kinds of error. Raising an alert for an event that did not happen is a false alarm; missing an event that did happen is a missed event. Two numbers measure them. Precision tells you what share of the alerts produced are real, and shows how much of the review team's time is wasted. Recall tells you what share of the events that happened were caught, and shows what the system misses.
Precision is easy to measure: alerts are reviewed and the correct ones counted. Measuring recall needs the missed events too, and they are not on the alert list. So recall is measured with a validation sample: particular hours of particular cameras are reviewed end to end by people, every event that happened is marked, and you look at how many of them the system caught. Reviewing recordings for validation is also processing of personal data; it is limited to the purpose and given to an authorised person.
The system gives each event a confidence score, and an event whose score is above the threshold becomes an alert. As the threshold rises, only events the system is sure of become alerts: false alarms fall and missed events rise. Lowering the threshold does the opposite. The right threshold is chosen by comparing the cost of reviewing an alert with the cost of missing an event; a single accuracy percentage quoted by a vendor is not enough to make that decision.
- Precision
True alerts ÷ (True alerts + False alarms) × 100- Recall
True alerts ÷ (True alerts + Missed events) × 100Missed events are known only in a validation sample reviewed end to end.- Review workload
Number of alerts × Review time per alert
| Threshold | Alerts | True alerts | False alarms | Missed events | Precision | Recall | Review workload |
|---|---|---|---|---|---|---|---|
| Low | 320 | 165 | 155 | 15 | 51.6% | 91.7% | 1,280 min |
| Medium | 200 | 150 | 50 | 30 | 75.0% | 83.3% | 800 min |
| High | 120 | 108 | 12 | 72 | 90.0% | 60.0% | 480 min |
As the threshold moves from low to high, precision rises from 51.6 to 90 per cent and recall falls from 91.7 to 60 per cent. Because the two curves move in opposite directions, every setting that reduces false alarms increases missed events.
A vendor's accuracy figure may have been measured in a different store, at a different camera angle and at a different threshold. The question to ask is not for a single percentage but for precision and recall measured on your own cameras, and the threshold at which they were measured.
Why must an anomaly alert carry store, area, time and transaction?
An anomaly alert flags a moment that departs from a store's own usual pattern: movement at the till with no POS record at the same time, movement in an area after closing, density in an area above the usual. The usual pattern comes from the history of that store, that area and that hour; the same movement can be ordinary at morning opening and unusual after closing.
An alert is worth as much as the speed with which the person opening it can decide. An alert that says "something happened" does not reduce the workload; it still sends someone to scroll through hours of footage. A good alert carries at least five things: which store, which area, which time window, which event type and, where there is one, the transaction record at the same moment. For a till event that transaction is the POS line; seeing the event and the receipt side by side when the alert opens shortens the review.
An alert is not a decision but the start of a review. Article 11 of Law No. 6698 gives the data subject the right to object to a result against them arising from the analysis of processed data exclusively by automated systems. The KVKK recommendations on AI likewise ask that the role of human intervention in decision-making be established and that people not be subjected to a decision affecting them that rests solely on automated processing. A person reviews the alert and a person records the finding; an alert alone produces no outcome for an employee or a customer.
- Set the priorityTill and cash-related events are reviewed first, informational density alerts later.
- Rule out innocent causesClock offset, a till running in training mode, a mid-shift cash drop, maintenance or refurbishment; a large share of alerts close at this check.
- Look at the moment of the eventOnly the clip within the alert's time window is reviewed; the whole shift is not scanned.
- Record the outcomeTrue alert or false alarm, and for what reason; this record is the input for measuring precision and tuning the threshold.
| Field | Example | What happens if it is missing |
|---|---|---|
| Store | Store code and name | The alert goes to the wrong team |
| Area | Till 3, entrance, stockroom door | The review starts by scanning every camera |
| Time window | 17:52:10–17:52:40 | The event cannot be located in the recording |
| Event type and confidence score | Unmatched till event, score 0.82 | Prioritisation is impossible |
| Linked transaction | The POS line in the same window, or the absence of one | The event is matched with sales data by hand all over again |
| Closure | Reviewer, outcome, date | The same alert reopens and no data builds up for tuning the threshold |
This section is general information, not legal advice. An employment decision based on an alert depends on the circumstances of the case; the investigation sequence and hearing the employee's explanation are covered in the cashier voids guide.
How are till events and camera events matched?
Till matching places two records side by side on the same time axis: on the till side, a POS movement, a void, a refund or an end-of-day till variance; on the camera side, a time-stamped event in the till area. The rule is simple: if the difference between the two records' timestamps is within a defined window, they match. If there is an event in the till area and no POS record in the same window, an unmatched till event alert is raised.
The most common reason matching breaks is not AI but the clock. The camera recorder's clock and the POS clock drift separately; when the offset exceeds the window, real matches are lost and the system raises alerts for problems that do not exist. That is why both systems are connected to the same time source and the offset is checked regularly.
Matching also speeds up the review of transactions that stand out in the exception report, such as voids and refunds: you go straight to the camera event at the moment of the specific transaction that fits the pattern. How the exception report is built and the order in which an investigation proceeds are covered in the guide to cashier voids and internal theft; till variance itself is covered in the till variance and POS reconciliation guide. A sale that is voided with the cash kept, or a product passed through without being scanned, creates no till variance; that is why camera events and the exception report are read together.
- Clock offset
Camera event timestamp − POS record timestamp- Match condition
|Clock offset| ≤ Matching window- Unmatched till event rate
Till events with no matching POS record ÷ All till events × 100
| Till side | Camera side | Outcome | First thing to check |
|---|---|---|---|
| POS record present | Till event in the same window | Matched; no alert | — |
| No POS record in the same window | Event in the till area | Unmatched till event alert | Clock offset, cash drop, maintenance; then the moment of the event |
| End-of-day till variance | Unmatched events in the same shift | The review starts from these events | Till count record and POS reconciliation |
| Void or refund flagged in the exception report | Camera event at the moment of the transaction | Event-level evidence | Innocent causes and supervisor approval |
AI camera analytics under Turkish data protection law: biometric data and privacy by design
Camera footage is personal data, and the analysis stage is processing of personal data even if the output is only a number. Retention periods, signs, privacy notices and access rights are covered in detail in the store camera recording and data protection guide; this section focuses on three AI-specific issues: recognition, data minimisation and automated decisions.
Recognition is the heaviest. Article 6 of Law No. 6698 classes biometric data as a special category of personal data and prohibits its processing. Processing is possible only in the limited cases listed in the article, for example the data subject's explicit consent, express provision in law, or necessity for the establishment, exercise or protection of a right, and the adequate measures determined by the Personal Data Protection Board must also be taken. Legitimate interest, which is among the general processing conditions, is not on the Article 6 list.
The KVKK guide on biometric data sets two conditions for data to count as biometric: processing must reveal a person's distinguishing physical, physiological or behavioural characteristics, and those characteristics must serve to identify the person or verify their identity. The guide also states the principle of necessity explicitly: if the same purpose can be achieved with a less intrusive means, processing biometric data is not necessary. It sets a further limit for employees: where refusing consent could have negative consequences for the worker, consent cannot be regarded as freely given.
Counting, queues and density are therefore built without recognising people. A design that does not know who a person is, keeps a track only within that camera's field of view and for that one pass, and stores the output as numbers at store, area and hour level sits on the much lower-risk side, because it produces no template that identifies a person. The KVKK recommendations on AI point the same way: systems should be developed under the principle of data protection by design, anonymisation methods should be preferred where the same result can be achieved without processing personal data, and a privacy impact assessment should be carried out where high risk is foreseen.
The Law defines anonymisation as rendering personal data impossible, in any way, to link to an identified or identifiable natural person, even when matched with other data. An hourly entry count can be designed to fit this definition; once an identity that follows a person across days or stores is kept, there is personal data again. The automated-decision side was covered in the third section: an alert starts a human review and does not replace the decision.
| Choice | Lower risk | Higher risk |
|---|---|---|
| Distinguishing people | A person is counted as a box; who they are is not derived | A face or body template is extracted and matched with other images (biometric data) |
| Track lifetime | The track is kept only for that pass and that camera | The same person is followed across days and stores |
| Stored output | Numbers and event records at store, area and hour level | Per-person tracks and a separate footage archive for analysis |
| Inference | Queue, density, entry count | Estimating personal characteristics such as age, gender or emotion |
| Decision | An alert starts a human review | An alert alone produces an outcome for a person |
| Use | Capacity and loss at area and hour level | Monitoring an individual employee's speed or attendance |
This section is general information, not legal advice. Which processing counts as biometric data and which legal basis it rests on depend on the specific installation and are assessed with a lawyer who works in data protection law. The left-hand column of the table reduces risk; on its own it does not make processing lawful.
Should footage be processed in the store or centrally?
Footage is processed in one of three places. With in-store processing, the analysis runs on the camera itself or on a device in the store, and what leaves the store is only event records and numbers, not footage. With central processing, footage or frames taken at intervals are sent to the company's own server. With processing on a service provider's server, the frames go to the service provider; if the server is abroad, that raises a separate transfer question.
The choice is as much legal as technical. In-store processing reduces the personal data crossing the network but needs as many devices to maintain and update as there are stores. Central or service-provider processing updates the model in one place and measures accuracy in one place, but footage crosses the network and the analysis depends on the store's connection.
On the legal side three provisions are directly relevant. Article 12 of Law No. 6698 requires the data controller to take the technical and administrative measures needed to ensure an appropriate level of security to prevent unlawful processing of, and unlawful access to, personal data; where data is processed by someone else on the controller's behalf, the controller is jointly responsible with that person for those measures. The KVKK recommendations on AI ask that the parties' status as data controller or data processor be settled at the start of the project. If footage is to be processed abroad, Article 9 of the Law applies: alongside one of the conditions in Articles 5 and 6, an adequacy decision or one of the appropriate safeguards listed in the article is needed, for example the standard contract announced by the Board; a standard contract is notified to the Authority within five working days of signature.
| In store | Central (company server) | On a service provider's server | |
|---|---|---|---|
| Data crossing the network | Event records and numbers | Footage or frames | Footage or frames |
| Updates and maintenance | A separate device in every store | In one place | At the service provider |
| When the connection drops | Analysis can continue; records are sent later | Analysis stops or is delayed | Analysis stops or is delayed |
| Measuring accuracy | Checked separately on each device | In one place centrally | Depends on the service provider's reporting |
| Legal question | Device access and security (Art. 12) | Server security and access rights (Art. 12) | Data processor relationship and joint responsibility (Art. 12(2)); if abroad, transfer conditions (Art. 9) |
This section is general information, not legal advice. The conditions and procedure for transfers abroad are set by Article 9 and the related regulation; the specific installation is assessed with a lawyer.
What should you ask before buying AI camera analytics?
A demo screen always looks good: a well-lit store, a well-angled camera, a hand-picked hour. A purchase decision, though, is tested on the worst camera in your store at its busiest hour. The questions below are there to close that gap.
Most of the questions are about operation rather than technology: who receives the alert, who closes it, who changes the threshold, and what happens when a camera changes. If the answers to these questions are not written down, the system works in the first months, then alerts pile up and nobody looks at them.
| Question | Why it matters | What a good answer looks like |
|---|---|---|
| Which event types does it produce, and which fields does each event carry? | If the event type is undefined, the alert cannot be interpreted | A list of event types; every record carries store, area, event type and time |
| Where and how was accuracy measured? | A percentage measured in another store says nothing about your camera | A validation sample on your own cameras; precision and recall separately, with the threshold |
| Who controls the threshold? | The threshold is the choice between false alarms and missed events | The threshold is set per event type and changes are logged |
| Does it recognise people? | Recognition means processing biometric data | No face template; a track lasts only for the pass, no identity following a person across days |
| Where is footage processed, and what is stored? | The data crossing the network and being stored determines the risk | Processing location in writing; what is stored is event records and numbers; footage follows the security recording's retention |
| Does data leave the country? | If it does, the Article 9 conditions are needed | It does not, or written safeguards and notification are in place |
| Who receives the alert, and how is it closed? | An alert that never closes builds up no data for tuning the threshold | Owner, deadline, outcome and closure record |
| How does it match with till and POS data? | The value of an unmatched-event alert comes from the linked transaction | Clock synchronisation method and matching window in writing |
| What happens when a camera changes? | When angle and light change, accuracy changes | Lines and zones are redefined and accuracy is measured again |
| Who does the installation? | Setting up lines, zones and thresholds determines the result | Installation and validation are part of the service |
What does AI camera analytics do in Mindpera, and what does it not do?
Mind Cam processes footage from cameras in grocery stores with computer vision and produces event and visitor count data. Every event is recorded with store, area, event type and time. Visitors are counted by store and by hour, the density map shows area use, and an alert is raised when queue time or density exceeds its threshold. The till variance record is placed next to the camera event at the same moment; a till event with no POS record at the same time, and movement outside the usual pattern, raise an alert, and the investigation starts from the matched event rather than from hours of scrolling through footage.
The role of AI in Mindpera is limited, and that is a deliberate choice. On the camera side it extracts the event from the footage and matches it with the sales record; sales, conversion, basket size and reconciliation differences are calculated in Mind Ops in the SQL layer with defined formulas, and running the report twice for the same day gives the same number. A camera anomaly alert goes to its owner together with its record.
Mind Cam's defined functions are event records, visitor counting, density, queue time, anomaly alerts and till-event matching; facial recognition, estimating age, gender or emotion, detecting shelf gaps and automatic sanctions against a person are not among them. The purpose of the cameras, the privacy notice, the retention period and access to recordings are the business's decisions as data controller. If camera, till and sales data sit in different systems, our team handles the installation and brings the sources into a single data model.
- Computer vision: camera footage is turned into event and count data
- Event record: store, area, event type and timestamp
- Till matching and anomaly alert: unmatched till events and movement outside the usual pattern
- Mind Ops: metrics come from defined formulas; AI does not produce or change numbers
Frequently asked questions
- Does AI camera analytics require facial recognition?
- No. Counting visitors, queues and density does not require knowing who a person is; detecting the person as a box and following it from frame to frame is enough. Facial recognition means processing biometric data, and under Article 6 of Law No. 6698 biometric data is a special category of personal data. According to the KVKK guide on biometric data, if the same purpose can be achieved by a less intrusive means, processing biometric data is not necessary.
- What do precision and recall mean in camera analytics?
- Precision shows what share of the alerts produced are real events: if 150 of 200 alerts are correct, precision is 75 per cent. Recall shows what share of the events that happened were caught: if 150 of 180 real events were caught, recall is 83.3 per cent. Precision is measured by reviewing alerts; recall is measured with a validation sample in which recordings are reviewed end to end.
- What changes if the camera alert threshold is raised?
- Only events with a high confidence score become alerts; false alarms and review workload fall, but missed events rise. In the guide's example, raising the threshold lifts precision from 75 to 90 per cent and lowers recall from 83.3 to 60 per cent. The threshold is chosen separately for each event type: for till events involving cash, where a missed event is costly, it can be kept lower.
- Can store camera footage be processed on a server abroad under Turkish law?
- Under Article 9 of Law No. 6698, personal data may be transferred abroad when, alongside one of the conditions in Articles 5 or 6, there is an adequacy decision or one of the appropriate safeguards listed in the article, for example the standard contract announced by the Board; a standard contract is notified to the Authority within five working days. Where footage is processed is asked in writing before buying. This is general information, not legal advice.
- Is an AI-generated alert enough on its own for a decision about an employee?
- No. Article 11 of Law No. 6698 gives the right to object to a result against a person arising from the analysis of processed data exclusively by automated systems; the KVKK recommendations on AI also ask that the role of human intervention in decision-making be established. An alert starts a review: innocent causes are ruled out, the moment of the event is looked at and the employee's explanation is heard. This is general information, not legal advice.
- Why do till events and camera events fail to match?
- The most common reason is the clock: the camera recorder's clock and the POS clock drift separately, and once the offset exceeds the matching window, real matches are lost. With a 30-second window and a 75-second offset, no event matches and every event becomes an alert. Other causes are a till running in training mode, cash drops and maintenance. When the number of alerts suddenly jumps, the first check is the clock offset.
Sources
- Law No. 6698 on the Protection of Personal Data (consolidated text, Turkish), Arts. 3, 6, 9, 11, 12 — 2016-04-07
- KVKK, Guide on matters to consider when processing biometric data (Publication No. 55, Turkish) — 2025-03
- KVKK, Recommendations on the protection of personal data in the field of artificial intelligence (first published September 2021; Publication No. 76, April 2025 edition, Turkish) — 2025-04
- KVKK, public announcement on matters to consider when using security cameras in workplaces (Turkish) — 2026-06-08
- Object Detection in 20 Years: A Survey (published in Proceedings of the IEEE; arXiv 1905.05055, version 3) — 2023-01-18
- Artificial Intelligence (journal): Multiple Object Tracking: A Literature Review (arXiv 1409.7618, version 5) — 2022-02-11
- scikit-learn 1.9.1 documentation, Metrics and scoring: Precision, recall and F-measures (date accessed) — 2026-10-15