GDPR and WiFi Analytics: What Consent Is Required for Footfall Data in the EU

WiFi and Bluetooth Low Energy (BLE) footfall analytics measures how many people pass, enter, and linger in a physical space by listening for the radio signals their phones broadcast automatically, then converting those signals into counts, dwell times, and conversion rates. Picture two shopping centres opening on the same Saturday morning, one in Lyon and one in Rotterdam. Both have sensors bolted to the ceiling, both are counting phones, and both assume they're GDPR compliant because nobody asked anyone to sign anything.

Only one of them probably is. The difference comes down to what happens to a MAC address in the milliseconds after a sensor catches it, and which legal basis the operator actually documented before switching the system on. That sounds like a technicality. It's the entire case.

This piece lays out what GDPR requires for WiFi and BLE footfall tracking, where "anonymized" data stops being anonymous in the eyes of regulators, and how the answer shifts across France, Germany, Switzerland, Belgium, and the Netherlands. We'll also flag where the EU framing simply doesn't apply, because plenty of markets outside Europe play by very different rules.

How a phone becomes a data point

Every WiFi-enabled phone with its radio on sends out probe requests, little broadcast frames asking "is my favourite network nearby?" Each probe carries a MAC address, a unique identifier burned into the device's network hardware. Passive sensors in a store or mall ceiling pick these up without the phone ever connecting to anything. BLE beacons work the other way: the venue broadcasts, and apps or beacons on the receiving end log proximity and signal strength. Either method produces the same raw material — a device identifier, a timestamp, and a signal strength reading that approximates distance.

From that raw material, analytics platforms build the metrics retailers actually care about: footfall counts, dwell time, repeat-visit rate, and window conversion. If you want the deeper breakdown of what each of those numbers actually measures and where they get fuzzy, we've covered that separately in Dwell Time, Capture Rate, Conversion: What Each Retail Metric Really Counts. For this piece, the relevant fact is simpler: that MAC address, the moment it's captured, is the thing GDPR cares about.

Why a hashed MAC address is still personal data

This is where a lot of vendor marketing goes sideways. "We anonymize the data" usually means the system hashes the MAC address with SHA-256 or a similar algorithm, often combined with a rotating salt, before it touches a database. That's a real privacy improvement. It is not anonymization in the legal sense.

Pseudonymization refers to processing personal data so it can no longer be attributed to a specific person without additional information, while that additional information is kept separately and protected — which is precisely Article 4(5)'s definition, and precisely what hashing does. The hash is deterministic within its rotation window: the same phone produces the same hash until the salt changes, which means the hashed value can still single out one device moving through a space, even if nobody can immediately name the owner. Pseudonymized data remains inside GDPR's scope. A hashed MAC address can be stored and processed, but it would still be considered pseudonymous if it can uniquely single out a single device belonging to a natural person, and pseudonymising data does not move it out of scope of the GDPR as the data can still be linked back to a natural person, with the use of extra information .

The legal logic traces back further than WiFi tracking itself. In the 2016 Breyer judgment, the Court of Justice of the European Union concluded that dynamic IP addresses are to be seen as personal data, and following the same logic, MAC addresses of personal devices are therefore certainly to be seen as personal data . Add a timestamp and a location, and the case gets stronger, not weaker: a MAC address becomes personal data the moment it is combined with other data that can be traced back to a person, and that traceability is possible via the observed location data of the mobile phone . The Article 29 Working Party made the same point about geolocation and smart devices years before most retailers installed their first sensor (Privacy Company, 2018, citing WP29 Opinion 13/2011).

So when does WiFi footfall data actually leave GDPR's scope? Once data is truly anonymized — aggregated with a significant enough sample size, and it can no longer be related back to a single data subject — it falls out of scope of the GDPR and can be further used, though a valid legal basis is still required for the initial collection . That last clause matters: you need a lawful basis for the moment of capture, even if what you store afterward is a clean, aggregate count.

Picking a legal basis: consent or legitimate interest?

GDPR gives you six possible legal bases. For footfall tracking, four of them are non-starters immediately. Legal bases covering legal obligation, vital interest, and public interest certainly do not apply, as WiFi-tracking can not be seen as a legal obligation, in anyone's vital interest or in public interest in general . That leaves two real options: consent (Article 6(1)(a)) and legitimate interest (Article 6(1)(f)).

Most EU regulators accept legitimate interest for aggregate, non-marketing footfall counting, provided the controller runs and documents a balancing test. The EDPB's 2024 guidelines formalised what had previously been scattered national guidance into a three-step assessment covering the pursuit of a legitimate interest, the necessity of processing for that purpose, and a final weighing against the interests or fundamental freedoms of the data subjects, which must not override the controller's interest . Those guidelines were adopted in October 2024 and are now the reference point national DPAs cite when they evaluate a retailer's balancing test. Consent becomes mandatory the instant tracking stops being anonymous and aggregate and starts being personal and ongoing — a loyalty profile tied to a hashed ID, marketing messages triggered by store visits, or any dataset a retailer could use to recognise the same shopper across multiple trips. As one Dutch legal analysis puts it: if the responsible party wishes to rely on consent, the data subject must be able to give prior consent to the party that wants to track it using WiFi signals, and such consent is only valid if given freely and based on specific, unambiguous information .

