WiFi Presence Analytics Explained: Probe Requests to Insights
Key Takeaways: WiFi presence analytics measures foot traffic, dwell time, and zone occupancy by detecting wireless signals from devices in and around a venue — including devices that never connect to the network. The technology relies on probe request detection, RADIUS session accounting, and signal strength analysis. MAC address randomization (default on all modern devices since 2020) has fundamentally changed the accuracy model — presence analytics now estimates visitor counts using statistical methods rather than tracking individual devices. Combining presence analytics with captive portal authentication creates a two-layer intelligence system: aggregate traffic patterns from presence data, individual guest profiles from portal data.
Every smartphone continuously broadcasts wireless signals. When WiFi is enabled — which it is on 94% of smartphones in public spaces according to a 2025 Cisco study — the device sends probe requests searching for known networks. These signals are detectable by any access point within range, whether or not the device connects.
WiFi presence analytics captures and processes these signals to answer questions that no other affordable sensor technology can: How many people are in the venue right now? How long do they stay? Which zones are busiest? What percentage of passersby actually enter? How does foot traffic correlate with weather, events, or marketing campaigns?
For resellers, presence analytics transforms a WiFi deployment from "we capture emails" to "we measure everything that happens in your physical space." This guide explains the technology from probe request to business insight.
How probe request detection works
The probe request mechanism
When a WiFi-enabled device is not connected to a network, it periodically broadcasts probe request frames. These are 802.11 management frames that contain:
- •Source MAC address — the device's hardware (or randomized) MAC
- •Supported rates — the device's WiFi capabilities
- •SSID list (sometimes) — networks the device has previously connected to
- •Information elements — additional device capability descriptors
Probe requests serve a functional purpose: they help the device discover available networks. But they also serve as a passive sensor signal. Any access point or wireless sensor within range can receive and log these frames.
Detection range
The detection range for probe requests depends on the transmit power of the device and the sensitivity of the receiving access point. Typical detection ranges:
- •Indoor: 20–40 meters (65–130 feet) through walls and obstacles
- •Outdoor (line of sight): 50–100 meters (165–330 feet)
- •High-gain antenna: 100–200 meters (330–660 feet)
According to the IEEE 802.11 standard, probe requests are transmitted at the highest power level the device supports — typically 15–20 dBm for smartphones. This means probe requests are detectable at greater distances than normal data traffic.
Detection frequency
Modern smartphones send probe requests every 15–60 seconds when the screen is on and WiFi is not connected. When the screen is off, the frequency drops to every 2–5 minutes (iOS) or 5–15 minutes (Android, depending on manufacturer power optimization). According to Apple's 2025 Platform Security documentation, iOS devices send probe requests approximately every 20 seconds when the device is active and approximately every 120 seconds in standby.
The MAC randomization challenge
What changed
Prior to iOS 14 (2020) and Android 10 (2019), devices used their real hardware MAC address in probe requests. This made presence analytics straightforward: detect a MAC at 10:00, detect the same MAC at 10:45 — the device (and by inference, the person) was present for 45 minutes.
MAC address randomization changed this fundamentally. Modern devices generate random MAC addresses for probe requests. The randomized MAC changes periodically (Apple randomizes every 20 minutes during active scanning, according to Apple's 2025 privacy documentation). A single device may generate dozens of different MAC addresses during a one-hour visit.
Impact on analytics
Without mitigation, MAC randomization inflates visitor counts (one device appears as many) and makes dwell time calculation impossible (you cannot correlate the 10:00 detection with the 10:45 detection if the MAC changed at 10:20).
According to a 2025 study published in IEEE Transactions on Mobile Computing, naive MAC-based counting overestimates unique visitors by 3.7x to 6.2x in environments with MAC randomization.
Mitigation strategies
Modern presence analytics platforms use multiple approaches to restore accuracy:
Statistical modeling: Rather than counting unique MACs, the system applies statistical models that estimate unique visitors from the observed distribution of randomized MACs. Known randomization patterns (Apple devices randomize differently than Samsung devices) inform the model. Calibration data from venues with known foot traffic counts (door counters, ticket sales) validates the model accuracy.
Behavioral fingerprinting: Even with randomized MACs, probe request frames contain device capability information (supported rates, HT capabilities, VHT capabilities) that create a partial fingerprint. Combined with signal strength patterns and temporal clustering, this enables approximate device grouping.
Connected device correlation: Devices that authenticate through the captive portal provide a verified identity linked to a session. Presence analytics uses the ratio of connected-to-detected devices as a calibration factor. If 100 devices are detected and 30 authenticate, the platform applies a 3.3:1 ratio for footfall estimation.
Cisco Meraki CMX approach: Meraki's Connected Mobile Experiences (CMX) API uses a combination of probe request analysis, connected client data, and Bluetooth Low Energy (BLE) scanning to produce visitor analytics. Meraki's Location Analytics dashboard reports three visitor categories: Passersby (detected but never connected), Visitors (entered the venue area), and Connected (authenticated).
From raw signals to metrics
Footfall counting
Footfall is the count of unique individuals present in or near the venue during a given time period.
Raw data: Probe request detections with timestamps and signal strength.
Processing: The analytics engine groups probe requests by time window (typically 5-minute bins), applies MAC randomization deduplication, applies the statistical model to estimate unique individuals, and classifies each individual as Passersby (detected at low signal strength, not entering) or Visitor (detected at high signal strength or across multiple APs, likely inside the venue).
Output: Hourly and daily footfall counts with breakdowns by visitor type.
According to a 2025 RetailNext benchmark study, WiFi-based footfall counting achieves 85–92% accuracy compared to calibrated video counting systems when properly configured and calibrated.
Dwell time calculation
Dwell time measures how long a visitor stays in the venue.
For connected guests: Dwell time is precisely calculated from RADIUS accounting data — the difference between Acct-Status-Type: Start and Acct-Status-Type: Stop, recorded in seconds in the Acct-Session-Time field.
For unconnected visitors (presence only): Dwell time is estimated from the time span between first and last probe request detection within a visit session. A visit session ends when no probe requests from the device cluster are detected for a gap threshold (typically 15–30 minutes).
Output: Average dwell time, dwell time distribution (what percentage of visitors stay 0–15 min, 15–30 min, 30–60 min, 60+ min), and dwell time trends over time.
Zone heatmaps
In multi-AP venues, zone heatmaps show which areas of the venue attract the most traffic and longest dwell times.
Raw data: AP-level probe request counts and session data. Each AP covers a physical zone of the venue.
Processing: The system maps each AP to a physical zone (configured during deployment). Visitor detections are attributed to the zone served by the detecting AP. When a device is detected by multiple APs simultaneously, the strongest signal determines the primary zone.
Output: A spatial map with color-coded zones showing relative traffic density and average dwell time per zone. This data helps venue operators understand traffic flow patterns: where do guests congregate? Which areas are underutilized? Does moving a product display change zone traffic?
Visit frequency and return rate
For authenticated guests: Visit frequency is precisely tracked using the guest's profile identity. Each captive portal authentication creates a timestamped visit record. The analytics engine computes visits per week/month and identifies patterns (daily commuter, weekly regular, monthly occasional).
For unauthenticated visitors: Return detection relies on device fingerprinting and behavioral patterns, which are imprecise due to MAC randomization. Return rate for unauthenticated visitors is an estimate, not an exact count.
Output: Return rate percentage (what percentage of visitors return within 7/30/90 days), visit frequency distribution, and cohort retention curves.
Hardware requirements for presence analytics
Standard access points
Most enterprise-grade access points can log probe requests. However, the AP's primary function is serving connected clients, and probe request logging competes for radio time and processing resources.
Cisco Meraki, Aruba, and Ruckus access points support presence analytics through their respective cloud management platforms. The presence data is exposed through APIs (Meraki CMX, Aruba Central Analytics, Ruckus SmartCell Insight).
Dedicated sensors
For more accurate presence analytics without impacting WiFi performance, some deployments use dedicated wireless sensors. These devices are optimized for passive signal detection — they do not serve WiFi clients and can dedicate 100% of radio time to scanning.
Dedicated sensors are typically justified in high-value analytics deployments (shopping malls, airports, stadiums) where precision matters and the cost of additional hardware is proportional to the venue's scale.
MyWiFi presence analytics
MyWiFi's Pro plan and above include presence analytics powered by data from the connected access points. The platform's analytics dashboard displays footfall trends, connected vs. detected ratios, dwell time distributions, and zone heatmaps for venues with multiple APs.
For venues with Cisco Meraki hardware, MyWiFi integrates with the CMX API to ingest enhanced presence data including Bluetooth-based proximity metrics.
Presence analytics use cases for resellers
Retail: Measuring marketing campaign impact
A retail client runs a weekend promotion. Presence analytics measures the change in foot traffic compared to the previous weekend, the change in average dwell time (are people browsing longer?), and the connected-to-detected ratio (did the promotion drive more captive portal sign-ups?).
According to a 2025 International Council of Shopping Centers (ICSC) report, retailers using foot traffic analytics to measure campaign effectiveness see 23% higher marketing ROI because they can attribute physical visits to specific campaigns.
Hospitality: Optimizing staffing
A hotel client uses dwell time data from lobby, restaurant, pool, and gym zones to optimize staff scheduling. If the pool zone shows peak occupancy between 11 AM and 2 PM, poolside food and beverage staff should be scheduled accordingly.
Multi-location: Comparative benchmarking
A reseller managing 25 restaurant locations for a franchise client uses presence analytics to benchmark locations against each other: which locations have the highest foot traffic conversion (passersby to visitors), which have the longest average dwell time, and which have the highest return rates.
Real estate: Lease negotiation support
A shopping mall operator uses aggregate foot traffic data to justify lease rates. Zones with higher foot traffic command premium rents. The presence analytics data provides objective evidence.
Privacy and compliance
Presence analytics operates in a different privacy category than captive portal data capture. Probe request detection is passive — no consent is obtained from the device owner because no interaction occurs.
GDPR position
Under GDPR, whether probe request data constitutes personal data depends on whether the data can identify an individual. Randomized MAC addresses that change every 20 minutes, processed through statistical models that output aggregate counts, are generally considered anonymized data that does not require consent.
However, if the platform attempts to re-identify individuals (by correlating presence data with authenticated portal profiles), the combined data set is personal data subject to GDPR. The safest GDPR approach: keep aggregate presence analytics (footfall counts, average dwell time) separate from individual guest profiles.
The European Data Protection Board's 2024 guidance on WiFi tracking explicitly states that aggregate, anonymized footfall analytics do not require consent, but individual tracking (following a specific device across locations or time periods) does.
ePrivacy considerations
The EU ePrivacy Directive (and the pending ePrivacy Regulation) addresses the processing of traffic and location data from electronic communications. WiFi probe requests may fall under this scope. The safest position: process probe request data only in aggregate, never attempt individual re-identification, and disclose the use of WiFi analytics in the venue's privacy notice.
For detailed compliance guidance, see our consent management guide.
The future of presence analytics
Three trends are shaping the next generation of WiFi presence analytics:
Ultra-Wideband (UWB): Apple's U1/U2 chips and equivalent Android hardware enable centimeter-level positioning. UWB-based presence analytics will provide indoor positioning accuracy that WiFi probe requests cannot match. However, UWB requires purpose-built infrastructure and is years away from broad venue deployment.
Wi-Fi 6E/7 and 6 GHz: The 6 GHz band introduces new probe request behavior. According to the Wi-Fi Alliance's 2025 technical specification, devices probing on 6 GHz send Reduced Neighbor Reports that contain less identifying information. Presence analytics systems must adapt to extract signal from these new frame types.
AI-powered estimation: Machine learning models trained on calibrated venues are improving the accuracy of visitor count estimation from randomized probe data. A 2025 Google Research paper demonstrated a neural network approach that achieved 94% accuracy in unique visitor counting despite full MAC randomization, compared to 85% for traditional statistical methods.
FAQ
How accurate is WiFi presence analytics with MAC randomization? With proper calibration and statistical modeling, WiFi-based footfall counting achieves 85–92% accuracy compared to video counting systems. Without calibration, accuracy drops to 40–60% due to MAC randomization inflation.
Does presence analytics work if guests do not connect to WiFi? Yes. Presence analytics detects probe requests from all WiFi-enabled devices in range, whether or not they connect. The connected/detected ratio in typical venues ranges from 1:3 to 1:10.
What is the difference between presence analytics and portal analytics? Presence analytics measures aggregate traffic patterns from all devices (connected and unconnected). Portal analytics measures individual guest behavior for authenticated users. Combining both creates a complete picture: presence data tells you the total audience, portal data tells you who the identified audience is.
Can presence analytics track individual customers across visits? With MAC randomization, individual tracking of unauthenticated visitors is unreliable. Authenticated guests (who logged in through the captive portal) can be precisely tracked across visits. The captive portal authentication is the reliable identity layer.
Does presence analytics require special hardware? Standard enterprise access points from Cisco Meraki, Aruba, Ubiquiti, and Ruckus support probe request detection. Dedicated sensors improve accuracy but are not required for most deployments. MyWiFi's presence analytics works with existing supported hardware.
Is WiFi presence analytics legal? Aggregate, anonymized presence analytics (footfall counts, average dwell time) is generally permissible under GDPR and equivalent regulations. Individual device tracking requires consent. The safest approach is aggregate-only processing with venue-level privacy notices. Consult local data protection guidance for jurisdiction-specific requirements.