Come Calcolare il Tempo di Permanenza Utilizzando i WiFi Location Analytics

Questa guida fornisce un riferimento tecnico completo per il calcolo del tempo di permanenza WiFi utilizzando i WiFi location analytics, coprendo l'intera architettura dalla cattura delle richieste di probe 802.11 attraverso la trilaterazione basata su RSSI all'analisi delle zone geofenced. È progettata per IT manager, architetti di rete e direttori delle operazioni di sede che necessitano di implementare un'intelligence di localizzazione accurata e scalabile in ambienti di vendita al dettaglio, ospitalità, sanità e settore pubblico. I lettori otterranno indicazioni pratiche sull'implementazione, casi di studio reali e un quadro chiaro per tradurre i dati spaziali grezzi in risultati di business misurabili.

📖 9 minuti di lettura📝 2,134 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 10 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del 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.

Punti chiave

✓Wifi dwell time measures how long a device remains in a defined physical zone, and is the foundational metric for spatial engagement analytics in retail, hospitality, healthcare, and transport environments.
✓Accurate dwell time calculation requires three or more Access Points to detect a device simultaneously at -75 dBm or better — the Rule of Three — enabling trilateration to determine the device's position.
✓MAC randomization on modern smartphones is the primary challenge for passive analytics; driving Guest WiFi authentication provides deterministic identification that overcomes this limitation.
✓Geofence zone size, dwell thresholds, and timeout periods must be carefully configured per zone; incorrect settings are the most common cause of misleading dwell data.
✓Passive analytics provides reliable trend data at scale; authenticated analytics provides individual-level precision suitable for conversion attribution and personalised engagement.
✓Dwell time data delivers ROI through three channels: evidence-based merchandising decisions, dynamic operational staffing, and contextually relevant customer engagement.
✓Regular RF calibration is essential — the physical environment of a venue changes continuously, and a deployment calibrated at launch will degrade in accuracy without an ongoing maintenance cadence.

Riepilogo Esecutivo

Per le sedi aziendali — dai vasti spazi di vendita al dettaglio agli stadi estesi — comprendere il comportamento dei visitatori non è più un lusso di marketing; è un requisito operativo fondamentale. Il tempo di permanenza WiFi, la durata in cui un dispositivo rimane all'interno di una zona fisica definita, funge da metrica fondamentale per misurare l'engagement spaziale. Tuttavia, calcolare accuratamente il tempo di permanenza utilizzando l'infrastruttura wireless esistente richiede la navigazione in ambienti RF complessi, la randomizzazione MAC e frequenze di probe dei dispositivi variabili.

Questa guida fornisce a professionisti IT senior, architetti di rete e direttori delle operazioni un riferimento tecnico definitivo su come calcolare il tempo di permanenza utilizzando i WiFi location analytics. Esploriamo i meccanismi di rilevamento dei dispositivi, il ruolo dell'Indicatore di Forza del Segnale Ricevuto (RSSI) e della trilaterazione, e come piattaforme come Purple traducono le richieste di probe grezze in business intelligence azionabile. Sfruttando la vostra infrastruttura Guest WiFi esistente, le organizzazioni possono implementare analytics scalabili senza costose reti hardware sovrapposte. Il caso del ROI è convincente: le sedi che implementano l'analisi della posizione riportano costantemente miglioramenti misurabili nei tassi di conversione, nell'efficienza operativa e nella soddisfazione del cliente.

Approfondimento Tecnico: I Meccanismi del Tempo di Permanenza

Il calcolo del tempo di permanenza è fondamentalmente un problema di risoluzione spaziale e temporale. Richiede l'identificazione di un dispositivo, la stima della sua posizione e il tracciamento continuo di tale posizione nel tempo. Ognuna di queste tre fasi introduce le proprie sfide tecniche, e una soluzione robusta deve affrontarle tutte.

1. Rilevamento e Identificazione del Dispositivo

Il processo inizia con il rilevamento passivo delle richieste di probe 802.11. I dispositivi mobili trasmettono continuamente questi frame di gestione per scoprire le reti wireless disponibili. Gli Access Point (AP) che agiscono come sensori catturano questi frame, che contengono l'indirizzo MAC del dispositivo, un timestamp e la forza del segnale all'AP ricevente (RSSI).

Storicamente, l'indirizzo MAC forniva un identificatore persistente a livello hardware. Tuttavia, i moderni sistemi operativi mobili — iOS 14+, Android 10+ e Windows 10+ — implementano la randomizzazione MAC per migliorare la privacy dell'utente. Quando un dispositivo non è associato a una rete, utilizza un indirizzo MAC temporaneo e randomizzato che ruota periodicamente. Questo sfida direttamente il calcolo passivo del tempo di permanenza, poiché un singolo dispositivo fisico può apparire come più visitatori unici durante una sessione.

