GDPR and WiFi Analytics: What Consent Footfall Data Actually Needs

WiFi and Bluetooth Low Energy (BLE) footfall analytics means counting and tracking shoppers by capturing the radio signals their phones broadcast automatically, with no app install and no login required. Picture two shopping centres built the same year, running identical sensor hardware from the same vendor. One sails through a CNIL compliance check. The other gets a formal notice and a rewrite order. The hardware was the same. What differed was how each one handled legal basis, retention, and anonymization — the three questions this article answers in full.

Retailers and mall operators didn't invent this problem. Every phone with WiFi enabled sends out probe requests looking for known networks, dozens of times an hour, whether or not it ever connects to anything. Sensors near the entrance pick those up for free. That's the appeal, and it's also exactly why regulators pay attention: you're processing signals from people who never opted into anything, in a space they're just walking through.

This piece covers how the data actually gets collected, what GDPR classifies as personal data in that pipeline, when consent is genuinely required versus when legitimate interest covers you, and how the answer shifts across France, Germany, Switzerland, Belgium, and the Netherlands. We'll also cover what MAC address randomization has done to both the privacy picture and the accuracy of the numbers you're reading on a dashboard.

What the Sensors Actually Pick Up

Two mechanisms do almost all the work in physical-space analytics: WiFi probe requests and BLE advertising packets. A WiFi-enabled phone probe request refers to the signal a device sends out to discover nearby networks it has previously joined, a background process that happens continuously and was never designed with location analytics in mind. Collecting Wi-Fi probe request signals from shoppers' smartphones is one of the two common ways to count people in a space (Retail Sensing, 2024).

These probes carry a MAC address, a hardware identifier, along with a list of network names the phone remembers. A person's phone regularly sends a request to nearby networks to see which it can connect to, and these probe requests contain data about all the networks the phone has previously found, meaning details of all the physical locations that person has been to can potentially be accessed. That's the part that makes this more sensitive than a simple visitor count — it's not just "someone walked by," it's a fragment of someone's movement history.

BLE beacons work differently. A beacon broadcasts a short advertising packet; a phone's app (if installed and permissioned) listens for it and reports back proximity. BLE is generally opt-in by design, because it usually needs an app with location permission granted, whereas WiFi probe capture is passive and silent from the shopper's side. That distinction matters enormously for legal basis, which we'll get to.

Is a MAC Address Personal Data? Yes, Even Hashed

This is the single most misunderstood point in the industry, and vendors get it wrong constantly in their own marketing copy. WiFi-tracking relies on MAC addresses, which are considered personal data, even in hashed form (TechGDPR, 2023). Hashing a MAC address doesn't anonymize it — it pseudonymizes it, and pseudonymized data stays inside GDPR's scope. The European Data Protection Board formalized this distinction in its Guidelines 01/2025 on Pseudonymisation, adopted 16 January 2025. The EDPB indicates that pseudonymised data is still personal data as long as it can be linked to an individual with additional information, and the deletion of that additional information does not automatically render the data anonymous . In practice, a daily-rotated salt applied to a MAC address at the sensor is still pseudonymization, not anonymization, unless you can prove re-identification is impossible for anyone with access to the data — not just for you.

The follow-up EDPB Guidelines 04/2025 on Anonymisation went further, introducing three technical criteria for testing anonymisation: no record isolation, no linkability, and no inference that would let someone single out an individual in a dataset. The guidelines also take a hard line on mixed datasets: a dataset as a whole should only be considered anonymous if anonymisation is effective for every individual included in it, and where some records remain identifiable, the entire dataset must be treated as personal data unless the identifiable and anonymous parts are separated at a technical level . For a shopping mall with sensors across forty stores, that means one unanonymized zone can taint the whole dataset's legal status.

This lines up with the Court of Justice's 2025 ruling in EDPS v SRB, which the EDPB's guidelines now explicitly cite, confirming that identifiability has to be judged against the realistic means available to any party who might access the data — not just the controller's own capability (Bird & Bird, 2026). If your WiFi analytics vendor claims their hashed-MAC pipeline is "fully anonymous," ask them which of the three tests they've actually run.

