Passer au contenu principal

Comment calculer le temps de présence à l'aide de WiFi Location Analytics

Ce guide fournit une référence technique complète pour le calcul du temps de présence WiFi à l'aide de WiFi location analytics, couvrant l'architecture complète de la capture des requêtes de sondage 802.11 en passant par la trilatération basée sur le RSSI jusqu'à l'analyse des zones géorepérées. Il est destiné aux responsables informatiques, aux architectes réseau et aux directeurs des opérations de site qui doivent déployer une intelligence de localisation précise et évolutive dans les environnements de la vente au détail, de l'hôtellerie, de la santé et du secteur public. Les lecteurs obtiendront des conseils de mise en œuvre exploitables, des études de cas réelles et un cadre clair pour traduire les données spatiales brutes en résultats commerciaux mesurables.

📖 9 min de lecture📝 2,134 mots🔧 2 exemples concrets3 questions d'entraînement📚 10 définitions clés

Écouter ce guide

Voir la transcription du podcast
Welcome to the Purple Technical Briefing. I'm your host, and today we are diving deep into the mechanics of spatial intelligence. Specifically, we're looking at how to calculate dwell time using WiFi location analytics. If you're an IT director, a network architect, or managing operations for a large venue — be it a retail chain, a hospital, or a stadium — you know that understanding how people move through your space is critical. Dwell time is the foundational metric here. It's not just about knowing someone entered the building; it's about knowing they spent twelve minutes in the promotional aisle, or forty-five minutes in the triage waiting room. But getting accurate dwell time isn't as simple as just turning on a feature in your wireless controller. It requires a solid understanding of RF dynamics, network architecture, and data processing. So, let's get into the technical details. Fundamentally, calculating dwell time involves three steps: identifying a device, estimating its position, and tracking that position over time. Step one is device detection. Mobile devices are constantly sending out 802.11 probe requests to find networks. Your Access Points act as sensors, picking up these probes. The AP records the device's MAC address, a timestamp, and the Received Signal Strength Indicator — or RSSI. Now, a quick note on identification. Historically, the MAC address was a static identifier. But today, iOS and Android use MAC randomization for privacy when probing. If a device isn't connected to your network, its MAC address changes. This means passive tracking can inflate visitor counts and skew dwell times, because one device looks like multiple devices over time. To get deterministic, highly accurate data, you need the user to authenticate to your Guest WiFi. Once authenticated, you have a persistent identifier. Moving to step two: spatial estimation. How do we know where the device is? We use RSSI and trilateration. If one AP hears a device at minus sixty-five dBm, we can estimate it's roughly ten metres away. But it could be anywhere on a ten-metre circle around that AP. To get a location, we need at least three APs to hear that same probe request. This is what I call the Rule of Three. The analytics engine takes the RSSI from all three APs, calculates the estimated distances, and finds where those circles intersect. Advanced systems use weighted centroids and Kalman filters to smooth out the inevitable RF noise and multipath fading you get in complex environments — think metal shelving in a warehouse, or dense crowds in a stadium concourse. Finally, step three: the temporal calculation. Once we have a stream of location coordinates, we map them against geofenced zones you've defined in the platform. Dwell time is calculated by logging an Entry Event when the device enters the zone, and an Exit Event when it leaves. Crucially, you must configure a Dwell Threshold. If someone walks through the apparel section in ten seconds, they are a passerby, not a dweller. Setting a threshold of, say, thirty seconds filters out the noise and gives you clean engagement data. Now let's talk implementation. How do you actually deploy this successfully? First, assess your infrastructure. A network designed for basic coverage will not support accurate location analytics. You need density. You need APs positioned on the perimeter of your zones, not just down the middle of the hallway. As a rule of thumb, a device should be heard by at least three APs at any given location, with an RSSI of minus seventy-five dBm or better. If your current deployment doesn't meet that standard, you'll need to densify — particularly in the zones that matter most to your business. Second, define your zones carefully. Don't make them too small. If a zone is smaller than the accuracy tolerance of your network, devices will appear to bounce in and out, corrupting your dwell metrics. In a retail environment, a good starting point is zones of at least twenty to thirty square metres. Third, think about your data pipeline. Your wireless controller needs to forward location data to the analytics platform. This typically happens via API or secure syslog. Ensure this integration is configured correctly and that data flows in near real-time — anything over a thirty-second lag will degrade the quality of your live operational dashboards. Fourth, and this is often overlooked: calibrate regularly. The RF environment in a venue changes. New displays go up, seasonal stock changes the layout, crowds absorb signal differently than empty aisles. A site survey conducted at deployment will not remain accurate six months later. Build a calibration cadence into your operational schedule. Now, let's move to a rapid-fire Q&A based on common deployment issues I see in the field. Question one: Our location data is jumping all over the place in our warehouse. What's going on? Warehouses are RF nightmares. Metal racking causes severe signal reflection — what we call multipath fading. The signal bounces off the metal and arrives at the AP via multiple paths, distorting the RSSI reading. You likely need to densify your APs, consider directional antennas focused down specific aisles, and ensure your analytics platform has its smoothing algorithms tuned for high-interference environments. Question two: Our dwell times seem way too short, and our visitor counts are much higher than expected. You are almost certainly relying on passive data, and MAC randomization is breaking the sessions. Each time a device changes its MAC address, the platform sees it as a brand new visitor who only stays for a short time. The fix is to drive Guest WiFi authentication. When users log in, you get a persistent identifier that survives MAC randomization. Incentivise authentication — a simple splash page with a one-click social login is often enough. Question three: We've defined a zone around our checkout, but it keeps capturing people who are just walking past. This is a Dwell Threshold configuration issue. Increase your minimum dwell threshold for that zone. If your checkout queue typically takes two minutes, set the threshold to sixty or ninety seconds. Anyone who passes through in less time simply won't be counted as a checkout dweller. To summarise everything we've covered today: dwell time calculation transforms your physical space into a measurable, optimisable environment. It requires a dense AP deployment, a solid understanding of trilateration and RSSI, and smart configuration of geofences and dwell thresholds. The data you get back is genuinely powerful. It tells you which zones are performing, where bottlenecks are forming, and where your layout or staffing needs to change. When correlated with sales or operational data, it becomes one of the most actionable metrics in your entire analytics stack. For the next steps, I'd recommend starting with a focused pilot. Pick two or three high-value zones in your venue, ensure your AP density is sufficient, configure your zones and thresholds carefully, and run the pilot for four to six weeks before drawing conclusions. That gives you enough data to establish a baseline and identify meaningful trends. Thank you for joining this technical briefing from Purple. For more detailed implementation guides and to explore how Purple's hardware-agnostic analytics platform can work with your existing infrastructure, head to purple dot ai.

