Skip to main content

What Is WiFi Analytics? A Complete Guide

This complete technical guide explains how WiFi analytics transforms standard network infrastructure into a business intelligence engine, covering data capture mechanisms (footfall, dwell time, device type, repeat visits), architectural considerations, and measurable ROI. It is designed for IT managers, network architects, and venue operations directors who need to evaluate and deploy WiFi analytics in enterprise environments.

📖 7 min read📝 1,518 words🔧 2 examples3 questions📚 10 key terms

🎧 Listen to this Guide

View Transcript
Welcome to this executive briefing from Purple. I'm your host, and today we're dissecting WiFi Analytics — what it is, how it works under the hood, and most importantly, how to transition your wireless network from a cost centre into a strategic business asset. Whether you're an IT director, a network architect, or a venue operations lead, this briefing is designed to give you the clarity you need to make a decision or start a deployment this quarter. Let's start with the context. For years, IT teams have viewed Guest WiFi as a utility — something you provide because visitors expect it, and something you budget for reluctantly. But modern enterprise platforms like Purple fundamentally change that paradigm. WiFi analytics is the process of capturing telemetry data from devices interacting with your network and turning that raw data into actionable intelligence: footfall counts, dwell time, spatial flow, device demographics, and repeat visit patterns. The key insight is this: you are almost certainly already sitting on top of the infrastructure needed to generate this intelligence. The access points you've already deployed are capable of far more than routing traffic. The question is whether you have the right analytics layer on top of them. So, let's get into the technical detail. How does the data capture actually work? It breaks down into two distinct mechanisms, and understanding the difference between them is critical to designing your deployment correctly. The first mechanism is unauthenticated presence analytics. Even before a user connects to your network — even before they open the settings menu on their phone — their device is constantly broadcasting what are called probe requests. These are short 802.11 management frames that a client device sends out to discover available networks in its vicinity. Your access points hear these probe requests. By measuring the Received Signal Strength Indicator — the RSSI — of those probes across multiple access points simultaneously, the analytics engine can triangulate the approximate physical location of that device. This is the foundation of presence analytics. It gives you your baseline metrics: total footfall, how many people walked past your store versus how many entered, and general dwell time within defined zones. However, and this is important, presence analytics has a significant limitation in 2026: MAC address randomisation. Modern operating systems — iOS 14 and later, Android 10 and later — now rotate the device's hardware address on a per-network basis, and in some cases even more frequently. This means you cannot reliably track a returning visitor using unauthenticated probe data alone. A device that visited your venue last Tuesday will appear as an entirely new, unknown device when it returns this Tuesday, because its MAC address has changed. This brings us to the second mechanism: authenticated analytics via the captive portal. This is where the real intelligence is generated. When a user actively connects to your Guest WiFi network and authenticates — whether through a social login, an email address, or a phone number — you bridge the gap between the anonymous, rotating hardware address and a persistent, known customer profile. You are now capturing first-party data with explicit consent. This is the data that marketing teams can act on: who is visiting, how often, what time of day, how long they stay, and which zones they move through. From an architectural standpoint, the beauty of a platform like Purple is that it functions as an overlay on your existing infrastructure. Whether you are running Cisco, Aruba, Meraki, Ruckus, or any other major vendor, the edge hardware — your wireless LAN controllers and access points — forwards telemetry data via API or syslog to the cloud-based analytics engine. You do not need to replace your hardware. You are simply extracting more value from the investment you have already made. The data pipeline works like this. The access points capture probe request data and connection events. The WLAN controller aggregates this and forwards it to the Purple platform. Purple's analytics engine normalises the data, applies spatial mapping algorithms against your uploaded floor plans, and surfaces the results in the analytics dashboard. Simultaneously, when a user authenticates through the captive portal, their profile data is stored and can be pushed via webhook to your CRM or marketing automation platform — Salesforce, HubSpot, Marketo, whatever you're running. Now let's talk about implementation. If you're an IT director planning a deployment, I want to highlight the three most common pitfalls I see. The first pitfall is network design. If you designed your wireless network purely for coverage — placing access points in the centre of rooms to maximise signal propagation — your location analytics accuracy will be poor. For accurate triangulation, you need density, and specifically, you need access points placed around the perimeter of your zones. Think about it geometrically: without perimeter APs, the system cannot determine whether a device is near the edge of a room or in the adjacent corridor. If accurate indoor positioning is a requirement, you need to revisit your AP placement strategy before you go live. The second pitfall is captive portal friction. The captive portal is your primary instrument for converting anonymous presence data into authenticated customer profiles. If the portal is slow, complex, or asks for too much information upfront, visitors will abandon it. Keep the authentication flow to two steps maximum. Offer social login options. Be transparent about what data you're collecting and why. A frictionless portal experience directly translates to higher data capture rates. The third pitfall is data siloing. This is the most common and the most damaging. I have seen organisations deploy a WiFi analytics platform, generate genuinely valuable data, and then leave it sitting in an IT dashboard that the operations team never looks at. The ROI of WiFi analytics is only realised when the data flows into the hands of the people who can act on it. Build automated reports for your operations director. Configure API integrations to push customer data into the CRM. Set up alerts that trigger when dwell time in a specific zone exceeds a threshold. Let me give you two concrete implementation scenarios to illustrate the business impact. Scenario one: a four-hundred-room resort hotel. The General Manager wants to reduce congestion at the check-in desks during peak hours — typically three to five in the afternoon — and increase revenue at the lobby bar. The IT team deploys high-density APs in the lobby and maps specific zones in the analytics platform: the check-in queue zone, the lobby seating zone, and the bar area. They configure two triggers. First, if dwell time in the check-in queue zone exceeds fifteen minutes for more than twenty devices simultaneously, an automated SMS alert is sent to the Duty Manager to open additional desks. Second, if a device dwells in the lobby seating zone for more than ten minutes, a personalised notification is pushed offering a ten percent discount at the bar. The result is a direct, measurable link between WiFi analytics and both operational efficiency and ancillary revenue. Scenario two: a large retail chain. The Head of Merchandising wants to understand why a specific high-traffic aisle is not generating proportional sales despite heavy footfall. The analytics team defines zones for the main walkway and the target aisle. They analyse two metrics: the spatial conversion rate — how many devices move from the walkway into the aisle — and the dwell time within the aisle. If conversion is high but dwell time is low, visitors are entering the aisle but leaving quickly, suggesting the product placement is confusing or the signage is poor. If conversion is low despite high walkway traffic, the end-cap display needs redesigning to attract attention. This is the kind of granular, evidence-based insight that was previously only available through expensive manual observation studies. Now for a rapid-fire Q&A based on the questions I hear most frequently from clients. Question one: Does WiFi analytics violate GDPR? The answer is no, provided your captive portal clearly and prominently outlines the data usage policy and secures explicit, auditable opt-in consent before capturing any personal data. The key word is explicit. Pre-ticked boxes and buried consent language are not compliant. Purple's platform includes built-in consent management tools designed specifically for GDPR and CCPA compliance. Question two: Can we use WiFi analytics for asset tracking — for example, locating wheelchairs or medical equipment in a hospital? The short answer is: not reliably with standard WiFi analytics. Standard presence analytics is designed to track active user devices that are regularly broadcasting probe requests. Medical equipment may enter sleep states and stop broadcasting, making it invisible to the network. Additionally, standard RSSI triangulation typically provides five to ten metre accuracy, which is insufficient for locating equipment in adjacent rooms. For precise asset tracking, a dedicated Real-Time Location System using active RFID or BLE beacons is the appropriate solution. Question three: How does MAC randomisation affect our repeat visitor metrics? It means that any repeat visitor metric derived solely from unauthenticated presence data is likely understated. The fix is to prioritise authenticated sessions. When a user logs in through the captive portal, their profile is tied to their email address or social identity, not their MAC address. Purple's platform handles this automatically, stitching together sessions from the same authenticated user regardless of MAC address changes. To summarise the key takeaways from this briefing. WiFi analytics provides deep, real-time visibility into your physical spaces using infrastructure you have already deployed. Presence analytics gives you footfall and spatial flow from unauthenticated devices. Authenticated analytics via the captive portal gives you rich first-party customer profiles. MAC randomisation makes authenticated data essential for repeat visitor tracking. AP placement must be designed for density and perimeter coverage if location accuracy is a requirement. And critically, the ROI is only realised when data flows out of the IT dashboard and into the hands of operations and marketing teams. Thank you for listening to this briefing. For the complete technical reference guide, including architecture diagrams, implementation checklists, and industry-specific use cases, visit purple dot ai. If you're evaluating WiFi analytics platforms, I'd encourage you to look at how Purple compares to alternatives — we've published a detailed comparison guide on the website covering the key decision criteria. Until next time.