Per mantenere la continuità della sessione per un calcolo accurato del tempo di permanenza, le piattaforme di analytics devono impiegare una delle due strategie. La prima è il fingerprinting euristico, che comporta l'analisi degli Information Elements (IE) all'interno del frame di richiesta probe — come i tassi di dati supportati, gli elenchi di canali e i campi specifici del fornitore — per collegare probabilisticamente le richieste di probe dallo stesso dispositivo anche quando l'indirizzo MAC cambia. Il secondo approccio, e di gran lunga più affidabile, è quello di fare affidamento sulle sessioni autenticate. Quando un utente si connette esplicitamente alla rete Guest WiFi , la piattaforma riceve il vero indirizzo MAC hardware del dispositivo e può collegarlo a un profilo utente persistente. Questa identificazione deterministica è lo standard d'oro per metriche di permanenza accurate e a lungo termine.

2. Stima Spaziale: RSSI e Trilaterazione

Una volta rilevato un dispositivo, il sistema deve determinarne la posizione fisica. L'approccio più ampiamente adottato utilizza la trilaterazione basata su RSSI, una tecnica spiegata in dettaglio nella guida The Mechanics of WiFi Wayfinding: Trilateration and RSSI Explained .

Il principio è semplice: l'RSSI decade in modo prevedibile con la distanza secondo il modello di Perdita di Percorso nello Spazio Libero (FSPL). Misurando la forza del segnale a più AP, il sistema può stimare la distanza dal dispositivo a ciascun AP. Quando tre o più AP rilevano la stessa richiesta di probe, il motore di analytics può calcolare la posizione del dispositivo trovando l'intersezione di cerchi (o sfere in un ambiente 3D a più piani) i cui raggi corrispondono alle distanze stimate da ciascun AP.

In pratica, gli ambienti RF sono lontani dal modello idealizzato di spazio libero. Il fading multipath, causato dalle riflessioni del segnale su pareti, scaffalature metalliche e corpi umani, introduce una significativa varianza RSSI. Per mitigare ciò, i motori di analytics di livello produttivo applicano diverse tecniche:

Tecnica	Scopo	Guadagno Tipico
Algoritmo del Centroide Ponderato	Assegna un peso maggiore agli AP con letture RSSI più forti	Riduce l'errore di posizione del 15–30%
Filtro di Kalman	Appiana le stime di posizione nel tempo per rimuovere il rumore transitorio	Riduce il jitter nel tracciamento in tempo reale
Mappatura delle Impronte	Pre-mappa le firme RSSI in posizioni note per la calibrazione	Migliora la precisione in ambienti RF complessi
Media Multi-AP	Media l'RSSI su più intervalli di campionamento	Riduce l'impatto delle interferenze momentanee

Per una trilaterazione affidabile, si applica la Regola dei Tre: un dispositivo deve essere rilevato da almeno tre AP contemporaneamente con una forza del segnale di -75 dBm o superiore. Le reti progettate puramente per la copertura — dove un singolo AP fornisce un segnale su una vasta area — non supporteranno un'accuravalutare l'analisi della posizione. Questa è una distinzione architettonica critica che deve essere affrontata prima dell'implementazione.

3. Calcolo Temporale: Definire e Calcolare il Tempo di Permanenza

Con un flusso di coordinate di posizione, il motore di analisi mappa le posizioni dei dispositivi rispetto alle zone georeferenziate definite all'interno della piattaforma. Una georeferenzia è un poligono virtuale disegnato su una planimetria, che rappresenta un'area fisica significativa come una coda alla cassa, un display promozionale o una hall d'albergo.

Il tempo di permanenza non è semplicemente la differenza tra il primo e l'ultimo timestamp osservato. Un calcolo robusto deve tenere conto dei cicli di sospensione del dispositivo, delle brevi uscite dalla zona e del rumore intrinseco nelle stime di posizione. La logica di calcolo standard definisce tre parametri chiave:

Evento di Ingresso: La posizione stimata del dispositivo entra in una zona georeferenziata definita e vi rimane per un periodo minimo — la Soglia di Permanenza — per filtrare i passanti. Una soglia comune per gli ambienti di vendita al dettaglio è di 30 secondi; per le aree di attesa sanitarie, 60 secondi potrebbero essere più appropriati.

Evento di Uscita: La posizione del dispositivo si sposta al di fuori del confine della zona, o il dispositivo non viene rilevato da alcun AP per un Periodo di Timeout definito (tipicamente 3–5 minuti). Il timeout gestisce i dispositivi che entrano in modalità di sospensione o vengono riposti in una borsa, prevenendo la terminazione prematura della sessione.

Durata della Permanenza: La differenza tra il timestamp dell'Evento di Ingresso e il timestamp dell'Evento di Uscita, meno qualsiasi buffer di timeout. Questa è la metrica riportata nella dashboard di WiFi Analytics .