header_image.png

Résumé Exécutif

Pour les sites d'entreprise — des vastes surfaces de vente aux stades tentaculaires — comprendre le comportement des visiteurs n'est plus un luxe marketing ; c'est une exigence opérationnelle critique. Le temps de présence WiFi, la durée pendant laquelle un appareil reste dans une zone physique définie, sert de métrique fondamentale pour mesurer l'engagement spatial. Cependant, le calcul précis du temps de présence à l'aide de l'infrastructure sans fil existante nécessite de naviguer dans des environnements RF complexes, la randomisation MAC et des fréquences de sondage d'appareil variables.

Ce guide fournit aux professionnels informatiques seniors, aux architectes réseau et aux directeurs des opérations une référence technique définitive sur la façon de calculer le temps de présence à l'aide de WiFi location analytics. Nous explorons les mécanismes de détection des appareils, le rôle de l'indicateur de force du signal reçu (RSSI) et de la trilatération, et comment des plateformes comme Purple transforment les requêtes de sondage brutes en intelligence d'affaires exploitable. En tirant parti de votre infrastructure Guest WiFi existante, les organisations peuvent déployer des analyses évolutives sans réseaux matériels superposés coûteux. Le cas du retour sur investissement est convaincant : les sites qui mettent en œuvre l'analyse de localisation signalent constamment des améliorations mesurables des taux de conversion, de l'efficacité opérationnelle et de la satisfaction client.


Approfondissement technique : Les mécanismes du temps de présence