header_image.png

Executive Summary

For modern enterprise venues, providing Guest WiFi is no longer simply a cost centre or an expected utility — it is a critical infrastructure layer for business intelligence. WiFi Analytics is the process of capturing, processing, and visualising data generated by devices connecting to, or probing, a wireless network. For IT managers, network architects, and venue operations directors, deploying a robust analytics solution bridges the gap between IT expenditure and measurable business value.

This guide details the technical architecture of WiFi data collection, the specific metrics captured — including footfall, dwell time, device type, and repeat visits — and the integration points necessary to turn raw network telemetry into actionable insights. By leveraging existing infrastructure, whether deploying in Retail , Healthcare , Hospitality , or Transport , organisations can achieve deep visibility into physical spaces without deploying costly overlay sensor networks.


Technical Deep-Dive: How WiFi Analytics Works

At its core, WiFi analytics relies on the fundamental behaviour of 802.11 client devices. Even before a user authenticates to a network, their device broadcasts probe requests to discover available access points (APs). These management frames, combined with the data generated during authenticated sessions, form the two primary data streams that a WiFi analytics platform processes.

The Data Capture Mechanisms

Presence Analytics (Unauthenticated): When a smartphone has WiFi enabled, it periodically sends probe requests containing its MAC address and signal strength (RSSI). Access points detect these probes. By triangulating the RSSI across multiple APs, the system calculates the device's approximate location within a venue. This provides baseline footfall and conversion metrics — passers-by versus active visitors — without requiring any user interaction.

