Retail Data Goldmine: Wi-Fi Footfall Analytics
| Retail Analytics
Probe tracking fails under MAC randomisation. How to run PDPO-compliant footfall analytics.
Why the old idea no longer holds: probes, MAC addresses and repeat visitors
For years, the pitch for retail Wi-Fi footfall analytics sounded straightforward: as long as shoppers kept Wi-Fi switched on, in-store probes could detect their devices, count heads, work out entry rates and recognise repeat visitors. That pitch no longer holds. The reason is not that the concept itself was wrong, but that phone behaviour and privacy expectations have both moved on. Before writing any footfall analytics plan, two realities need to be clear. First, modern phones do not present the same MAC address over time. Second, in Hong Kong, collecting and using this kind of data has to follow the principles of the Personal Data (Privacy) Ordinance.
What a probe request is
To find nearby Wi-Fi networks, a device sends out probe requests. Probe requests are part of how Wi-Fi works, not a feature designed for counting people. Probe detection places receivers in store to listen for these requests and build statistics from what they hear. It can sound like a way to count footfall without asking shoppers to do anything, but the problem is that the identifying information inside probe requests is no longer stable.
What MAC randomisation changed
A MAC address is the hardware identifier a device presents on a network, 48 bits long. Devices used to connect to Wi-Fi with a fixed factory MAC address, which allowed a device to be tracked and individually identified. That is no longer the usual case. Apple states that an iPhone uses a distinct private network address on each Wi-Fi network it joins, which helps reduce tracking of the iPhone across networks. Android documentation states that devices running Android 10 or later use a randomised MAC address by default, with a different randomised MAC address for each SSID. In other words, the same phone presents a different MAC address in different shops and on different networks, so joining visit records across networks by MAC address alone is not reliable.
Even on the same network, a randomised MAC address may not stay stable over time. Android documentation describes persistent randomisation, under which the MAC address stays unchanged until a factory reset, and non-persistent randomisation, used in some situations on Android 12 or later, under which a new randomised MAC address may be generated on a later connection, for example after a DHCP lease has expired and the device has been disconnected from the network for a while. Users can also switch randomisation on or off by hand. Treating a MAC address as a long-term stable customer identifier does not match how modern phones behave by default.
Why probe counts are not headcounts
Beyond randomisation, probe detection has coverage limits: a device with Wi-Fi switched off sends no Wi-Fi probe requests; one person may carry several devices; and one device may present different randomised MAC addresses at different times. Probe counts therefore do not equal headcounts, and any statement that presents probe counts as headcounts is wrong. Repeat-visitor detection has the same problem: judging repeat visitors by MAC address alone is not reliable. If a shop wants to understand repeat visits, it should rely on verifiable channels the visitor provides willingly, such as an account, membership or survey, rather than inferring identity from passive tracking.
Hong Kong's PDPO: principles to settle before collecting anything
Hong Kong's Personal Data (Privacy) Ordinance (Cap. 486), Schedule 1, sets out six Data Protection Principles. The points below cover the principles most directly relevant to Wi-Fi footfall analytics, as general reference only, not legal advice. How the Ordinance applies to a specific deployment should be reviewed by a qualified legal professional against the actual facts.
DPP1: purpose, necessity and collecting only what is needed
Data Protection Principle 1 (DPP1) requires that personal data must not be collected unless it is collected for a lawful purpose directly related to a function or activity of the data user, that the collection is necessary for or directly related to that purpose, and that the data is adequate but not excessive for that purpose. The means of collection must also be lawful and fair. DPP1 further requires the data user to take reasonably practicable steps to tell the data subject, on or before collection, whether providing the data is voluntary or mandatory, the consequences of not providing it if mandatory, the purpose for which the data will be used, the classes of persons to whom the data may be transferred, and the rights to access and correct the data together with the contact details for such requests. Applied to Wi-Fi footfall analytics, this means a shop should first define a specific purpose, such as understanding overall in-store footfall distribution, improving shelf layout or planning staffing periods, rather than collecting as much data as possible for possible future use; collect only what that purpose needs; and explain the arrangements above before collection.
Whether a MAC address counts as personal data depends on whether an individual can be identified in practice in the specific circumstances. If a MAC address can be combined with other data to identify a person, it should be handled as personal data. This article does not claim that any MAC address is or is not personal data; the actual answer depends on the specific system design.
DPP3: use beyond the original purpose needs separate consent
Data Protection Principle 3 (DPP3) provides that personal data must be used only for the purpose for which it was collected, or a purpose directly related to it, unless the data subject gives prescribed consent for another use. Prescribed consent means the data subject's voluntary express consent, not withdrawn in writing. In practice, data collected to provide guest Wi-Fi access must not be repurposed automatically for direct marketing, individual customer tracking, merging with other systems to build personal profiles, or handing to third parties for new purposes, unless the new use is directly related to the original purpose or prescribed consent has been obtained. Connecting to Wi-Fi, on its own, does not amount to consent for other uses of the data.
The remaining principles: retention, security, openness, access and correction
Data Protection Principle 2 (DPP2) requires data to be correct and kept only for as long as needed to achieve the collection purpose, not longer. Data Protection Principle 4 (DPP4) requires reasonably practicable steps to protect personal data against unauthorised or accidental access, processing, erasure, loss or use. Data Protection Principle 5 (DPP5) requires openness about policies and practices for personal data, the kinds of personal data held and the main purposes of use. Data Protection Principle 6 (DPP6) gives data subjects rights to access and correct their personal data. This article gives no specific retention periods or penalty figures, because those are not matters a general reference article should settle on the reader's behalf.
Putting compliance first: aggregate statistics based on connected guest Wi-Fi
Putting these principles into practice, the more defensible approach is to base statistics on visitors who actively connect to the shop's Wi-Fi, and to use aggregate statistics as the default output. A visitor who actively connects, and sees the collection purpose and related notice during connection, is a clearer collection situation than passive detection of unconnected devices. Statistics from the connected stage can come from device connection and disconnection records with access points, aggregated by area or access point, rather than focusing on tracking individual devices.
Define the purpose first, then choose the tool
Before deployment, define the purpose in writing: for example, understanding overall in-store footfall distribution, improving shelf layout or planning staffing periods. The purpose should be specific, not framed as collecting as much data as possible for possible future use. Only then should the tool and the scope of collection be chosen. If aggregate statistics can already answer the business question, individual-level identifying data should not be collected. That ordering is itself the practical expression of DPP1's requirement that collection be necessary, directly related, adequate but not excessive.
State the collection arrangements on the landing page
The guest Wi-Fi landing page is the natural place to state the collection notice. The notice should explain the collection purpose, the categories of data, the classes of transferees, whether providing the data is voluntary or mandatory, and the contact arrangements for access and correction requests. A generic privacy policy link, without explaining the specific use of Wi-Fi data at the point of collection, is not enough. The notice should be given before or at collection, not added afterwards.
Keep sign-in and marketing consent separate
Sign-in and marketing consent should be handled separately. A visitor should be able to connect to Wi-Fi only, without choosing to receive marketing messages. Tying the two together, so that refusing marketing means no Wi-Fi access, is not recommended here as a compliant approach. Any use beyond the original collection purpose, such as direct marketing or sharing with third parties for identification, needs prescribed consent first. Separation has to work in the system settings as well as on paper: a visitor who declines marketing should not find their details flowing into a marketing list automatically.
What aggregate statistics can show
The table below sets out common types of aggregate indicators and their limits. The point is that output should be aggregate figures and trends, not the movement trails of individual devices.
| Indicator | Approach | Limitation |
|---|---|---|
| Entry-rate trend | Aggregate first-connection records of connected visitors by time period, and compare against overall changes in doorway footfall | Covers connected visitors only, not every shop entrant |
| Dwell-time distribution | Aggregate connection durations by area or access point | Connection duration is not the same as the time a shopper actually spends in store |
| Relative area heat | Compare aggregate connection volumes across areas, in relative terms | Affected by access point positions and signal range; not a per-shelf footfall ranking |
What to do and what not to do
| Do | Do not |
|---|---|
| Define a specific purpose before collecting, and collect only what is needed | Collect excessive identifying data on the grounds that it may be useful later |
| State the collection purpose, classes of transferees, voluntary or mandatory nature, and access and correction arrangements on the landing page | Post only a generic privacy policy link, without explaining the specific use of Wi-Fi data at collection |
| Present entry-rate, dwell-time and heat-area trends as aggregate statistics | Output or keep movement trails or visit-time sequences for individual devices |
| Base statistics on connected guest Wi-Fi and information visitors provide willingly | Track individuals or build repeat-visitor profiles from passive detection of unconnected devices by MAC address |
| Keep sign-in and marketing consent separate, so a visitor can connect without receiving marketing | Make marketing consent a condition of Wi-Fi access, or treat connecting as consent for other uses |
| Use data only for the notified purpose or a directly related purpose; obtain prescribed consent for a new use first | Repurpose access-provision data for direct marketing, merge it into personal profiles, or hand it to third parties for new purposes, without prescribed consent |
| Keep data only until the purpose is achieved, then delete it or render it non-identifiable | Keep raw MAC addresses or individual device records indefinitely |
| Separate the guest network from internal business networks, and limit access rights | Let unrelated staff or third parties freely inspect raw device records |
Checklist before starting
- Has the purpose been written down, with collection limited to what that purpose needs?
- Does the landing page state the purpose, classes of transferees, voluntary or mandatory nature, and access and correction arrangements?
- Is the output aggregate statistics, without movement trails for individual devices or breakdowns that could identify a person?
- Are sign-in and marketing consent separate, so that a visitor who declines marketing does not end up on a marketing list?
- Is the guest network separated from the shop's internal business network, with access to raw data limited to staff who need it?
- Are retention arrangements limited to what achieving the purpose needs, with deletion or non-identifiable handling settled for when the purpose is complete?
- If a third-party supplier will handle personal data, does the contract state that it may process the data only as instructed and must protect data security?
- Is there a regular review of whether collection is still needed, and whether its scope still matches the purpose?
Disclaimer
This article is general reference only, not legal advice. How the PDPO applies to a specific deployment depends on the actual collection method, notice arrangements and purpose, and should be reviewed by a qualified legal professional. Shops should assess their own circumstances before deploying footfall analytics, and should not treat this article as a compliance ruling.
To plan guest Wi-Fi, in-store coverage and back-office networks as one design, see Wi-Fi Solutions, or see Office Networks for how segmentation and back-office networks fit together. For an assessment based on a specific site, contact us.