Probe Requests, MAC Randomisation, and What Retail Analytics Can Still Measure

A probe request is a Wi-Fi management frame that a smartphone broadcasts to ask nearby access points which networks are available, and it is the raw material behind most Wi-Fi-based foot-traffic analytics. Retail and mall operators have logged these frames since around 2013 to count visitors, measure dwell time, and estimate conversion, all without anyone connecting to a network. The technique never required an app, a login, or a receipt.

Then operating systems started randomising the MAC address inside that frame. Apple shipped it first, in iOS 8, back in 2014. Android and Windows followed over the next several years, and by the early 2020s a stable, trackable MAC address in a probe request was the exception rather than the rule. That single change reshaped an entire analytics category, and most public explanations of it are either outdated or written by vendors with an obvious interest in saying "don't worry, it still works fine."

This piece lays out what's actually still measurable, what changed and when, and how the legal basis for collecting any of it holds up under GDPR — with the EU treated as the lead jurisdiction, since France, the Netherlands, Belgium, Germany, and Switzerland have each produced distinct regulatory positions worth separating out.

How a probe request actually works

Every Wi-Fi-capable device periodically scans for networks it recognises, and it does this by sending unencrypted probe request frames into the air, whether or not it ever connects. Smartphones with WiFi can be used as an indicator of customer presence thanks to a WiFi mechanism common across all such devices: probe requests, which are 802.11 management frames transmitted at regular intervals and contain information that can be used to identify presence, time spent, and repeat visits within range of an access point. A retail Wi-Fi sensor or access point just has to listen.

Historically, the frame carried the device's real, factory-assigned MAC address in the clear. Even a device not connected to a Wi-Fi network periodically sends probe requests searching for networks that might be available, sometimes even when Wi-Fi functionality itself is not activated. Before randomisation became standard, that meant the fixed and unique MAC address of the terminal was sent, and by collecting these frames over time together with location technologies, it was possible to uniquely identify the terminal and record its journey within the coverage area of the Wi-Fi network. That was the entire foundation of first-generation Wi-Fi footfall analytics: one stable identifier, seen at multiple sensors, over multiple days.

Bluetooth Low Energy: a related but different signal

Bluetooth Low Energy (BLE) refers to a low-power wireless protocol that small beacon transmitters use to broadcast a short identifier at regular intervals, which a nearby phone's Bluetooth radio can detect. Retail deployments use it two ways: beacons placed in-store that a retailer's own app detects (requiring the app installed and Bluetooth enabled), or BLE-scanning sensors that passively listen for the addresses phones broadcast during Bluetooth's own discovery process. Foot-traffic location information is based predominantly on 802.11 wireless and Bluetooth standards , and the two are often deployed side by side in malls, with Wi-Fi covering passive detection and BLE covering app-based engagement and micro-location inside a specific store.

The privacy tradeoff runs in the opposite direction from Wi-Fi probes. A BLE beacon can't identify a phone that hasn't installed the retailer's app, so it captures a smaller, more engaged slice of visitors — but that slice comes with an explicit install-and-permission step, which is a much cleaner consent story than passively logging every phone that walks past a storefront.

What MAC randomisation changed, and when

MAC address randomisation refers to a device generating a temporary, locally-administered address for probe requests instead of using its permanent, factory-assigned one. Vendors such as Apple, starting from iOS 8, and Microsoft, starting from Windows 10, introduced their own randomisation mechanisms before formal standardisation, and the IEEE eventually formalised MAC address randomisation in the 802.11aq amendment for probe requests during the pre-association stage. The rollout was staggered by years and inconsistent across vendors, which is exactly why analytics accuracy varies so much by device mix even today.

Platform / spec	First shipped	What changed
iOS	iOS 8 (2014)	Randomised MAC used for probe requests while not associated to a network
Windows	Windows 10 (2015)	Optional randomisation, dependent on hardware/driver support (Vanhoef et al., ASIACCS 2016)
IEEE 802.11aq	802.11-2016 amendment	Formal standard for randomised pre-association addressing, replacing vendor-specific behaviour
iOS / Android, mature phase	iOS 14+, Android 10+ (2019–2020)	Per-network random addresses became the effective default, materially reducing persistence for unique-visitor tracking
IEEE MADINAS / 802.11bh / 802.11bi	Ongoing	Working groups formed specifically to close remaining fingerprinting and timing-based re-identification gaps

None of this made devices untraceable. One study of MAC address randomisation implementations across a variety of mobile devices found that 90% were vulnerable to some form of re-identification, usually through sequence numbers, information-element fingerprints, or scan-timing patterns rather than the address itself. Those findings, among others, prompted the formation of the IEEE 802.11bi task group and the IETF's MADINAS working group , both still active, working on closing the gaps that randomisation alone didn't fix.

What retail analytics can still measure, realistically

The honest answer sits between "nothing changed" and "it's useless," and it depends on which metric you're asking about.