Authenticated Analytics: When a user actively connects to the captive portal, the analytics engine captures rich first-party data. This typically includes demographic information, contact details, and CRM identifiers, bridging the gap between an anonymous MAC address and a known, persistent customer profile. This is the data layer that enables personalised marketing and loyalty programmes.

Location Services (RTLS): Advanced deployments utilise techniques such as Time Difference of Arrival (TDOA) or Fine Timing Measurement (802.11mc/802.11az) to provide highly accurate indoor positioning, often augmented by Bluetooth Low Energy (BLE) beacons. For a detailed breakdown of these positioning technologies, see our Indoor Positioning System: UWB, BLE, & WiFi Guide .

data_capture_overview.png

Architecture and Integration

The architecture typically involves edge hardware — wireless LAN controllers and APs — forwarding telemetry data via API or syslog to a cloud-based analytics engine. The platform ingests this high-velocity data stream, normalises it, and applies spatial mapping algorithms against uploaded floor plans to produce zone-level analytics.

Crucially, the system must integrate seamlessly with the existing network vendor stack. Whether you are evaluating Purple vs Cisco Spaces (DNA Spaces): When to Choose Each or deploying on Aruba, Ruckus, or Meraki, the analytics platform acts as an overlay — extracting value without requiring hardware replacement. This is a fundamental distinction from proprietary sensor-based solutions.

