TL;DR / Key Takeaways
- WiFi analytics has two modes: presence (anonymous, sensor-based) and engagement (identified, captive-portal-based). Most venues need both, with each answering a different question.
- MAC randomisation changed the discipline. Platforms that adapted use statistical correction and consented identification to maintain ±3-7% accuracy versus camera ground truth. Platforms that ignored the change have lost accuracy.
- The headline metrics are footfall, dwell time, return-visit rate, zone transitions, new-vs-returning split, and capture rate. The honest reading is the corrected figure with the confidence interval, not the raw probe count.
- CCPA-compliant analytics is achievable with hashed MAC and rotation for presence, explicit consent at the portal for engagement, a DPIA, and clear venue signage. the FTC and state attorneys general and the EU's CNIL have both issued positive guidance on the model.
- The strongest sector applications are retail, shopping malls, airports, stadiums, museums, and corporate offices. Each uses the same data model with a different framing layer on top.
Most venues are sitting on a sensor network they have already paid for: the access points they put in for guest WiFi. The same hardware, the same RF events, the same association logs, used differently, produce a usable account of who walked in, how long they stayed, where they went, and whether they came back.
That is WiFi analytics. It is not a perfect substitute for a turnstile counter at the door or a computer-vision camera on the till. It is a much cheaper substitute that covers the whole venue rather than one chokepoint, and that surfaces movement and dwell data the cameras cannot produce.
This guide is the operating reference for venue and marketing teams considering or running WiFi analytics. It covers the two modes (presence and engagement), the metrics that matter, what MAC randomisation broke and how the discipline adapted, the comparison against alternative people-counting technologies, the CCPA / CPRA shape, and the sector applications that work.
The two modes: presence and engagement
Almost every confused conversation about WiFi analytics is the result of mixing these two up. They use different data, answer different questions, and run under different legal bases.
Presence analytics
Anonymous, sensor-based, derived from probe requests and association logs. Counts unique devices in a zone over a time window. Hashed MAC with rotation as the technical privacy control.
Answers: how many people came in, how long they stayed, how they moved between zones, and whether overall volume is up or down.
Lawful basis: legitimate interest with DPIA, signage, opt-out.
Engagement analytics
Identified, captive-portal-based, derived from sign-ins and ongoing sessions. Ties visits to a contact record. The substrate for segmentation, journeys, and lifecycle marketing.
Answers: who came in, how often they come, what time of day, which sites of a multi-site brand, and the marketing-actionable cohort behavior.
Lawful basis: explicit consent at the portal sign-in.
Most venues need both. Presence gives the headline footfall and dwell numbers, comparable like-for-like across sites. Engagement gives the identified cohort that marketing can actually run journeys against. The two are joined at the captive portal: a visitor who signs in moves from the presence dataset to the engagement dataset for that visit.
MAC randomisation and why it changed the discipline
For most of the 2010s, WiFi analytics rested on a quietly false assumption: that a device’s MAC address was stable across visits. iOS 14 (2020) broke that for iPhones. Android 10 broke it for Android. Windows 11 and macOS Sonoma extended the change to laptops. By 2026, the great majority of consumer devices present a randomised, rotating MAC during probe requests before association.
Naive counting that treated each unique MAC as a unique device started over-counting. Return-visit rates collapsed; new-visitor share rocketed; cohort retention curves stopped making sense.
The discipline adapted in two ways. First, statistical correction: probabilistic models that account for the expected randomisation rate and rotation cadence per device class, calibrated against camera ground truth at known sites. Second, identification through the captive portal: visitors who sign in present a stable identity that survives randomisation entirely.
The combined accuracy of a corrected presence stream plus an opted-in engagement layer in 2026 is comparable to where 2018 footfall analytics sat, with a stronger privacy story. The vendors that did the correction work have maintained accuracy; the vendors that did not have lost it. Worth checking explicitly during evaluation.
Want to see how MAC rotation affects your metrics? Use our free MAC Randomization Simulator (from our free WiFi tools library) to model raw device counts, ground truth visitor counts, and the reconciled counts.
The randomisation timeline
- 2014: iOS 8 introduces randomised probes (off by default in practice).
- 2020: iOS 14 randomises per-SSID by default.
- 2020: Android 10+ randomises per-SSID by default.
- 2022: Windows 11 expands to all WLAN probes.
- 2023: macOS Sonoma matches iOS behavior on laptops.
- 2026: randomisation is the dominant assumption; static MAC is the edge case.
The six metrics worth reporting
WiFi analytics platforms can produce a hundred derived metrics. Six of them carry almost all the decision weight.
Footfall
Unique visitors entering a defined zone in a time window. The headline KPI for retail and venue operators.
Dwell time
Median, p25/p75, p95 time-in-zone per visit. Distinguishes browsers from buyers.
Return-visit rate
Share of visitors in a window who also visited in the previous N days. Loyalty signal.
Zone transitions
Origin-destination flows between defined zones. The basis for journey analytics and layout testing.
New vs returning
Acquisition vs retention split. Useful for marketing attribution and for honest reporting of footfall lift.
Capture rate
Share of detected presence converting to a captive-portal sign-in. Bridge between presence and engagement.
WiFi vs cameras vs door sensors
WiFi analytics is not the only people-counting technology. The right answer for most venues uses two of them together: a high-accuracy chokepoint counter at the front door and WiFi across the whole venue for dwell and journey.
| Method | Accuracy | Coverage | Cost | Privacy | Journeys |
|---|---|---|---|---|---|
| WiFi presence | ±3-7% | Whole venue | Uses existing APs | Hashed MAC, opt-out, signage | Native |
| Computer vision | ±1-3% at doorway | Field of view only | Per-camera + compute | Strongest concern in EU | Limited |
| Door sensor (IR / 3D) | ±2-4% | Doorway only | Per-door | Low | None |
Sector applications
The data model is the same across sectors; the framing layer on top is what changes. Six sectors do most of the work.
Compliance: CCPA / CPRA, CNIL, UK GDPR, ISO 27001
WiFi analytics that respects privacy is a solved problem. The model below is what the CNIL has explicitly approved and what the FTC and state attorneys general has consistently allowed. Sweetgreen, Chase, and Eastern Michigan University all run venue analytics on Purple.
CCPA / CPRA
Presence analytics: legitimate interest with DPIA. Engagement analytics: explicit consent at the portal. Hashed MAC with rotation is the accepted technical control for presence.
Reference ›CNIL guidance
The French regulator has issued specific guidance on WiFi analytics. The model that satisfies the CNIL is the one the rest of the EU follows.
Reference ›CCPA / CPRA
California requires a privacy notice and opt-out mechanism. WiFi analytics that aggregates and anonymises sits within the existing privacy-policy framework.
Reference ›ISO 27001
Annex A.5.34 (privacy and protection of PII) and A.5.12 (classification of information) apply. The platform should produce a DPIA template and a retention-schedule export.
Reference ›The four operational requirements: a completed DPIA, hashed MAC with rotation for the presence stream, explicit consent at the captive portal for the engagement stream, and visible venue signage explaining what is being measured and how to opt out. Purple ships templates and venue-signage assets for each. The compliance posture is part of the product, not an afterthought.
How to evaluate a WiFi analytics platform
An eight-item checklist for procurement, operations, and the data team.
A platform that does not correct for randomised MACs is not measuring footfall in 2026. Ask for the methodology and the validation against camera ground truth.
You need the anonymous, whole-venue mode and the consented, identified mode. Platforms that only do one of them aren't enough.
Zone definitions should be edited in the dashboard, not by re-pulling cable. Coverage areas, anchor stores, departments.
Multi-site operators need normalised KPIs across sites of different size and traffic profile. Raw numbers do not work.
Hourly batch to S3 / BigQuery / Snowflake. Native Looker / Tableau connectors. The data should land where your analysts already work.
The platform should hand you the privacy paperwork and the venue signage you need. Building it from scratch slows deployment by weeks.
Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet. The analytics layer should outlive the AP refresh.
Configurable retention by data class. Identifiable data on the shortest defensible schedule. Aggregate data on whatever your reporting needs.
Frequently asked questions
What is WiFi analytics?
+
WiFi analytics is the practice of using a venue's existing wireless network as a sensor for footfall, dwell time, and customer movement. Two modes: presence analytics (anonymous, sensor-based, MAC-randomisation-affected) and engagement analytics (identified, captive-portal-based, opted-in). Most operators run both, with each answering a different question.
How accurate is WiFi footfall counting?
+
Modern WiFi analytics with statistical correction for MAC randomisation runs at ±3-7% versus camera-based ground truth in retail environments. The accuracy is good enough for like-for-like comparison, trend tracking, and benchmarking; it is not good enough for cash-register reconciliation. The number you report should be the corrected figure with the confidence interval, not the raw probe count.
Has MAC randomisation broken WiFi analytics?
+
It changed it. iOS 14+, Android 10+, Windows 11, and macOS Sonoma randomise the MAC address presented in probe requests before association. Naive counting that treated each unique MAC as a unique device is now wrong. Statistical correction models, plus opted-in captive-portal identification for engagement analytics, are how modern platforms maintain accuracy. The platforms that ignored the change have lost accuracy; the ones that adapted have not.
What is the difference between presence and engagement analytics?
+
Presence analytics counts devices that are physically present but not authenticated; it measures footfall and dwell anonymously and is CCPA-defensible under legitimate interest with a DPIA. Engagement analytics measures behavior for visitors who signed in to the captive portal and gave consent; it ties visits to identity, supports segmentation, and runs under explicit consent. Most venues need both.
Is WiFi analytics CCPA-compliant?
+
Yes, with proper design. For presence analytics, hash the MAC client-side with rotation, document a legitimate-interest assessment, complete a DPIA, and post visible signage. For engagement analytics, run on explicit consent at the captive portal. the FTC and state attorneys general and the EU's CNIL have both issued positive guidance on WiFi analytics where these conditions are met. We have a full compliance playbook linked from this pillar.
Is WiFi or camera better for people counting?
+
Different jobs. Cameras with computer vision are more accurate at single-doorway counting (95%+ vs ground truth) but cost more, see only their field of view, and raise stronger privacy concerns. WiFi covers the whole venue cheaply, supports dwell and zone-to-zone analysis natively, and identifies returning visitors statistically. Most large-format retail and venue operators run both: cameras at the door for accuracy, WiFi inside for coverage.
What sort of dwell time should I expect?
+
Median dwell across Purple's dataset: 9-14 minutes in QSR, 35-55 minutes in casual dining, 18-32 minutes in apparel retail, 55-95 minutes in shopping malls, 75-130 minutes in airports air-side. Useful as benchmarks; the more useful measure is your own dwell trend month-on-month against same-store comparable.
Can WiFi analytics track customer journeys?
+
Within a venue, yes. Zone-to-zone transitions, time-in-zone, common paths, and drop-off points are all measurable. Across venues of the same brand, it depends on whether the visitor authenticated (engagement) or not (presence); presence-only journeys across sites are very weak signal once MAC randomisation is accounted for.
Does WiFi analytics work for office occupancy?
+
Yes. The same infrastructure that authenticates staff devices reports utilisation by floor, by day-of-week, and by hour-of-day. Integration with workplace booking systems (Robin, Envoy, Microsoft Places) is a common pattern. Office occupancy is one of the higher-confidence use cases because the population is largely authenticated and the device count is more stable than retail footfall.
How does this integrate with my existing BI stack?
+
Direct API access, hourly batch export to S3 / BigQuery / Snowflake, native Looker and Tableau connectors, and webhook event streaming. The data model is documented and stable. Most large operators land WiFi data into the same warehouse as POS and loyalty, then build reporting in their own tool of choice.