Legal Basis: Consent or Legitimate Interest?

The basis of asking permission from the data subject usually does not provide a good basis for WiFi tracking, because in practice it is difficult to ask permission in advance from random pedestrians or shoppers (Privacy Company, 2019). You can't hand out a consent form to everyone who walks past a storefront. That's precisely why legitimate interest, rather than consent, is the legal basis most WiFi footfall deployments in the EU actually rely on. The legitimate interest basis can serve as grounds for processing MAC addresses in WiFi tracking — for example, a lessor of retail space may have a legitimate interest in collecting business economic information about the number of visitors per store over time . But legitimate interest isn't a free pass. It requires a documented balancing test, a way for people to object, and — critically — genuine anonymization or immediate pseudonymization at the sensor, not downstream.

France's CNIL set the template for this approach as far back as 2015, and it's still the reference point regulators and consultants cite today. The CNIL noted that data controllers may rely on their legitimate interest as a legal basis for the processing under GDPR , provided notice and opt-out mechanisms are in place (Hunton Andrews Kurth, 2015). In shopping malls, these devices can compile traffic statistics and determine how many individuals have visited over a limited time range, model the routes individuals take through the mall, and calculate the rate of repeating visitors — all of that is fair game under legitimate interest, as long as the operator can show the balancing test and give people a way out.

France's Opt-Out Model: The CNIL Playbook

The CNIL's guidance is unusually concrete, which is why it's worth walking through as a working template even outside France. The CNIL recommended using multiple modalities to provide notice to individuals, such as posting a privacy notice at entry and exit points of the shopping mall, on WiFi access points, on every advertising device, on the mall's website, or through a specific marketing campaign . Signage alone doesn't satisfy the requirement — it has to be paired with an actual way to object. For opt-out, the CNIL suggested a dedicated website or app on which individuals enter their MAC address to object to the processing, or a dedicated WiFi network that automatically collects the device's MAC address for opt-out purposes, using a clear and explicit network name such as "wifi_tracking_optout" . One thing the CNIL explicitly ruled out: data controllers should not recommend that individuals turn off the WiFi feature of their phone to avoid being tracked — that's treated as pushing the compliance burden onto the shopper, which defeats the point of an opt-out. This guidance traces back to a real enforcement case. In 2015, France's CNIL censured the billboard giant JCDecaux for installing WiFi boxes on their signs that captured the unique MAC addresses of passing smartphones — the firm wasn't properly anonymizing the data, and it wasn't getting people's informed consent either (IAPP, 2018). That case is a decade old now, but it's still the reference enforcement action the entire industry designs around.

How the Picture Shifts by Country

The GDPR text is the same across the EU, but national DPAs interpret the legitimate-interest balancing test with different levels of strictness, and Switzerland sits outside GDPR entirely under its own revised data protection act. Here's how the core question — can you run passive footfall counting without consent — plays out across the markets that matter most for retail and mall operators.

Jurisdiction	Primary legal basis for passive counting	Where consent becomes mandatory	Notable guidance
France	Legitimate interest, with documented notice and opt-out	Linking data to identity, marketing follow-up, retention beyond stated purpose	CNIL 2015 traffic-measurement guidance; JCDecaux enforcement
Netherlands	Legitimate interest for private commercial space; stricter for (semi-)public areas	Public-sector tracking outside a defined public task; any outdoor/street-level capture	Dutch DPA (AP) has issued strong opinions against WiFi tracking in semi-public spaces
Germany	Legitimate interest, but DPIA expectations run high given Germany's historically strict DPA posture	Any profiling tied to loyalty cards, apps, or cross-store identity matching	State DPAs apply GDPR Art. 6(1)(f) balancing with added documentation weight
Belgium	Legitimate interest, aligned with CNIL-style EU baseline	Captive portal data capture, marketing consent bundling	APD/GBA follows EDPB guidance closely; no major divergent national doctrine
Switzerland	Legitimate interest under the revised FADP (not GDPR, but closely modeled on it)	Cross-border data transfer, profiling with legal/significant effect	FDPIC oversight; GDPR-equivalence generally assumed but not identical
EU baseline (EDPB)	Legitimate interest for anonymized/pseudonymized presence counting	Consent required once data is no longer anonymous by the three-part test	EDPB Guidelines 01/2025 (pseudonymisation) and 04/2025 (anonymisation)