The data pipeline follows this flow: APs capture probe requests and connection events → the WLAN controller aggregates and forwards telemetry → the analytics engine normalises and maps the data → the dashboard surfaces insights to operations and marketing teams → API webhooks push authenticated user profiles to CRM and marketing automation platforms.

Standards and Compliance Considerations

Deployments must account for several regulatory and technical standards:

Standard Relevance
IEEE 802.11ax (Wi-Fi 6/6E) Provides the OFDMA and BSS Colouring features that improve AP density and location accuracy
IEEE 802.11mc / 802.11az Fine Timing Measurement (FTM) enables sub-metre ranging accuracy for RTLS deployments
WPA3-Enterprise Mandatory for deployments handling sensitive data; provides 192-bit security mode
GDPR / UK GDPR Requires explicit, auditable consent before capturing personal data via captive portal
PCI DSS Guest WiFi traffic must be isolated from payment card networks via dedicated VLANs
CCPA Applies to deployments serving California residents; requires opt-out mechanisms

Implementation Guide

Deploying a WiFi analytics solution requires careful coordination between network engineering and business stakeholders. The following steps represent a vendor-neutral deployment framework.

Step 1 — Network Readiness Assessment: Evaluate current AP density and placement against location analytics requirements. Standard coverage design (APs centred in rooms) is insufficient for accurate triangulation. Perimeter AP placement is essential. Conduct an active site survey using tools such as Ekahau or iBwave to identify RF dead zones and interference sources.

Step 2 — Floor Plan Mapping: Upload accurate, scaled floor plans to the analytics platform. Define zones that align with business objectives — for example, 'Checkout Area', 'Promotional End-Cap Zone', or 'Lobby'. Inaccurate floor plan scaling is one of the most common causes of poor location data quality.

Step 3 — Captive Portal Configuration: Design the authentication flow to balance user experience with data acquisition. Implement social login options (Google, Apple ID) to reduce friction. Ensure the portal is fully responsive across device types. Purple can act as an identity provider for OpenRoaming under the Connect licence, enabling seamless onboarding for returning users without repeated portal interactions.

Step 4 — Consent and Privacy Framework: Implement GDPR-compliant consent capture. Consent must be granular (separate opt-ins for analytics, marketing, and third-party sharing), explicit (no pre-ticked boxes), and auditable (timestamped records stored per user profile).

Step 5 — Data Integration: Configure webhooks and REST API integrations to push authenticated user data into CRM platforms (Salesforce, HubSpot) and marketing automation tools (Marketo, Klaviyo). This step is where the IT deployment directly enables marketing ROI and is frequently deprioritised — do not let it be.

Step 6 — Alerting and Reporting: Configure operational alerts (e.g., dwell time thresholds triggering staff notifications) and automated reports for non-technical stakeholders. Data that remains in an IT dashboard generates no business value.


Best Practices

MAC Randomisation Mitigation: Modern operating systems (iOS 14+, Android 10+) use per-network randomised MAC addresses. Analytics platforms must rely on authenticated sessions and behavioural stitching algorithms rather than persistent hardware addresses for repeat visitor tracking. Prioritise captive portal authentication rates as a KPI.

AP Density for Location Accuracy: A minimum of three APs with overlapping coverage is required for basic triangulation. For sub-3-metre accuracy, deploy APs at 8–10 metre intervals in high-value zones. For sub-metre RTLS, supplement with BLE beacons or deploy 802.11az-capable hardware.

Network Segmentation: Isolate Guest WiFi traffic from corporate and payment networks using dedicated VLANs, firewall ACLs, and DNS filtering. This is non-negotiable for PCI DSS compliance and significantly reduces the attack surface.

Data Governance: Establish a clear data retention policy. Most analytics use cases are well-served by 13 months of data (enabling year-on-year comparison). Longer retention periods increase compliance risk and storage costs without proportional analytical benefit.