Metric	Pre-randomisation (pre-2014)	Current state
Aggregate footfall / occupancy	Accurate	Still accurate — counting probe requests per time window doesn't need a stable identifier
Passers-by vs. entrants	Accurate	Still accurate for the same reason — it's a signal-strength and zone comparison, not identity matching
Dwell time in a zone	Accurate	Still reasonably accurate within a single visit, since the random MAC typically persists for that session
Unique visitor count	Exact	Estimated — requires statistical de-duplication, since one visitor can appear as several MACs
Repeat-visit / loyalty tracking across days	Exact, long-horizon	Degraded — cross-day matching relies on probabilistic signals or requires captive-portal authentication
Cross-mall / cross-property journey tracking	Straightforward	Largely broken passively; requires app-based or loyalty-card identity to reconstruct reliably

A properly configured retail deployment can still achieve 85–92% device detection accuracy, and dwell time remains the metric that correlates most directly with purchase probability — which is why most operators haven't abandoned the technology, even after randomisation. What they've done instead is shift from "unique visitor" claims toward aggregate and session-level metrics, and toward pairing Wi-Fi presence data with a captive portal or loyalty app whenever they genuinely need identity to persist. Our companion piece on how malls actually count visitors goes deeper on the sensor placement and de-duplication logic behind those aggregate numbers.

Dwell time also varies predictably by category, which matters for interpreting any deployment's output. Quick-service retail typically sees dwell times of three to eight minutes, fashion and apparel eight to fifteen, electronics twelve to twenty, and home goods fifteen to twenty-five (Flame Analytics, 2026, accessed September 2026). A five-minute average dwell time in an electronics showroom is a red flag; the same number in a convenience store is normal.

The GDPR question: legal basis, anonymisation, and the 2026 EDPB guidelines

Under the GDPR, a controller collecting probe-request or BLE data needs one of six legal bases, and most of them don't apply here. Of the six possible legal bases under Article 6(1), legal obligation, vital interest, and public interest certainly don't apply, since Wi-Fi tracking is none of those things — which leaves consent, contract performance, and legitimate interest as the realistic options. Consent is the cleanest legally, but it has to be real. Consent to Wi-Fi tracking should be given as an additional, non-required option, and it needs to be revocable as easily as it was given, with a system in place allowing withdrawal at any time.

Anonymisation is the other route, and it's the one most vendors misrepresent. Hashed or encrypted versions of a MAC address are still pseudonymous if they can uniquely single out one device belonging to a natural person, and pseudonymising data doesn't move it out of GDPR scope, since it can still be linked back to a person with additional information. True anonymisation is harder than a hash function. Data only escapes GDPR scope once it's genuinely aggregated with a significant enough sample size that it can no longer be related back to a single data subject.

The EDPB updated its thinking on this substantially with Guidelines 02/2026 on Anonymisation, adopted 7 July 2026. The framework moved from a checklist to an outcome test. Anonymisation is now a likelihood test rather than a checklist: data is anonymous under the GDPR only when it no longer relates to an identified or identifiable person, identification is judged by means reasonably likely to be used, and the risk only needs to be very low rather than completely impossible — and anonymity is relative, since the same dataset can be anonymous for one recipient and not another. The EDPB tests this against three criteria. It checks for no record isolation, no linkage, and no inference — and a hashed MAC that lets you re-link the same device across five store visits fails the linkage test outright, regardless of how strong the hash is.

In practice, that means retention windows and temporal aggregation do more compliance work than the hashing algorithm itself. Rotating pseudonyms per session, aggregating events into short time windows rather than logging every frame, and refusing to cross-reference Wi-Fi presence data against loyalty or CRM records are the controls that actually move a dataset toward the anonymous side of the line.

France, Germany, Switzerland, Belgium, the Netherlands: same law, different postures

All EU member states apply the same GDPR text, but national data protection authorities have taken visibly different positions on Wi-Fi tracking specifically, and France has gone furthest in publishing an explicit, workable model.

Jurisdiction	Regulator	Documented position
France	CNIL	Published detailed rules for audience/traffic measurement in publicly accessible areas, including opt-out via a clearly named network and a ban on telling people to just switch off Wi-Fi
Netherlands	Autoriteit Persoonsgegevens	Fined a municipality over Wi-Fi tracking in a public space in 2021; among the strictest enforcement records in the bloc on this technology
Belgium	Autorité de protection des données	Cited alongside the Dutch and UK authorities as increasingly scrutinising Wi-Fi tracking and processing of personal data in commercial contexts
Germany	Federal + state DPAs (BfDI / Landesdatenschutzbehörden)	Applies GDPR directly with no Wi-Fi-specific national guidance published, so legitimate-interest assessments and DPIA thresholds carry more weight in practice
Switzerland	FDPIC	Not an EU/GDPR jurisdiction — governed by the revised Federal Act on Data Protection (in force since 1 September 2023), which applies broadly similar necessity and transparency principles without EDPB guidance binding it directly

The CNIL recommended using a clear and explicit name for the opt-out network, such as "wifi_tracking_optout," and stated that data controllers should not recommend that individuals turn off the Wi-Fi feature of their phone to avoid being tracked , since that's not a meaningful way to let someone exercise their right to object. Where the technical conditions aren't strictly met, the CNIL's position is that processing may only be implemented with individuals' consent, and that consent must be as simple to withdraw as it was to grant . Separately, for the general analytics-tracker exemption that some operators try to lean on, the CNIL's conditions include not cross-checking the data with other processing such as customer files or visit statistics from other sites, limiting the tracer's scope to a single site or app, and limiting tracker lifetime to 13 months .