Outside the EU, the calculus changes. The UK's ICO runs a parallel but separate regime post-Brexit, and US guidance under the FTC and state attorneys general leans more permissive for presence analytics, with CCPA focused primarily on sale/disclosure rather than passive counting itself. If you're running a program that spans EU and non-EU markets, design to the strictest jurisdiction — it's cheaper than maintaining two pipelines.

When Consent Actually Becomes Mandatory

Passive, anonymized counting is one thing. The moment you connect footfall data to an identifiable person — a name, an email, a loyalty number, a returning device profile tied to a CRM record — you've left legitimate-interest territory. Mixing in the consent for tracking with the use of guest WiFi or a loyalty program is not possible; consent to WiFi-tracking should be given as an additional, non-required option (TechGDPR, 2023). That rules out the common pattern of "accept these terms to get online" doubling as tracking consent. The same principle shows up in captive portal design guidance: you cannot bundle it with the consent to access the WiFi. Consent has to be a separate, specific, unticked checkbox — not a condition of network access. That single design decision — separate checkbox versus bundled terms — is the difference between a compliant captive portal and a GDPR complaint waiting to happen. Retention adds another trigger. Suggested retention windows for guest WiFi data in retail settings run around twelve months after the last visit, and holding unhashed MAC addresses past that window for footfall analytics is one of the most common exposure points auditors flag. If your footfall data outlives its stated purpose, the legitimate-interest balancing test gets much harder to defend.

MAC Randomization: Good for Privacy, Bad for Your Dashboard

Here's where privacy engineering and measurement accuracy collide. Apple shipped the first version of MAC randomization in iOS 8 back in 2014, off by default. Android followed with per-network randomization as the default starting in Android 10, in 2019 — and macOS Sequoia made it the default for WiFi networks in 2024. iOS 18 went further, adding a rotation mode that generates a fresh address roughly every two weeks for unassociated probes (IronWifi, 2026). The privacy upside is real: a randomized MAC can no longer be trivially linked back to the same physical device across visits or venues. The accuracy downside is just as real. Venue operators have reported apparent unique visitor counts inflating by three hundred to five hundred percent after major operating system updates rolled out MAC randomisation by default (Purple.ai, 2026). If your weekly footfall report suddenly jumped 40% with no change in actual traffic, randomization — not a surge in customers — is the likely culprit. Vendors correct for this with temporal clustering (grouping probe bursts that arrive in tight windows as a single likely device) and by leaning more heavily on authenticated WiFi sessions, where the MAC is at least stable for the duration of a connection. Neither fix is perfect. This is the same accuracy ceiling discussed in more depth in our piece on what dwell time, capture rate, and conversion actually measure — the headline number on a dashboard is rarely the raw count, and understanding the correction method matters before you act on it.

The DPIA You Probably Need and Might Be Skipping

Under Article 35 GDPR, a Data Protection Impact Assessment is required whenever processing is likely to result in high risk to individuals — and location tracking at scale clears that bar almost automatically. If your WiFi analytics involve large-scale profiling or location tracking, you likely need a DPIA documenting the privacy risks and mitigations (IronWifi, 2026). Importantly, IT managers and DPOs must conduct a DPIA before deploying guest WiFi systems that include footfall analytics, real-time location tracking, or marketing profiling, and failure to conduct a required DPIA is itself a GDPR violation (Purple.ai, 2026) — independent of whether the underlying tracking turns out to be lawful. You can have a perfectly defensible legitimate-interest basis and still be in breach for never writing the assessment down. A DPIA for mall-scale WiFi analytics typically documents: the exact data captured (MAC, RSSI, timestamp, SSID list), the anonymization or hashing method and at what point it's applied, retention periods per data category, who else can access the raw feed (the vendor, the landlord, the brand tenants), and the balancing test against individual rights. This is also where the measurement and the legal paperwork meet the physical reality of a deployment — something covered in more depth in our guide to indoor positioning technologies and their real accuracy, since the DPIA has to reflect what the sensors can actually resolve, not just what the vendor's spec sheet claims.