Troubleshooting & Risk Mitigation

Inaccurate Location Data: Most commonly caused by insufficient AP density, incorrect floor plan scaling, or RF interference from adjacent networks. Validate AP placement against the site survey, verify floor plan scale in the analytics platform, and use the spectrum analysis tools in your WLAN controller to identify interference sources.

Low Authentication Rates: If visitors are not completing the captive portal, audit the user journey. Measure drop-off at each step. Common causes include slow portal load times (optimise for mobile on 3G/4G fallback connections), excessive data fields, and unclear value propositions. A/B test the portal design.

Data Silos: The most commercially damaging failure mode. Proactively build automated reports for operations and marketing teams. Establish a cross-functional 'WiFi Data' working group with representatives from IT, marketing, and operations to review insights monthly.

Vendor Lock-In: Avoid analytics platforms that require proprietary hardware. Ensure the platform supports your existing AP vendor via standard APIs and can export data in open formats (CSV, JSON) to prevent dependency on a single vendor's ecosystem.


ROI & Business Impact

The ultimate measure of a WiFi analytics deployment is its contribution to business outcomes. The following framework maps analytics capabilities to measurable KPIs.

use_cases_by_industry.png

Analytics Capability Business KPI Typical Improvement
Footfall counting Visitor volume tracking Replaces manual counting; 99%+ accuracy
Dwell time by zone Queue management, staff allocation 15–25% reduction in peak wait times
Repeat visit rate Customer loyalty measurement Baseline for loyalty programme ROI
Spatial conversion rate Window-to-door conversion Informs exterior display investment
Authenticated profiles CRM enrichment, campaign targeting 3–5x improvement in email campaign relevance
Zone flow analysis Layout optimisation Measurable uplift in secondary spend

For Hospitality operators, WiFi analytics enables repeat guest recognition, lobby congestion management, and F&B upsell triggers. For Retail chains, it provides heatmap-driven layout optimisation and campaign attribution. For transport hubs and public sector venues, it delivers service utilisation data and crowd flow management. For a detailed look at connected venue applications, see our Internet of Things Architecture: A Complete Guide .

By treating the WiFi network as a strategic data asset rather than a utility, IT leaders transition from cost-centre managers to business enablers — delivering concrete ROI through enhanced operational efficiency, improved customer engagement, and evidence-based decision-making.

Key Terms & Definitions

Probe Request

An 802.11 management frame broadcast by a client device to discover available wireless networks in its vicinity, containing the device's MAC address and supported data rates.

The foundational mechanism for unauthenticated presence analytics. Access points capture these frames to detect and locate devices before any user interaction occurs.

RSSI (Received Signal Strength Indicator)

A measurement of the power level of a received radio signal, expressed in dBm (typically ranging from 0 to -100 dBm).

Analytics platforms use RSSI readings from multiple APs simultaneously to triangulate a device's physical location. Lower (more negative) values indicate greater distance from the AP.

MAC Address Randomisation

A privacy feature in modern operating systems (iOS 14+, Android 10+) that assigns a randomised hardware address to a device on a per-network basis, replacing the device's permanent MAC address.

Significantly limits the reliability of unauthenticated presence analytics for repeat visitor tracking, making captive portal authentication essential for building persistent customer profiles.

Captive Portal

A web-based authentication interface that intercepts a user's HTTP/HTTPS traffic and redirects them to a login or registration page before granting network access.

The primary mechanism for capturing first-party customer data and securing GDPR-compliant consent. Portal design and friction level directly determine data capture rates.

Dwell Time

The duration a specific authenticated or detected device remains within a defined physical zone, measured from first detection to last detection within that zone.

A critical operational metric used to identify queue congestion, measure engagement with promotional displays, and trigger time-based marketing automations.

Footfall

The total count of unique devices detected within a defined venue or zone over a specified time period.

Provides the baseline traffic metric analogous to website sessions. Used to measure overall venue performance, compare locations, and calculate spatial conversion rates.