Belgian, UK, and Dutch data protection authorities have each been described as increasingly scrutinising Wi-Fi tracking and the processing of personal data it involves , which is a meaningfully different enforcement posture from Germany's, where GDPR is applied without a Wi-Fi-specific national interpretation published to date. Spain's AEPD has also published dedicated technical guidance walking through the probe-request mechanism and the same de-anonymisation research base cited above, treating Wi-Fi tracking as squarely within scope of ordinary GDPR analysis rather than a special case.

Enforcement: what regulators have actually done, not just said

Guidance documents are one thing; fines are another, and the record here is thinner than the volume of guidance would suggest. The clearest documented case is the Dutch DPA's 2021 action against a municipality for Wi-Fi tracking in a public square — a case that keeps showing up as the reference point in other regulators' own guidance, including Spain's AEPD. That pattern is itself informative: this is a technology regulators keep writing about and occasionally act on, but large commercial fines specifically for probe-request analytics remain rare compared to cookie or ad-tech enforcement. The practical risk for most retail deployments is less "surprise fine" and more "DPIA gap surfaced during an audit, tenant dispute, or data subject access request."

Outside the EU: the US, UK, and other markets

Outside the EU, the framing shifts from a single default-restrictive law to a patchwork of sector and state rules. The US has no federal equivalent to GDPR; Wi-Fi analytics there sits under general FTC unfairness/deception authority and an expanding set of state privacy laws, several of which (California's CPRA among them) treat MAC-address-based identifiers as personal information once they can be linked to a device or household. The UK, post-Brexit, still runs UK GDPR with materially the same anonymisation and legitimate-interest tests as the EU version, administered by the ICO rather than a national DPA network — which is why UK enforcement patterns track closer to the Netherlands and Belgium than to the US model. Markets like the UAE, Singapore, and most of Southeast Asia have data protection laws modelled partly on GDPR but without an equivalent body of Wi-Fi-specific guidance yet published, so operators there are largely applying first principles: minimise, disclose, and don't cross-reference identifiers across systems.

A worked example: sizing a mall entrance's real conversion funnel

Consider a mid-size regional mall with four entrances and Wi-Fi sensors mounted near each one, plus zone sensors in the food court and two anchor-adjacent corridors. Passive probe detection at the entrances gives a passers-by count and an entrants count for each door — no identity needed, just signal presence inside a defined RF boundary during a time window. That ratio is the storefront's attraction rate, and it's measurable whether or not a single device in the count uses a randomised MAC.

Where it gets harder is the next question a leasing manager usually asks: how many of today's visitors were here last month? Answering that with any precision now requires either a captive-portal login (explicit consent, persistent identity, smaller sample) or a statistical de-duplication model that accepts a margin of error and reports a range rather than a single number. Neither is a failure of the technology — it's the tradeoff randomisation was designed to force. A mall operator who understands that tradeoff reports "returning-visitor rate: 34–41%, based on session clustering" instead of a false-precision single figure, and that honesty is what actually holds up during a tenant rent-review dispute or a DPIA.

Teampl has run its own version of this at scale: WiFi signal-scanning field operations across Germany, France, and the Benelux region, collecting thousands of scans a day to validate exactly this kind of coverage and detection-rate question before analytics vendors get switched on. The gap between what a sensor spec sheet claims and what it actually detects in a real, RF-noisy commercial building is usually the first thing worth verifying independently, and it's a different exercise from the indoor mapping work covered in our comparison of LiDAR, photogrammetry, and mobile scanning methods for building the underlying floor plan those zones are drawn on.

What to check before you deploy or audit a Wi-Fi analytics program

• Legal basis, written down: confirm whether the program relies on consent, legitimate interest with a documented balancing test, or genuine anonymisation — not an assumption that "it's just Wi-Fi data."
• DPIA on file: large-scale location tracking and behavioural profiling generally trigger the Article 35 threshold; check it exists and is current, not from the original 2019 rollout.
• Retention window: match it against CNIL's 13-month benchmark for comparable trackers, or your own DPA's published figure, and confirm raw frame-level logs aren't kept indefinitely "for model training."
• No cross-referencing: verify presence data isn't silently joined against loyalty, CRM, or ad-ID datasets — that join is what turns pseudonymous into personal, fast.
• Opt-out mechanism: a real one, clearly labelled, that doesn't just tell visitors to turn off their phone's Wi-Fi.
• Device-mix assumptions: ask the vendor what detection accuracy figure they're quoting and against what OS version mix — an 85-92% number measured on a 2021 device fleet won't hold on 2026 hardware.

Start a project

Teampl runs field data collection programs — egocentric video, in-store audits, mystery visits, GIS surveys — designed around a specific research question, not a generic panel. If this topic touches a program you're planning, tell us what you're trying to learn.

Frequently Asked Questions