WiFi Probes vs. BLE vs. Camera Counting: An Honest Comparison

None of these methods is universally "the compliant one." Each has a different default legal posture and a different operational ceiling.

Method	Data captured	Typical legal basis	Best for	Where it stops
WiFi probe request capture	MAC address, RSSI, SSID history, timestamp	Legitimate interest, if hashed/anonymized at the sensor	Passive footfall counts, dwell time, zone-to-zone movement across a whole mall	Accuracy degraded by MAC randomization; raw counts need correction
BLE beacon + app	Proximity to beacon, device ID, app-permissioned location	Explicit opt-in consent (app permission)	Precise in-aisle positioning, personalized offers for consenting app users	Only captures the subset of shoppers who installed the app and granted permission — often a small fraction of actual footfall
Captive portal / guest WiFi login	Email, name, authenticated session MAC, consent record with timestamp	Explicit consent, unbundled from network access	Return-visit tracking, CRM enrichment, verified first-party marketing data	Only covers shoppers who choose to log in — not a representative footfall count
Camera-based people counting (no facial recognition, counts only)	Aggregate counts and timestamps; no images retained	Often outside GDPR scope if no images are stored or individuals identified	Entrance-level traffic counts where WiFi sensor coverage is impractical	No individual-level dwell time, zone transitions, or return-visit detection

A Worked Example: Rolling This Out Across a Mall Chain

Consider a mid-size mall operator running forty stores across Germany, France, and Benelux, trying to standardize one WiFi analytics deployment across all of them rather than negotiating country-by-country. The practical build looks like this: sensors hash MAC addresses on-device before anything leaves the hardware, with daily key rotation so no cross-day linkage is possible even internally. Signage goes up at every entrance and on every WiFi access point, worded consistently across markets but adapted to each DPA's expected phrasing. A DPIA gets written once, as a template, then adjusted per site for any local variation — a captive portal in one location, pure passive counting in another. Retention is capped at twelve months for aggregated statistics and essentially zero for raw probe data beyond the on-device processing window. Teampl has run its own WiFi signal-scanning field operations at exactly this scale — thousands of scans a day across Germany, France, and the Benelux region — which is where a lot of the operational detail in this article comes from: the gap between what a vendor's compliance deck promises and what a sensor actually logs in the field is where most of the real risk lives. Getting that gap closed before go-live, not after a DPA inquiry, is the entire point of a DPIA.

Common Mistakes That Trigger a Compliance Problem

• Treating hashed MAC addresses as anonymous. They're pseudonymized, not anonymized, under EDPB Guidelines 01/2025 — and still personal data.
• Bundling tracking consent into network terms. You cannot bundle it with the consent to access the WiFi; it must be a separate, unticked option.
• Skipping the DPIA because "it's just counting." Large-scale location profiling almost always clears the Article 35 threshold, regardless of anonymization quality.
• Recommending shoppers disable WiFi to avoid tracking. The CNIL explicitly flagged this as an inadequate substitute for a real opt-out mechanism.
• Ignoring MAC randomization in reported numbers. A 300–500% count inflation after an OS update isn't a traffic surge — it's a measurement artifact that needs correcting before it reaches a board deck.

Where This Article Fits Into the Bigger Measurement Picture

GDPR compliance is the legal ceiling on what you can collect. It's not the same question as whether the number you end up with is accurate, or whether it means what a leasing team thinks it means. Those are separate problems, covered in our breakdown of what dwell time, capture rate, and conversion actually count, and in our look at the real-world accuracy limits of indoor positioning more broadly. A fully compliant WiFi analytics deployment can still produce misleading numbers if MAC randomization, sensor placement, or capture-rate assumptions go unchecked. Compliance gets you permission to measure. It doesn't guarantee you're measuring the right thing well.

Frequently Asked Questions