Spatial Conversion Rate

The percentage of devices detected in an outer zone (e.g., a street or main walkway) that subsequently enter an inner zone (e.g., a store or aisle).

Used by retail operators to evaluate the effectiveness of exterior displays and entrance signage. A low conversion rate despite high footfall indicates an attraction problem at the threshold.

OpenRoaming

A Wireless Broadband Alliance (WBA) federation standard that enables seamless, secure Wi-Fi onboarding across participating networks without requiring repeated captive portal interactions.

Purple can act as an identity provider for OpenRoaming under the Connect licence, enabling venues to offer seamless connectivity while retaining the ability to capture analytics data from returning users.

RTLS (Real-Time Location System)

A system that uses radio frequency technologies (WiFi, BLE, UWB, or RFID) to determine and track the real-time location of objects or people within a defined space.

Relevant when sub-3-metre location accuracy is required — for example, asset tracking in healthcare or turn-by-turn indoor navigation in large venues. Standard WiFi RSSI triangulation is typically insufficient for these use cases.

TDOA (Time Difference of Arrival)

A location technique that calculates position by measuring the difference in the time a signal arrives at multiple reference points (APs or anchors).

Provides significantly higher location accuracy than RSSI-based triangulation, but requires hardware support and precise clock synchronisation across APs.

Case Studies

A 400-room resort hotel wants to reduce congestion at check-in desks during peak hours (15:00–17:00) and increase revenue at the lobby bar. The IT team has a Cisco Meraki deployment with 24 APs across the ground floor.

  1. Map the lobby floor plan in the analytics platform with three distinct zones: 'Check-In Queue', 'Lobby Seating', and 'Bar Area'. Verify that at least three APs provide overlapping coverage in each zone for accurate triangulation.
  2. Configure a real-time operational alert: if the device count in the 'Check-In Queue' zone exceeds 20 simultaneously AND average dwell time exceeds 15 minutes, trigger an automated SMS to the Duty Manager via the platform's webhook integration.
  3. Configure a marketing trigger: if a device dwells in the 'Lobby Seating' zone for more than 10 minutes, push a personalised notification (via the captive portal session or email if authenticated) offering a 10% discount at the bar, valid for 30 minutes.
  4. Integrate the authenticated user profiles with the hotel PMS (Property Management System) to automatically recognise returning guests and suppress the captive portal for them, surfacing a personalised welcome message instead.
  5. Review weekly dwell time reports to identify whether the check-in queue alert is triggering at consistent times, enabling proactive staffing adjustments rather than reactive responses.
Implementation Notes: This scenario demonstrates the two-layer value of WiFi analytics: operational efficiency (queue management) and revenue generation (ancillary spend). The key architectural decision is the PMS integration in step 4, which elevates the deployment from a generic analytics tool to a guest experience platform. The 10-minute dwell trigger in step 3 is deliberately conservative — it targets guests who are already settled and receptive, rather than those still navigating the space.

A 50-store retail chain has deployed WiFi analytics across all locations. The Head of Merchandising reports that a specific promotional aisle in their flagship Manchester store generates high footfall but below-average sales per square foot. They want to understand why before rolling out the same layout to 15 other stores.

  1. Define two zones in the analytics platform for the Manchester store: 'Main Walkway' (the primary traffic artery adjacent to the aisle) and 'Promotional Aisle' (the target zone).
  2. Pull a 30-day report comparing: (a) the spatial conversion rate — the percentage of devices in the Main Walkway that subsequently enter the Promotional Aisle — and (b) the average dwell time within the Promotional Aisle for devices that do enter.
  3. Scenario A — High conversion, low dwell time: Visitors are entering the aisle but leaving quickly. This indicates the product placement or signage within the aisle is confusing or unappealing once inside. Recommendation: redesign the aisle layout and test with a 14-day A/B comparison.
  4. Scenario B — Low conversion despite high walkway traffic: Visitors are not being drawn into the aisle from the walkway. This indicates the end-cap display or entrance signage is ineffective. Recommendation: redesign the entrance display and measure conversion rate change over the following 14 days.
  5. Correlate the WiFi analytics data with POS transaction data by time-of-day to identify whether dwell time correlates with purchase probability, establishing a venue-specific 'engagement threshold' for future campaign design.