A worked example: measuring window conversion without crossing the line

Consider a 500-store retail chain that wants to measure window conversion — how many passers-by actually walk in — using passive WiFi analytics, without building a consent flow for every pedestrian on the pavement. One documented approach: deploy sensors configured to capture probe requests, then run an edge-based hashing agent that applies a SHA-256 hash to the MAC address combined with a daily rotating salt, before forwarding only the hashed identifier and signal strength — never the raw address itself.

The salt rotation matters more than it sounds. Rotating the salt daily or weekly ensures a device cannot be tracked indefinitely, limiting the data's lifespan and adhering to the principle of data minimisation . But hashing alone isn't the finish line — hashing alone is not sufficient, and controllers must also employ temporal aggregation , bucketing individual pings into hourly counts so no single hashed ID survives as an addressable record past the reporting window. This is roughly the same architecture French and Dutch regulators were describing back in 2018, just with better crypto underneath it.

This is also where field-level WiFi scanning work tends to diverge sharply from what a slide deck promises. Teampl has run WiFi signal-scanning field operations across Germany, France, and the Benelux region, collecting thousands of scans a day — and the practical lesson from that kind of volume is that the privacy architecture has to be built into the collection pipeline from the start, not patched on afterward once a regulator asks questions.

France, Germany, Switzerland, Belgium, the Netherlands: where the lines actually sit

GDPR is a regulation, which in theory means uniform rules across the EU. In practice, national data protection authorities interpret the balancing test differently, and Switzerland isn't in the EU at all. Here's how the major markets for mall and retail analytics compare.

Jurisdiction	Governing framework	Position on legitimate interest	Distinctive requirement
France	GDPR + CNIL guidance	Accepted for aggregate counting with layered notice	Reliable pseudonymization of MAC addresses with deletion of raw data, and anonymization or deletion of pseudonymized data by end of day
Netherlands	GDPR + Dutch DPA opinions	Accepted in private commercial space, contested for passers-by	Strong opinions from the Dutch DPA hold that WiFi tracking in semi-public spaces is harder to justify the moment personal data of people outside the premises — passers-by — is swept in
Belgium	GDPR + Belgian DPA recommendations	Accepted subject to a documented three-step test	The DPA frames legitimate interest as a three-step process: identify the controller's legitimate interest, evaluate the interests of data subjects, then balance the two
Germany	GDPR, enforced by state-level DPAs	Accepted but assessed case-by-case, no single national WiFi-tracking opinion	Balancing test applied under the general EDPB framework rather than retail-specific guidance
Switzerland	Revised Federal Act on Data Protection (nFADP), in force since September 2023	Broad justification grounds, conceptually close to legitimate interest	GDPR doesn't apply directly to Switzerland-only processing; enforcement mechanics and penalty structure differ from the EU model

Outside Europe, the calculus shifts again. US retailers operate under a patchwork of state laws rather than one federal standard, and the pressure to anonymize comes more from reputational risk than a single regulator. As one industry analysis of US retail WiFi tracking noted, anonymization of MAC address information may help protect retailers against future decisions of regulators in the US and EU, even though it can inhibit measurement of repeat customers . The EU starts from the opposite default: personal data until proven otherwise.

Consent, legitimate interest, or contract: which basis actually fits your deployment?

Retailers and mall operators tend to default to whichever basis the vendor's privacy policy already assumes. That's backwards. The right basis depends on what you're actually doing with the data once it's captured.

Legal basis	Fits this use case	What it requires	Where it breaks down
Legitimate interest (Art. 6(1)(f))	Aggregate footfall counts, dwell time benchmarking, anonymous heatmaps	Documented balancing test, signage, same-day deletion or irreversible anonymization	Fails the moment data is used to track or profile an identifiable individual across visits
Explicit consent (Art. 6(1)(a))	Loyalty apps, captive-portal login, marketing retargeting tied to visits	A connection path that doesn't require opting in, and no pre-ticked consent boxes	Low opt-in rates if the ask is clumsy; doesn't cover passers-by who never touch the portal
Contract (Art. 6(1)(b))	Mall-wide WiFi service where connectivity itself is the product	Terms genuinely necessary to deliver the connectivity, not a backdoor for marketing data	Rarely survives scrutiny if the "contract" is really consent in disguise

Notice the pattern: whichever basis you pick, transparency isn't optional. Even under legitimate interest, venues should display signage informing visitors that WiFi analytics are in operation, even for purely aggregate analytics .

When you need a DPIA — and when signage genuinely isn't enough

Large shopping centres running continuous, multi-sensor WiFi or BLE tracking across common areas tend to cross a threshold most retailers don't realise exists. If your WiFi analytics involve large-scale profiling or location tracking, you likely need a data protection impact assessment documenting the privacy risks and mitigations . A single boutique with one sensor counting entries is a different risk profile than a mall tracking movement across forty stores and three floors — the latter is exactly the kind of systematic, large-scale monitoring of a publicly accessible area that triggers a mandatory DPIA under Article 35.

