If you run analytics across a retail estate, "Schrems II" has probably reached you as a compliance worry rather than a case name you have read. The worry is real and the mechanics are worth getting right, because the ruling changed how EU personal data can be moved to countries outside the EU, and a lot of retail analytics quietly does exactly that. Footfall data feels harmless until you trace where it goes: a camera counter's footage, a Wi-Fi tracker's device identifiers, a cloud dashboard hosted in another jurisdiction. Once personal data crosses a border, Schrems II is in the room.
This post covers the cross-border transfer angle specifically. It explains what the Court of Justice of the EU actually decided, why it lands on retail analytics vendors, how the transfer question differs from the residency question, and why a counting method that captures no personal data changes the calculation at the root. For where data is stored and hosted rather than where it is transferred, see data residency for retail analytics; this post owns the transfer side of that pair. This is general information, not legal advice.
What does Schrems II mean for retail analytics?
Schrems II is the 2020 ruling by the Court of Justice of the EU (Case C-311/18) that invalidated the EU-US Privacy Shield and tightened the conditions for transferring EU personal data to third countries. For retail analytics, it matters when a vendor moves personal data, such as camera footage or device identifiers, outside the EU, because each transfer then needs a valid legal mechanism and a case-by-case assessment. A footfall method that captures no personal data changes the picture at the root: if the data being handled is not personal data, the transfer restrictions that Schrems II reinforced do not attach to it in the same way. This is general information, not legal advice; confirm your specific transfers with your DPO or counsel.
What Schrems II actually did
The case is formally CJEU Case C-311/18, decided on 16 July 2020. It arose from a complaint about the transfer of EU personal data to the United States, and its practical effect was blunt: the Court struck down the EU-US Privacy Shield, the framework many organisations had relied on to move personal data across the Atlantic. Overnight, transfers that had been treated as covered lost the mechanism they were leaning on.
The ruling did more than remove one framework. It reinforced that when you rely on other transfer tools, such as Standard Contractual Clauses, you cannot treat them as a rubber stamp. The exporter has to look at the legal regime of the destination country and judge whether EU personal data will actually get protection there equivalent to what it gets in the EU. Where it will not, extra safeguards are needed, and if adequate protection cannot be reached, the transfer should not go ahead. In short, the ruling shifted the burden onto the party doing the transfer to assess and document that the data stays protected wherever it lands.
For a data protection team, the consequence is a case-by-case transfer assessment for personal data leaving the EU, rather than a blanket assumption that a signed clause settles the matter. That is the shape of the obligation Schrems II left behind, and it is the reason "where does our footfall data actually go" became a question retail teams started asking their analytics vendors.
Why it hits retail analytics vendors
Retail analytics is a transfer problem the moment the data involved is personal data and the processing crosses a border. Two common footfall methods put personal data in play. Camera-based counters record images of people, which are personal data whenever a person is identifiable in them. Wi-Fi and device-tracking counters collect MAC addresses or other device identifiers, which regulators have long treated as personal data because they can single out a device and, through it, a person.
Now add the cloud. If that camera footage or those device identifiers are processed or stored on infrastructure outside the EU, or by a vendor whose parent company is subject to another country's access laws, the data has been transferred to a third country in the sense Schrems II cares about. The retailer, as controller, is the one who has to be able to show that transfer is lawful: the right mechanism in place, the destination assessed, safeguards added where the assessment demands them. A vendor's reassuring "it's all in the cloud" is not an answer to that question. It is often the start of it.
This is why the transfer angle is distinct from the storage-location question. You can host data inside the EU and still have a transfer problem if a non-EU parent can be compelled to access it. And you can have a clean transfer posture on paper that collapses the moment someone actually reads the destination country's surveillance laws. The only way to shrink the problem reliably is to reduce the amount of personal data that exists to be transferred in the first place.
Data residency versus data transfer: two different questions
These two terms get used interchangeably, and conflating them causes real mistakes. Data residency is about where data physically lives: which country's data centres hold it at rest. Data transfer is about data moving from one jurisdiction to another, and crucially about who can reach it, not only where the disk sits.
You can satisfy residency and still fail on transfer. A dataset stored in Frankfurt is resident in the EU, but if the vendor operating it is subject to a foreign government's lawful-access powers, the potential for that data to be reached from outside the EU is a transfer-law concern regardless of the physical location. Schrems II is fundamentally a transfer ruling, not a residency ruling. It is about the protection personal data receives once it can be accessed under another country's regime, wherever the bytes happen to rest.
For the residency side of the pair, which covers where footfall data is hosted and stored, see data residency for retail analytics. Keeping the two questions separate is what lets a retail team give a straight answer to each instead of a muddled answer to both. For the parallel question in the United States, on how state privacy law treats retail analytics, see US privacy law and retail analytics.
How no-PII counting changes the transfer-risk calculation
Every safeguard discussed so far is a way of protecting personal data as it moves. There is a more fundamental move available: do not capture personal data in the first place. If the footfall measurement produces no personal data, the transfer restrictions that Schrems II reinforced do not attach to it in the same way, because those restrictions govern the transfer of personal data specifically.
Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode, and tracks that movement to about one-metre precision. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.
Read against the transfer question, that matters at the root rather than at the safeguard layer. The data being handled is a count, a dwell time, and a path shape, none of which identifies anyone. It is not that Ariadne moves personal data carefully across borders; it is that the count itself is not personal data, so the transfer-restriction question the retailer would otherwise have to work through does not arise for the count. This is not the same as capturing personal data and then treating it, and it is not a claim that Ariadne scrubs identity out afterward. No identity is captured to begin with, so there is nothing personal to protect on its way across a border.
There is one honest exception to keep separate. If a deployment turns on an optional identified feature, such as a guest Wi-Fi login a visitor chooses to complete, that feature does involve personal data and should be assessed on its own terms, including any transfer that touches it. The anonymous count and the opt-in feature are different data flows and should be treated as such. Why a device identifier is personal data in the first place, which is the crux of the whole transfer concern, is covered in why device identifiers are personal data, and the underlying sensing choice is a non-biometric one, explained in non-biometric counting.
A practical checklist for evaluating a vendor's transfer posture
When a retail team assesses an analytics vendor on Schrems II grounds, the useful questions are concrete. These are general due-diligence prompts, not a legal template; your DPO or counsel should shape the final assessment for your estate.
- Does the method capture personal data at all? If it captures no images, no device identifiers, and no biometric data, the transfer question shrinks dramatically before any mechanism is even discussed.
- Where is the data processed and stored, and by whom? Ask for the actual processing locations and sub-processors, not a marketing line about "the cloud."
- Can any entity outside the EU be compelled to access the data? A non-EU parent company or sub-processor can create a transfer concern even when the storage is inside the EU.
- What transfer mechanism is relied on where personal data does leave the EU, and has a destination assessment been done? A signed set of clauses is a starting point, not the finish.
- Are optional identified features (guest Wi-Fi, loyalty tie-ins) documented as separate data flows with their own transfer posture?
The first question is the one that changes the most. A vendor whose method produces no personal data hands you a far shorter assessment than one whose method depends on footage or device identifiers, because most of the transfer machinery only engages once personal data is present.
FAQ
What is Schrems II in simple terms?
Schrems II is a 2020 ruling by the Court of Justice of the EU (Case C-311/18) that invalidated the EU-US Privacy Shield and made organisations assess, case by case, whether EU personal data stays adequately protected when it is transferred to a country outside the EU. It shifted the burden of proof onto the party doing the transfer.
Does Schrems II apply to footfall and people-counting data?
It applies whenever that data is personal data and is transferred outside the EU. Camera footage and device identifiers are personal data, so moving them to non-EU infrastructure raises the transfer question. A counting method that captures no personal data does not put personal data into the transfer in the first place.
Is data residency the same as a data transfer restriction?
No. Residency is where data physically lives; transfer is about data moving to another jurisdiction and who can access it there. You can host data inside the EU and still face a transfer concern if a non-EU entity can be compelled to reach it. Schrems II is fundamentally a transfer ruling.
How does camera-free counting reduce Schrems II exposure?
It captures no personal data: no camera images, no MAC address by default, and no biometric data. Because the transfer restrictions Schrems II reinforced govern the transfer of personal data, and the count is not personal data, that specific question does not arise for the count itself. Optional opt-in features that do involve personal data should be assessed separately.
Do we still need our DPO to sign off?
Yes. This is general information, not legal advice. Your data protection officer or counsel should assess your specific transfers, mechanisms, and any opt-in features for your own deployment before you rely on any position described here.
---