Le calcul du temps de présence est fondamentalement un problème de résolution spatiale et temporelle. Il nécessite d'identifier un appareil, d'estimer sa position et de suivre cette position en continu dans le temps. Chacune de ces trois étapes introduit ses propres défis techniques, et une solution robuste doit les aborder tous.

1. Détection et identification des appareils

Le processus commence par la détection passive des requêtes de sondage 802.11. Les appareils mobiles diffusent en continu ces trames de gestion pour découvrir les réseaux sans fil disponibles. Les points d'accès (AP) agissant comme des capteurs capturent ces trames, qui contiennent l'adresse MAC de l'appareil, un horodatage et la force du signal au point d'accès récepteur (RSSI).

Historiquement, l'adresse MAC fournissait un identifiant persistant au niveau matériel. Cependant, les systèmes d'exploitation mobiles modernes — iOS 14+, Android 10+ et Windows 10+ — implémentent la randomisation MAC pour améliorer la confidentialité des utilisateurs. Lorsqu'un appareil n'est pas associé à un réseau, il utilise une adresse MAC temporaire et randomisée qui tourne périodiquement. Cela remet directement en question le calcul passif du temps de présence, car un seul appareil physique peut apparaître comme plusieurs visiteurs uniques au cours d'une session.

Pour maintenir la continuité de la session pour un calcul précis du temps de présence, les plateformes d'analyse doivent employer l'une des deux stratégies suivantes. La première est le fingerprinting heuristique, qui implique l'analyse des éléments d'information (IE) au sein de la trame de requête de sondage — tels que les débits de données pris en charge, les listes de canaux et les champs spécifiques au fournisseur — pour lier de manière probabiliste les requêtes de sondage du même appareil même lorsque l'adresse MAC change. La seconde approche, et de loin la plus fiable, consiste à s'appuyer sur les sessions authentifiées. Lorsqu'un utilisateur se connecte explicitement au réseau Guest WiFi , la plateforme reçoit la véritable adresse MAC matérielle de l'appareil et peut la lier à un profil utilisateur persistant. Cette identification déterministe est la référence absolue pour des métriques de temps de présence précises et à long terme.

2. Estimation spatiale : RSSI et trilatération

Une fois qu'un appareil est détecté, le système doit déterminer sa position physique. L'approche la plus largement déployée utilise la trilatération basée sur le RSSI, une technique expliquée en détail dans le guide Les mécanismes de la navigation WiFi : trilatération et RSSI expliqués .

Le principe est simple : le RSSI diminue de manière prévisible avec la distance selon le modèle de perte de chemin en espace libre (FSPL). En mesurant la force du signal à plusieurs points d'accès (AP), le système peut estimer la distance entre l'appareil et chaque AP. Lorsque trois AP ou plus détectent la même requête de sondage, le moteur d'analyse peut calculer la position de l'appareil en trouvant l'intersection de cercles (ou de sphères dans un environnement 3D multi-étages) dont les rayons correspondent aux distances estimées de chaque AP.

dwell_time_architecture_overview.png

En pratique, les environnements RF sont loin du modèle idéalisé de l'espace libre. L'évanouissement multitrajets, causé par les réflexions du signal sur les murs, les étagères métalliques et les corps humains, introduit une variance RSSI significative. Pour atténuer cela, les moteurs d'analyse de qualité production appliquent plusieurs techniques :

Technique Objectif Gain typique
Algorithme du centroïde pondéré Attribue un poids plus élevé aux AP avec des lectures RSSI plus fortes Réduit l'erreur de position de 15 à 30 %
Filtrage de Kalman Lisse les estimations de localisation dans le temps pour éliminer le bruit transitoire Réduit la gigue dans le suivi en temps réel
Cartographie par empreinte Pré-cartographie les signatures RSSI à des emplacements connus pour l'étalonnage Améliore la précision dans les environnements RF complexes
Moyennage multi-AP Moyenne le RSSI sur plusieurs intervalles d'échantillonnage Réduit l'impact des interférences momentanées

Pour une trilatération fiable, la Règle de Trois s'applique : un appareil doit être détecté par au moins trois AP simultanément avec une force de signal de -75 dBm ou mieux. Les réseaux conçus uniquement pour la couverture — où un seul AP fournit un signal sur une grande zone — ne prendront pas en charge un calcul précisles analyses de localisation. Il s'agit d'une distinction architecturale critique qui doit être abordée avant le déploiement.

