What is a probe request?
Your phone spends its day quietly asking the air for Wi-Fi networks. Those short signals are probe requests, and they sit at the centre of how Wi-Fi discovery, device privacy and footfall measurement fit together.
Take a phone out of your pocket and it is already doing it: sending short bursts of radio signal that ask, in effect, “which Wi-Fi networks are out there?” Each of those bursts is a probe request. No app triggers it, no login is involved, and it happens whether or not you ever join a network. It is simply how Wi-Fi discovery works.
That one small frame explains a surprising amount: why your phone finds networks so quickly, why phone makers changed how devices identify themselves, why regulators pay attention to Wi-Fi analytics, and how a shopping centre can know how many people visited without knowing anything about any of them.
How a probe request works
Wi-Fi devices have two ways to discover networks. They can listen passively for the beacons that access points broadcast, or they can scan actively by transmitting probe requests and waiting for nearby access points to answer with a probe response. Active scanning is faster, so phones do both.
A probe request is a management frame, the housekeeping layer of the Wi-Fi protocol. It is not user traffic: it carries no messages, no browsing, no content. A probe can be directed, naming a specific network the device is looking for, or it can be a broadcast probe that asks for any network in range. The device sends probes at intervals that vary with manufacturer, operating system, battery state and whether the screen is on. Connected devices keep scanning too, at a lower rate, which is how your phone moves to a stronger network without you asking.
The practical consequence: anywhere people carry phones, the air already contains a steady, passive murmur of probe requests. No app, no login, no action from anyone.
MAC randomisation: the privacy arms race
Every probe request includes a sender address, the device’s MAC address. A decade ago devices probed with their real, permanent hardware address, and privacy researchers rightly pointed out the risk: a permanent identifier, broadcast constantly, could in principle be logged and reused.
Phone makers responded, and modern devices now send probe requests with randomised MAC addresses that change over time and differ per network. That was good for privacy and it also reshaped Wi-Fi analytics: a system that naively counts unique addresses today will count the same phone many times. Serious measurement has to detect and correct for randomisation, spoofing, stationary devices and staff-like behaviour rather than trusting raw identifiers. This filtering-and-modelling layer, not the raw signal, is where the quality of a footfall system is decided. How the resulting counts are validated and delivered is described in what data you get.
Why probe requests matter for privacy
The privacy question is not whether probe requests exist; every Wi-Fi network on earth runs on them. The question is what a receiving system does with the identifiers they carry, because an identifier that can be tied to a person is personal data under GDPR.
That is why Wi-Fi analytics deserves scrutiny in any procurement or DPIA, and why the design of the measurement system is the whole game. In a privacy-first design, personal data is irrevocably deleted, never hashed and kept, never stored, leaving only anonymous, aggregated statistics. No profile, no history, no way back to a device or a person. Bumbee Labs’ Wi-Fi method is built this way and is the only footfall method in Europe approved by a data protection authority; what that approval means in a compliance review is covered on GDPR-compliant footfall analytics.
From a murmur of signals to a footfall statistic
For measurement, the ambient signalling around a venue is a resource that already exists. Wi-Fi-based people counting reads those signals with the access points a venue already runs, anonymises at the start of the pipeline, filters out the noise, and calibrates the result against manual control counts. What comes out the other end is not a log of devices but statistics about a place: how many visited, how long they stayed, how they moved between zones.
A probe request on its own is a device asking for a network. Handled correctly, at aggregate scale, it becomes something more useful and less personal: an honest count of how a physical space is actually used.
Frequently asked questions
Does a probe request contain personal data?
A probe request is a management frame, not user traffic: it carries no messages, browsing or content. It does include a MAC address, and because an identifier tied to a device can be personal data under GDPR, what matters legally is what a receiving system does with it. Systems designed for privacy remove the link to any individual so that only anonymous, aggregated statistics remain.
Can a person be tracked through probe requests?
Raw, unprocessed probe data could historically be misused that way, which is exactly why regulators scrutinise Wi-Fi analytics and why phone makers introduced MAC randomisation. A privacy-first measurement system is built so no individual can ever be identified: personal data is irrevocably deleted, never hashed and kept, never stored, leaving only anonymous, aggregated statistics.
Do phones send probe requests while connected to a network?
Yes, most devices keep scanning even when they are connected, for example to find a stronger network, though how often varies by manufacturer, operating system and whether the screen is on. Probe behaviour is not a fixed clock; it is a moving target that measurement systems must be calibrated around.
Is probe-based people counting GDPR-compliant?
It depends entirely on the system's design, which is why the question belongs in every procurement. Bumbee Labs' Wi-Fi method was reviewed and approved by a European data protection authority, and our GDPR page walks through what that approval means for a compliance review.