Guida all'Implementazione

L'implementazione di una soluzione robusta di analisi della posizione WiFi richiede un'attenta pianificazione e allineamento tra l'architettura di rete e gli obiettivi aziendali. I seguenti passaggi rappresentano un framework di implementazione indipendente dal fornitore, applicabile a qualsiasi ambiente WLAN aziendale.

Fase 1: Valutazione e Densificazione dell'Infrastruttura

Condurre un'indagine RF approfondita per valutare la distribuzione WLAN esistente rispetto ai requisiti dei servizi di localizzazione. La domanda chiave è se il posizionamento attuale degli AP supporta la Regola del Tre in tutte le zone target. Utilizzare uno strumento come Ekahau o iBwave per modellare la copertura degli AP e identificare le lacune. Se la rete è stata progettata esclusivamente per throughput e copertura, sarà quasi certamente necessario densificare la distribuzione, in particolare nelle zone di alto valore. Prevedere AP e cablaggi aggiuntivi come parte dell'ambito del progetto.

Fase 2: Definizione delle Zone e Georeferenziazione

Mappare lo spazio fisico in zone logiche all'interno della piattaforma di analisi. Importare le planimetrie e definire le aree georeferenziate che si allineano con le domande aziendali. In un ambiente Retail , le zone tipiche includono l'ingresso, specifiche categorie di prodotti, aree promozionali e la cassa. In un contesto Hospitality , le zone rilevanti potrebbero includere la hall, il ristorante, il bar, le sale conferenze e l'area piscina. Assicurarsi che le zone siano dimensionate in modo appropriato — un minimo di 20–30 metri quadrati è un limite inferiore pratico per l'analisi della posizione basata su WiFi.

Fase 3: Integrazione del Controller e Pipeline di Dati

Integrare il controller wireless (Cisco, Aruba, Meraki, Ruckus o equivalente) con la piattaforma di analisi. Ciò comporta tipicamente la configurazione del controller per inoltrare flussi di dati RTLS (Real-Time Location System) o aggiornamenti API di localizzazione al motore di analisi. Assicurarsi che la pipeline di dati sia configurata per la consegna quasi in tempo reale — una latenza superiore a 30 secondi degraderà la qualità delle dashboard operative in tempo reale. Tutta la trasmissione dei dati deve essere crittografata in transito (TLS 1.2 minimo) e conforme al GDPR e a qualsiasi normativa applicabile sulla protezione dei dati.

Fase 4: Configurazione delle Soglie e Stabilizzazione della Baseline

Configurare le Soglie di Permanenza e i Periodi di Timeout per ogni zona in base al comportamento previsto in quell'area. Far funzionare il sistema per un minimo di quattro-sei settimane prima di trarre conclusioni, per stabilire una baseline statisticamente robusta. Questa baseline è essenziale per identificare deviazioni significative — un calo improvviso del tempo di permanenza presso un display promozionale, ad esempio, può indicare un problema di merchandising o una carenza di personale.

Best Practices

Le seguenti raccomandazioni riflettono gli approcci standard del settore per l'implementazione di analisi della posizione WiFi su larga scala.

Calibrare regolarmente l'ambiente RF. L'ambiente fisico di un luogo cambia continuamente — nuovi display, inventario stagionale, densità della folla alterano tutti la propagazione RF. Un'indagine del sito condotta al momento dell'implementazione non rimarrà accurata sei mesi dopo. Inserire una cadenza di calibrazione trimestrale nel programma operativo e ricalibrare immediatamente dopo qualsiasi cambiamento fisico significativo dello spazio.

Segmentare l'analisi passiva e autenticata. Educare gli stakeholder sulla distinzione tra analisi passiva (dispositivi non autenticati, soggetti a randomizzazione MAC) e analisi autenticata (utenti che hanno effettuato l'accesso al Guest WiFi). I dati passivi forniscono dati di tendenza affidabili su larga scala; i dati autenticati forniscono un tracciamento deterministico a livello individuale. Utilizzare i dati passivi per l'analisi del traffico pedonale a livello macro e della popolarità delle zone, e i dati autenticati per l'attribuzione delle conversioni e l'engagement personalizzato.

Correlare con i dati operativi. Il tempo di permanenza isolato è una metrica, non un'intuizione. Il valore si sblocca quando i dati spaziali vengono correlati con i dati del Punto Vendita (PoS), gli orari del personale o i registri di erogazione dei servizi. Un tempo di permanenza elevato in una coda alla cassa, ad esempio, è utilizzabile solo se correlato ai volumi delle transazioni e ai livelli di personale. Questa correlazione è la base del caso di ROI per l'investimento in analisi della posizione.