3. Calcul temporel : Définir et calculer le temps de présence

Avec un flux de coordonnées de localisation, le moteur d'analyse cartographie les positions des appareils par rapport aux zones géorepérées définies au sein de la plateforme. Une zone géorepérée est un polygone virtuel tracé sur un plan d'étage, représentant une zone physique significative telle qu'une file d'attente de caisse, un présentoir promotionnel ou un hall d'hôtel.

Le temps de présence n'est pas simplement le delta entre le premier et le dernier horodatage observé. Un calcul robuste doit tenir compte des cycles de veille des appareils, des brèves sorties de zone et du bruit inhérent aux estimations de localisation. La logique de calcul standard définit trois paramètres clés :

Événement d'entrée : La position estimée de l'appareil entre dans une zone géorepérée définie et y reste pendant une période minimale — le Seuil de présence — pour filtrer les passants. Un seuil courant pour les environnements de vente au détail est de 30 secondes ; pour les zones d'attente des établissements de santé, 60 secondes peuvent être plus appropriées.

Événement de sortie : La position de l'appareil se déplace en dehors de la limite de la zone, ou l'appareil n'est détecté par aucun AP pendant une Période de temporisation définie (généralement 3 à 5 minutes). La temporisation gère les appareils qui entrent en mode veille ou sont placés dans un sac, empêchant la terminaison prématurée de la session.

Durée de présence : Le delta entre l'horodatage de l'événement d'entrée et l'horodatage de l'événement de sortie, moins tout tampon de temporisation. C'est la métrique rapportée au tableau de bord WiFi Analytics .


Guide de mise en œuvre

Le déploiement d'une solution robuste d'analyse de localisation WiFi nécessite une planification minutieuse et un alignement entre l'architecture réseau et les objectifs commerciaux. Les étapes suivantes représentent un cadre de déploiement indépendant du fournisseur, applicable à tout environnement WLAN d'entreprise.

Étape 1 : Évaluation et densification de l'infrastructure

Réalisez une étude de site RF approfondie pour évaluer votre déploiement WLAN existant par rapport aux exigences des services de localisation. La question clé est de savoir si votre placement actuel des AP prend en charge la Règle de Trois dans toutes les zones cibles. Utilisez un outil tel qu'Ekahau ou iBwave pour modéliser la couverture des AP et identifier les lacunes. Si votre réseau a été conçu uniquement pour le débit et la couverture, vous devrez presque certainement densifier le déploiement, en particulier dans les zones à forte valeur ajoutée. Prévoyez un budget pour des AP et un câblage supplémentaires dans le cadre du projet.

Étape 2 : Définition des zones et géorepérage

Cartographiez votre espace physique en zones logiques au sein de la plateforme d'analyse. Importez vos plans d'étage et définissez des zones géorepérées qui correspondent à vos questions commerciales. Dans un environnement de vente au détail , les zones typiques incluent l'entrée, les catégories de produits spécifiques, les zones promotionnelles et la caisse. Dans un environnement hôtelier , les zones pertinentes pourraient inclure le hall, le restaurant, le bar, les salles de conférence et la piscine. Assurez-vous que les zones sont dimensionnées de manière appropriée — un minimum de 20 à 30 mètres carrés est une limite inférieure pratique pour l'analyse de localisation basée sur le WiFi.

Étape 3 : Intégration du contrôleur et pipeline de données

Intégrez votre contrôleur sans fil (Cisco, Aruba, Meraki, Ruckus, ou équivalent) à la plateforme d'analyse. Cela implique généralement de configurer le contrôleur pour qu'il transmette les flux de données RTLS (Real-Time Location System) ou les mises à jour de l'API de localisation au moteur d'analyse. Assurez-vous que le pipeline de données est configuré pour une livraison quasi en temps réel — une latence supérieure à 30 secondes dégradera la qualité des tableaux de bord opérationnels en direct. Toutes les transmissions de données doivent être chiffrées en transit (TLS 1.2 minimum) et être conformes au GDPR et à toutes les réglementations applicables en matière de protection des données.

Étape 4 : Configuration des seuils et établissement de la ligne de base