Implementation Notes: This example highlights the diagnostic power of WiFi analytics when applied to a specific business problem. The critical insight is that 'high footfall, low sales' is not a single problem — it is two distinct problems with different root causes and different solutions. The analytics data disambiguates them. The POS correlation in step 5 is the most commercially valuable output, as it establishes a data-driven link between physical engagement and revenue.

Scenario Analysis

Q1. A retail client reports that their 'Repeat Visitor' metric has dropped by 40% over the past eight months, despite sales remaining steady and no significant change in marketing activity. Their analytics deployment relies entirely on unauthenticated presence tracking. What is the most likely technical cause, and what is the recommended remediation?

💡 Hint:Consider the timeline of major mobile OS updates and their privacy features.

Show Recommended Approach

The most likely cause is the progressive adoption of MAC address randomisation across the client's customer base. iOS 14 (released September 2020) and Android 10+ introduced per-network MAC randomisation, causing returning devices to appear as new, unique visitors to presence analytics engines. As the proportion of customers running these OS versions has increased, the repeat visitor metric has degraded. The remediation is to implement a captive portal authentication layer. When users authenticate with a persistent identifier (email address, social login), the analytics platform can build a customer profile tied to that identifier rather than the rotating MAC address. This restores repeat visitor tracking accuracy and simultaneously generates first-party marketing data.

Q2. You are the network architect for a new 80,000-seat stadium. The venue operations team wants WiFi analytics to manage crowd flow through concourse areas and identify concession stand congestion in real time. The IT budget allows for 400 APs. How should you prioritise AP placement to maximise analytics accuracy, and what accuracy level can you realistically expect?

💡 Hint:Think about the geometric requirements of triangulation and the difference between coverage and analytics design principles.

Show Recommended Approach

Prioritise perimeter placement over central coverage. For each concourse zone, ensure APs are placed at the zone boundaries rather than the centre. This enables the analytics engine to accurately determine when a device crosses from one zone to another. Aim for a minimum of three APs with overlapping coverage in each defined zone, with AP spacing of 8–10 metres in high-priority areas (concession stands, entry/exit gates). With standard RSSI triangulation on 802.11ax hardware, expect 3–5 metre location accuracy in open concourse areas. For sub-3-metre accuracy at specific chokepoints (e.g., individual concession windows), supplement with BLE beacons or deploy 802.11az-capable APs at those locations.

Q3. A hospital IT director wants to use the existing WiFi network to track the location of 200 high-value mobile medical assets (infusion pumps, portable ECG monitors). They do not want to deploy any additional hardware. The analytics platform currently provides 5-metre RSSI triangulation accuracy. Is this deployment viable, and what are the key risks?

💡 Hint:Consider both the technical accuracy requirements and the behaviour of the devices being tracked.

Show Recommended Approach

This deployment is not reliably viable for two reasons. First, medical equipment frequently enters low-power or sleep states, causing the device to stop broadcasting WiFi probe requests. When a device is not actively probing, it is invisible to the presence analytics engine. This creates gaps in tracking that are unacceptable for asset management. Second, 5-metre RSSI accuracy is insufficient to determine whether an asset is in Room 4A or Room 4B in a typical hospital ward layout. The recommended alternative is a dedicated RTLS solution using active RFID tags or BLE beacons attached to the assets, which actively broadcast at regular intervals regardless of the asset's power state, and which can achieve sub-2-metre accuracy. The existing WiFi infrastructure can serve as the receiver network for BLE beacons, avoiding the need for a completely separate sensor network.