Allinearsi ai requisiti di privacy e conformità. Assicurarsi che l'implementazione sia conforme al GDPR (in il Regno Unito e l'UE), e qualsiasi regolamentazione specifica del settore rilevante per la tua industria. Negli ambienti sanitari , i dati sulla posizione dei pazienti possono essere soggetti a requisiti aggiuntivi di protezione dei dati. Implementa i principi di minimizzazione dei dati — raccogli solo ciò che è necessario, anonimizza dove possibile e definisci chiare politiche di conservazione dei dati.

Risoluzione dei problemi e Mitigazione del rischio

La seguente tabella riassume le modalità di errore più comuni nelle implementazioni di dwell time WiFi e le fasi di rimedio raccomandate.

Modalità di errore	Causa probabile	Rimedio
Conteggi visitatori gonfiati, tempi di permanenza brevi	Randomizzazione MAC su dispositivi non autenticati	Promuovi l'autenticazione Guest WiFi; usa il fingerprinting euristico per i dati passivi
Dati di posizione erratici (dispositivi che saltano tra le zone)	Densità AP insufficiente o fading multipath	Aumenta la densità degli AP; ottimizza gli algoritmi di smoothing; ricalibra il modello RF
Zone che catturano i passanti	Soglia di permanenza impostata troppo bassa	Aumenta la soglia minima di permanenza per la zona interessata
Zona di cassa che cattura il traffico in ingresso	Definizioni di zona sovrapposte o sovradimensionate	Riduci i confini del geofence; assicurati che le zone non si sovrappongano
Dati del dashboard obsoleti o ritardati	Latenza della pipeline di dati o limitazione della frequenza API	Rivedi l'integrazione del controller; aumenta la frequenza di polling API
Scarsa precisione in ambienti multi-piano	Trilaterazione 2D applicata a uno spazio 3D	Implementa la discriminazione a livello di piano utilizzando i dati di elevazione AP

ROI e Impatto sul Business

L'implementazione dell'analisi della posizione WiFi trasforma gli spazi fisici in ambienti misurabili e ottimizzabili. Il caso aziendale opera su tre dimensioni: generazione di entrate, efficienza operativa ed esperienza del cliente.

Sul fronte delle entrate, i dati sul tempo di permanenza consentono decisioni di merchandising basate su prove. Sapere che una specifica esposizione di testata di corsia genera un tempo di permanenza medio di 9,2 minuti — contro 1,6 minuti all'ingresso — consente ai category manager di dare priorità ai prodotti ad alto margine nelle zone ad alto coinvolgimento. Per gli operatori del trasporto , la comprensione dei modelli di permanenza nelle concessioni al dettaglio informa direttamente le negoziazioni di locazione e gli accordi di condivisione dei ricavi.

Sul fronte operativo, l'analisi del tempo di permanenza in tempo reale consente una gestione dinamica del personale. Un sistema di gestione delle code che attiva un avviso al personale quando il tempo di permanenza alla cassa supera una soglia definita può ridurre i tempi di attesa senza il costo di un eccesso di personale permanente. Ciò contribuisce direttamente a migliorare la soddisfazione del cliente — un argomento esplorato in profondità in Come Migliorare la Soddisfazione degli Ospiti: Il Playbook Definitivo .

Sul fronte dell'esperienza, l'intelligence sulla posizione consente un coinvolgimento contestualmente rilevante. Se integrati con la piattaforma WiFi Analytics di Purple, i dati sul tempo di permanenza possono attivare notifiche personalizzate — ad esempio, un'offerta di sconto consegnata a un cliente che ha trascorso più di cinque minuti nella sezione calzature. Questa capacità è sempre più rilevante man mano che le sedi esplorano modelli di accesso senza password che riducono l'attrito dell'autenticazione pur mantenendo la qualità dei dati.

Per le organizzazioni del settore pubblico e le iniziative smart city, l'analisi del tempo di permanenza fornisce la base di prove per le decisioni di investimento infrastrutturale — comprendendo come i cittadini utilizzano spazi pubblici, hub di trasporto ed edifici civici. La crescente capacità di Purple nel settore pubblico, come evidenziato nella nomina di Iain Fox a VP Growth per il Settore Pubblico , riflette la crescente domanda di questo tipo di intelligenza spaziale negli ambienti governativi e municipali.

Il costo totale di proprietà per un'implementazione di analisi della posizione WiFi è tipicamente basso rispetto al valore operativo generato, in particolare dove lo strato di analisi è implementato su un'infrastruttura WLAN esistente. Il costo marginale è principalmente la licenza della piattaforma di analisi e il tempo di ingegneria richiesto per l'integrazione e la calibrazione — non un investimento hardware greenfield.

Definizioni chiave

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.

Esempi pratici

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.

Commento dell'esaminatore: 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.

Commento dell'esaminatore: 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.

Domande di esercitazione

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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.