If your footfall platform also feeds an indoor positioning layer — mapping which aisle someone lingered in, not just whether they entered — the accuracy and granularity of that data matters for the DPIA too. We've written separately about what indoor positioning technologies can and can't actually resolve in Indoor Positioning Without GPS: The Real Accuracy Numbers, which is worth reading alongside this one if you're scoping a mall-wide deployment rather than a single storefront sensor.

What "anonymized by the end of the day" actually looks like in practice

CNIL's guidance on audience measurement in physical spaces, still the most concrete published standard among EU regulators, lays out a specific operational sequence rather than a vague principle. Controllers should implement a reliable pseudonymization process for MAC addresses, including deletion of the raw data and use of a salt or key , and critically, the pseudonymized data must itself be anonymized or deleted by the end of the day . That second step is the one most vendor pitch decks skip. Hashing the MAC address at capture is a good first move. Keeping the hashed version indefinitely for trend analysis defeats the point, because a persistent hash is still a persistent identifier for that device.

The practical workaround most compliant platforms use is to convert individual hashed pings into aggregated hourly or daily counts, then discard the hash. You keep "340 visitors between 2pm and 3pm." You discard "device X was here at 2:03, 2:17, and 2:44." Once the discard step happens, the resulting number is genuinely outside GDPR's scope, because no single person remains identifiable inside it.

Captive portals and BLE apps: where explicit opt-in is non-negotiable

Everything above covers passive, non-personalised counting. The moment a venue wants more — a named profile, a loyalty tie-in, retargeted marketing based on store visits — the legal basis has to shift to explicit consent, and the consent flow itself has to be clean. Regulators are specific about what doesn't count: pre-ticked consent checkboxes are explicitly prohibited , and WiFi access cannot be conditional on marketing consent — guests must have a path to connect without opting in .

For shopping centres specifically, the consent architecture gets layered on top of the same hashing infrastructure used for aggregate counting. One industry guide to mall WiFi analytics describes the combined setup plainly: capturing the MAC address, immediately hashed using a one-way cryptographic function to maintain GDPR compliance, and measuring signal strength from multiple access points to estimate proximity and movement , while reserving explicit opt-in consent specifically for the captive portal authentication step where a shopper's identity actually enters the picture. Two different legal bases, running on the same sensor network, triggered by whether the visitor ever touches the login screen.

What good practice looks like end to end

• Hash MAC addresses at the edge, before they reach any central database, using a salted algorithm rather than a static or reversible transform.
• Rotate the salt on a defined schedule — daily is common — so no hashed identifier survives long enough to build a persistent profile.
• Aggregate pings into hourly or daily counts and discard the hashed identifier once aggregation is complete.
• Post visible signage wherever sensors operate, even for purely aggregate, non-marketing counting.
• Run and document a legitimate-interest balancing test before go-live, not after a regulator asks for one.
• Switch to explicit, unticked opt-in consent the moment data gets tied to an identifiable, returning visitor.
• Run a DPIA for any multi-sensor, mall-wide, or continuous monitoring deployment, not just for single-store pilots.

None of this is exotic. It's the same discipline that applies to any field data program handling identifiable signals at scale — the kind of structured, documented process we've described for other geodata work in Field Survey Methodology for Geodata: Sampling, Routing and QA. The specifics differ, but the underlying habit — document the basis, minimise what you keep, prove it later — doesn't change by data type.

Where enforcement actually lands

GDPR enforcement overall has not slowed down, and it gives useful context for how seriously regulators take location and device-identifier processing generally. Cumulative GDPR fines across the EU climbed from EUR 272.5 million in January 2021 to roughly EUR 7.1 billion by January 2026, according to DLA Piper's GDPR Fines and Data Breach Survey series . Dedicated WiFi-footfall enforcement actions remain rare compared to that total — most fines target bigger, more visible processing like ad tech or breach response — but the legal reasoning underpinning footfall analytics (what counts as personal data, what counts as a valid legitimate-interest basis) comes directly from the same body of case law and EDPB guidance driving those larger fines. A regulator that has just fined a tech company EUR 530 million over consent architecture (TikTok, Irish DPC, 2025) is not going to wave through a shopping centre's undocumented balancing test on a complaint.

Why the EU framing doesn't travel everywhere

It's worth saying plainly: not every market needs this level of legal scaffolding. The EU's default-to-personal-data posture, backed by a specific regulation with named legal bases and a continent-wide enforcement body, is unusual globally. The US relies on a mix of state privacy laws and sector rules like COPPA, with anonymization treated as good practice rather than a hard legal gate in most states. The UK runs a near-identical framework to GDPR post-Brexit, so most of this article applies there with minor terminology changes. If your footfall program operates purely outside the EU/UK/Switzerland axis, treat the compliance steps above as strong practice rather than a legal mandate — but build them in anyway, because the technical architecture (hash, rotate, aggregate, delete) costs little and keeps your options open if you ever expand into a market that does require it.

Frequently Asked Questions