Configurez les Seuils de présence et les Périodes de temporisation pour chaque zone en fonction du comportement attendu dans cette zone. Faites fonctionner le système pendant un minimum de quatre à six semaines avant de tirer des conclusions, afin d'établir une ligne de base statistiquement robuste. Cette ligne de base est essentielle pour identifier les écarts significatifs — une chute soudaine du temps de présence à un présentoir promotionnel, par exemple, peut indiquer un problème de merchandising ou un manque de personnel.

dwell_time_heatmap_infographic.png


Bonnes pratiques

Les recommandations suivantes reflètent les approches standard de l'industrie pour le déploiement d'analyses de localisation WiFi à grande échelle.

Calibrez régulièrement l'environnement RF. L'environnement physique d'un lieu change continuellement — de nouveaux présentoirs, des stocks saisonniers, la densité de la foule modifient tous la propagation RF. Une étude de site menée lors du déploiement ne restera pas précise six mois plus tard. Intégrez une cadence de calibration trimestrielle à votre calendrier opérationnel et recalibrez immédiatement après tout changement physique significatif de l'espace.

Segmentez les analyses passives et authentifiées. Sensibilisez les parties prenantes à la distinction entre les analyses passives (appareils non authentifiés, soumis à la randomisation MAC) et les analyses authentifiées (utilisateurs qui se sont connectés au Guest WiFi). Les données passives fournissent des données de tendance fiables à grande échelle ; les données authentifiées fournissent un suivi déterministe au niveau individuel. Utilisez les données passives pour l'analyse macro du trafic et de la popularité des zones, et les données authentifiées pour l'attribution des conversions et l'engagement personnalisé.

Corrélez avec les données opérationnelles. Le temps de présence isolé est une métrique, pas une information. La valeur est débloquée lorsque les données spatiales sont corrélées avec les données de Point de Vente (PoS), les plannings de personnel ou les enregistrements de prestation de services. Un temps de présence élevé à une file d'attente de caisse, par exemple, n'est exploitable que lorsqu'il est corrélé avec les volumes de transactions et les niveaux de personnel. Cette corrélation est le fondement du cas de ROI pour l'investissement dans l'analyse de localisation.

Alignez-vous sur les exigences de confidentialité et de conformité. Assurez-vous que votre déploiement est conforme au GDPR (en le Royaume-Uni et l'UE), ainsi que toute réglementation sectorielle pertinente pour votre industrie. Dans les environnements de santé , les données de localisation des patients peuvent être soumises à des exigences supplémentaires en matière de protection des données. Mettez en œuvre les principes de minimisation des données — ne collectez que ce qui est nécessaire, anonymisez si possible et définissez des politiques claires de conservation des données.


Dépannage et atténuation des risques

Le tableau suivant résume les modes de défaillance les plus courants dans les déploiements de temps de présence WiFi et les étapes de remédiation recommandées.

Mode de défaillance Cause probable Remédiation
Nombre de visiteurs gonflé, temps de présence courts Randomisation MAC sur les appareils non authentifiés Favoriser l'authentification Guest WiFi ; utiliser le fingerprinting heuristique pour les données passives
Données de localisation erratiques (appareils sautant entre les zones) Densité d'AP insuffisante ou évanouissement multitrajets Densifier les AP ; ajuster les algorithmes de lissage ; recalibrer le modèle RF
Zones capturant les passants Seuil de présence (Dwell Threshold) trop bas Augmenter le seuil de présence minimum pour la zone affectée
Zone de caisse capturant le trafic d'entrée Définitions de zones qui se chevauchent ou sont surdimensionnées Resserrer les limites de la géofence ; s'assurer que les zones ne se chevauchent pas
Données de tableau de bord obsolètes ou retardées Latence du pipeline de données ou limitation de débit de l'API Examiner l'intégration du contrôleur ; augmenter la fréquence d'interrogation de l'API
Faible précision dans les environnements multi-étages Trilateration 2D appliquée à un espace 3D Mettre en œuvre une discrimination par étage en utilisant les données d'élévation des AP

ROI et impact commercial

La mise en œuvre de l'analyse de localisation WiFi transforme les espaces physiques en environnements mesurables et optimisables. Le cas d'affaires s'articule autour de trois dimensions : la génération de revenus, l'efficacité opérationnelle et l'expérience client.

Du côté des revenus, les données de temps de présence permettent des décisions de merchandising fondées sur des preuves. Savoir qu'un présentoir de tête de gondole spécifique génère un temps de présence moyen de 9,2 minutes — contre 1,6 minute à l'entrée — permet aux chefs de catégorie de prioriser les produits à forte marge dans les zones à fort engagement. Pour les opérateurs de transport , la compréhension des schémas de présence dans les concessions de détail éclaire directement les négociations de location et les accords de partage des revenus.

Du côté opérationnel, l'analyse de présence en temps réel permet une dotation en personnel dynamique. Un système de gestion de file d'attente qui déclenche une alerte au personnel lorsque le temps de présence à la caisse dépasse un seuil défini peut réduire les temps d'attente sans le coût d'un sureffectif permanent. Cela contribue directement à l'amélioration de la satisfaction client — un sujet exploré en profondeur dans Comment améliorer la satisfaction des clients : Le guide ultime .

Du côté de l'expérience, l'intelligence de localisation permet un engagement contextuellement pertinent. Lorsqu'elles sont intégrées à la plateforme WiFi Analytics de Purple, les données de présence peuvent déclencher des notifications personnalisées — une offre de réduction livrée à un client qui a passé plus de cinq minutes dans la section chaussures, par exemple. Cette capacité est de plus en plus pertinente à mesure que les lieux explorent des modèles d'accès sans mot de passe qui réduisent la friction d'authentification tout en maintenant la qualité des données.

Pour les organisations du secteur public et les initiatives de villes intelligentes, l'analyse de présence fournit la base de preuves pour les décisions d'investissement en infrastructure — comprendre comment les citoyens utilisent les espaces publics, les pôles de transport et les bâtiments civiques. La capacité croissante de Purple dans le secteur public, comme souligné dans la nomination d'Iain Fox au poste de VP Croissance pour le Secteur Public , reflète la demande croissante pour ce type d'intelligence spatiale dans les environnements gouvernementaux et municipaux.

Le coût total de possession pour un déploiement d'analyse de localisation WiFi est généralement faible par rapport à la valeur opérationnelle générée, en particulier lorsque la couche d'analyse est déployée sur une infrastructure WLAN existante. Le coût marginal est principalement la licence de la plateforme d'analyse et le temps d'ingénierie requis pour l'intégration et la calibration — et non un investissement matériel de type "greenfield".

Définitions clés

Wifi Dwell Time

The measured duration a WiFi-enabled device remains within a defined physical zone, calculated from the delta between an entry event and an exit event as detected by the wireless infrastructure.

The primary metric for spatial engagement analytics. Used by retail operators, venue managers, and healthcare administrators to understand how people use physical spaces.

Received Signal Strength Indicator (RSSI)

A measurement of the power level of a received radio signal, expressed in decibels relative to one milliwatt (dBm). Values typically range from 0 dBm (maximum signal) to -100 dBm (minimum detectable signal).

The raw input for distance estimation in WiFi location analytics. RSSI of -75 dBm or better at three or more APs is the minimum requirement for reliable trilateration.

Trilateration

A mathematical technique for determining the position of a point by measuring its distance from three or more known reference points. In WiFi analytics, the reference points are Access Points and the distances are estimated from RSSI readings.

The core positioning algorithm used by WiFi location analytics platforms. Distinct from triangulation, which uses angles rather than distances.

MAC Randomization

A privacy feature implemented in modern mobile operating systems (iOS 14+, Android 10+) where a device uses a temporary, randomized MAC address when probing for networks, rather than its permanent hardware address.

The primary technical challenge for passive WiFi analytics. Causes a single physical device to appear as multiple unique visitors, inflating footfall counts and fragmenting dwell time sessions. Mitigated by encouraging Guest WiFi authentication.

Geofencing

The creation of a virtual geographic boundary — defined as a polygon on a floor plan — that triggers analytical events (entry, exit, dwell) when a tracked device crosses the boundary.

Used within the analytics dashboard to define specific areas for localized dwell time measurement. Zone size and placement are critical configuration decisions that directly impact data quality.

Dwell Threshold

The minimum duration a device must remain within a geofenced zone before the analytics platform registers an entry event and begins counting dwell time.

Essential for data quality. A threshold that is too low will count passersby as dwellers; a threshold that is too high will miss genuine short-duration engagements. Must be tuned per zone based on expected behaviour.

Multipath Fading

A phenomenon where a radio signal reaches a receiving antenna via two or more paths — direct line-of-sight and one or more reflected paths — causing constructive or destructive interference that distorts the received signal strength.

The primary source of RSSI inaccuracy in complex indoor environments such as warehouses, retail stores, and hospitals. Mitigated through AP densification, smoothing algorithms, and RF fingerprinting.

Probe Request

An 802.11 management frame broadcast by a client device to discover available wireless networks. Contains the device's MAC address (which may be randomized), supported data rates, and other capability information.

The fundamental data packet captured by APs to detect the presence of devices in a venue. The raw input for all passive WiFi location analytics.

Deterministic Identification

The ability to identify a specific device or user with certainty, typically achieved through an authentication event where the device's true hardware MAC address is revealed to the network.

Achieved when a user authenticates to the Guest WiFi network. Enables accurate long-term dwell tracking that is immune to MAC randomization, and allows spatial data to be tied to a known user profile for conversion attribution.

Free-Space Path Loss (FSPL)

The attenuation of radio signal strength that occurs as the signal propagates through free space, increasing with distance and frequency according to a logarithmic model.

The theoretical basis for RSSI-to-distance conversion in trilateration. Real-world environments deviate significantly from the FSPL model due to obstacles and reflections, which is why calibration and smoothing algorithms are essential.

Exemples concrets

A national retail chain with 150 stores wants to measure the effectiveness of a new end-cap promotional display. The marketing team needs to know how long shoppers are stopping at the display, and whether high dwell time correlates with increased sales of the promoted SKU.

Step 1 — Zone Creation: Define a tight geofence (approximately 4m x 3m) around the end-cap display within the Purple analytics dashboard, distinct from the broader aisle zone. Step 2 — Threshold Configuration: Set a minimum dwell threshold of 20 seconds to filter out customers simply walking past the aisle end. Step 3 — Baseline Period: Run the analytics for two weeks before the promotion launches to establish a baseline dwell time for that zone. Step 4 — Promotion Period Measurement: Activate the promotion and monitor dwell time daily. Export the dwell time data via the analytics API. Step 5 — Correlation: Join the dwell time dataset with PoS transaction data for the promoted SKU, segmented by time of day and day of week. Calculate the Pearson correlation coefficient between average zone dwell time and hourly SKU sales volume. Step 6 — Reporting: Present the correlation data to the category management team with a recommendation to replicate the display format in high-footfall stores.

Commentaire de l'examinateur : The critical design decision here is the tight geofence around the specific display, rather than the broader aisle. This isolates the behaviour of interest. The 20-second threshold is appropriate for a retail browsing context — short enough to capture genuine engagement, long enough to exclude transit. The correlation with PoS data is what transforms the dwell metric into a business insight. Note that if the store relies entirely on passive analytics, MAC randomization may undercount repeat visitors; correlating with loyalty card data or encouraging Guest WiFi authentication would improve the precision of the individual-level analysis.

A large NHS trust needs to monitor patient wait times in the Emergency Department triage area to ensure compliance with the four-hour SLA target. The IT team has an existing Cisco Meraki deployment but no current analytics capability.

Step 1 — Infrastructure Audit: Conduct an RF site survey of the triage waiting area. Verify that a minimum of three Meraki APs hear devices in all seating areas at -70 dBm or better. The ED environment typically has high RF interference from medical equipment; densify if necessary. Step 2 — Meraki Location API Integration: Enable the Meraki Scanning API on the relevant APs and configure it to POST location data to the Purple analytics platform endpoint at 30-second intervals. Step 3 — Zone Definition: Define the triage waiting area as a distinct zone within Purple. Set the dwell threshold to 60 seconds and the timeout to 10 minutes (to account for patients who may be briefly taken to a side room). Step 4 — Real-Time Alerting: Configure a webhook alert to notify the duty charge nurse via the hospital's operational messaging system (e.g., Microsoft Teams or Vocera) if the average dwell time in the triage zone exceeds 45 minutes. Step 5 — Reporting: Generate weekly dwell time reports segmented by time of day and day of week to identify peak pressure periods for staffing optimisation.

Commentaire de l'examinateur : In healthcare, dwell time directly impacts patient outcomes and regulatory compliance. The critical step is the infrastructure audit — location accuracy must be sufficient to distinguish the waiting area from adjacent clinical corridors, which may be separated by only a few metres. The 10-minute timeout is deliberately generous to account for the non-linear movement patterns of patients in an ED. Real-time alerting is what transforms retrospective analytics into a proactive operational tool. Data governance is paramount in this context: ensure all location data is processed in compliance with NHS data protection policies and UK GDPR, and that patient data is anonymised at the point of collection.

Questions d'entraînement

Q1. You are deploying location analytics in a large warehouse with high metal racking throughout. Initial tests show device locations jumping erratically between aisles, and average dwell times are inconsistent. What is the most likely root cause and what remediation steps would you recommend?

Conseil : Consider how the physical structure of the environment affects RF signal propagation, and what this means for the reliability of RSSI-based distance estimation.

Voir la réponse type

The erratic location data is caused by severe multipath fading. Metal racking reflects and scatters RF signals, meaning the RSSI values received by APs are heavily distorted by reflected paths rather than representing true line-of-sight distances. This makes the trilateration engine's distance estimates unreliable. Recommended remediation: (1) Densify the AP deployment, positioning APs at the end of each aisle to maximise line-of-sight coverage down the aisle length. (2) Consider directional antennas focused down specific aisles to reduce cross-aisle interference. (3) Implement RF fingerprinting — pre-map RSSI signatures at known grid points throughout the warehouse to create a calibrated location model that accounts for the specific RF characteristics of the environment. (4) Tune the analytics platform's Kalman filter smoothing parameters to reduce the impact of transient RSSI spikes on the location estimate.

Q2. A retail operations director reports that the analytics platform is showing total daily visitor counts that are three times higher than the manual door counter, and average dwell times of under two minutes across all zones. The deployment relies entirely on passive probe request monitoring. What is the architectural issue and how would you resolve it?

Conseil : Think about what happens to a device's identifier over the course of a one-hour shopping visit on a modern smartphone.

Voir la réponse type

The issue is MAC randomization. Modern smartphones rotate their randomized MAC address periodically — in some cases every few minutes. Because the platform is relying entirely on passive probe requests, each new MAC address is interpreted as a new, unique visitor. A single shopper who spends an hour in the store may generate ten or more unique MAC addresses, each appearing as a separate visitor with a short dwell time. The resolution is twofold: (1) Implement a Guest WiFi authentication flow to drive users onto the network, providing a persistent hardware MAC address and a known user identity. Even a 30–40% authentication rate will significantly improve data quality. (2) For the remaining passive data, implement heuristic fingerprinting to probabilistically link probe requests from the same device based on Information Element patterns, reducing (though not eliminating) the inflation caused by MAC rotation. Communicate clearly to stakeholders that passive visitor counts are trend indicators, not absolute figures.

Q3. You have deployed location analytics in a shopping centre and defined a zone around a specific food court seating area. The data shows that the zone has an unusually high average dwell time of 45 minutes, but the food court operator reports that most customers are only seated for 15–20 minutes. What configuration issue might explain this discrepancy?

Conseil : Consider how the analytics platform handles devices that stop sending probe requests while remaining physically present in the zone.

Voir la réponse type

The most likely cause is an incorrectly configured Timeout Period. When a customer finishes eating and puts their phone in their pocket or bag, the device may enter a low-power state and stop broadcasting probe requests. If the Timeout Period is set too long — for example, 30 minutes — the platform will continue the dwell session for 30 minutes after the last detected probe, even if the customer has already left. This artificially inflates the reported dwell time. The fix is to reduce the Timeout Period to a value that reflects the typical gap between probe broadcasts in the environment — usually 3–5 minutes is appropriate for a busy public venue. Additionally, review whether the geofence boundary for the food court zone is inadvertently capturing adjacent areas (e.g., a corridor or queue) where customers may linger after leaving the seating area.