Cómo calcular el tiempo de permanencia utilizando análisis de ubicación WiFi

Esta guía ofrece una referencia técnica completa para calcular el tiempo de permanencia WiFi utilizando análisis de ubicación WiFi, cubriendo la arquitectura completa desde la captura de solicitudes de sondeo 802.11, pasando por la trilateración basada en RSSI, hasta el análisis de zonas geocercadas. Está diseñada para gerentes de TI, arquitectos de redes y directores de operaciones de recintos que necesitan implementar inteligencia de ubicación precisa y escalable en entornos minoristas, hoteleros, de atención médica y del sector público. Los lectores obtendrán orientación de implementación práctica, estudios de casos reales y un marco claro para traducir datos espaciales brutos en resultados comerciales medibles.

📖 9 min de lectura📝 2,134 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 10 definiciones clave

Escucha esta guía

Ver transcripción 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.

Puntos clave

✓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.

Resumen Ejecutivo

Para los recintos empresariales —desde amplios espacios comerciales hasta extensos estadios— comprender el comportamiento de los visitantes ya no es un lujo de marketing; es un requisito operativo crítico. El tiempo de permanencia WiFi, la duración que un dispositivo permanece dentro de una zona física definida, sirve como métrica fundamental para medir el compromiso espacial. Sin embargo, calcular con precisión el tiempo de permanencia utilizando la infraestructura inalámbrica existente requiere navegar por entornos de RF complejos, la aleatorización de MAC y las frecuencias variables de sondeo de dispositivos.

Esta guía proporciona a profesionales de TI sénior, arquitectos de redes y directores de operaciones una referencia técnica definitiva sobre cómo calcular el tiempo de permanencia utilizando análisis de ubicación WiFi. Exploramos la mecánica de la detección de dispositivos, el papel del Indicador de Fuerza de Señal Recibida (RSSI) y la trilateración, y cómo plataformas como Purple traducen las solicitudes de sondeo en inteligencia de negocios procesable. Al aprovechar su infraestructura de Guest WiFi existente, las organizaciones pueden implementar análisis escalables sin costosas redes de hardware superpuestas. El caso del ROI es convincente: los recintos que implementan análisis de ubicación reportan consistentemente mejoras medibles en las tasas de conversión, la eficiencia operativa y la satisfacción del cliente.

Análisis Técnico Detallado: La Mecánica del Tiempo de Permanencia

Calcular el tiempo de permanencia es fundamentalmente un problema de resolución espacial y temporal. Requiere identificar un dispositivo, estimar su posición y rastrear esa posición continuamente a lo largo del tiempo. Cada una de estas tres etapas introduce sus propios desafíos técnicos, y una solución robusta debe abordarlos todos.

1. Detección e Identificación de Dispositivos

El proceso comienza con la detección pasiva de solicitudes de sondeo 802.11. Los dispositivos móviles transmiten continuamente estos marcos de gestión para descubrir redes inalámbricas disponibles. Los Puntos de Acceso (APs) que actúan como sensores capturan estos marcos, que contienen la dirección MAC del dispositivo, una marca de tiempo y la fuerza de la señal en el AP receptor (RSSI).

Históricamente, la dirección MAC proporcionaba un identificador persistente a nivel de hardware. Sin embargo, los sistemas operativos móviles modernos — iOS 14+, Android 10+ y Windows 10+ — implementan la aleatorización de MAC para mejorar la privacidad del usuario. Cuando un dispositivo no está asociado a una red, utiliza una dirección MAC temporal y aleatoria que rota periódicamente. Esto desafía directamente el cálculo pasivo del tiempo de permanencia, ya que un solo dispositivo físico puede aparecer como múltiples visitantes únicos durante una sesión.

Para mantener la continuidad de la sesión para un cálculo preciso del tiempo de permanencia, las plataformas de análisis deben emplear una de dos estrategias. La primera es el reconocimiento heurístico (heuristic fingerprinting), que implica analizar los Elementos de Información (IEs) dentro del marco de la solicitud de sondeo —como las tasas de datos admitidas, las listas de canales y los campos específicos del proveedor— para vincular probabilísticamente las solicitudes de sondeo del mismo dispositivo incluso cuando la dirección MAC cambia. El segundo enfoque, y mucho más fiable, es confiar en las sesiones autenticadas. Cuando un usuario se conecta explícitamente a la red Guest WiFi , la plataforma recibe la verdadera dirección MAC de hardware del dispositivo y puede vincularla a un perfil de usuario persistente. Esta identificación determinista es el estándar de oro para métricas de permanencia precisas y a largo plazo.

2. Estimación Espacial: RSSI y Trilateración

Una vez detectado un dispositivo, el sistema debe determinar su ubicación física. El enfoque más ampliamente implementado utiliza la trilateración basada en RSSI, una técnica explicada en profundidad en la guía La Mecánica de la Orientación WiFi: Trilateración y RSSI Explicados .

El principio es sencillo: el RSSI decae predeciblemente con la distancia según el modelo de Pérdida de Trayectoria en Espacio Libre (FSPL). Al medir la fuerza de la señal en múltiples APs, el sistema puede estimar la distancia del dispositivo a cada AP. Cuando tres o más APs detectan la misma solicitud de sondeo, el motor de análisis puede calcular la posición del dispositivo encontrando la intersección de círculos (o esferas en un entorno 3D de múltiples pisos) cuyos radios corresponden a las distancias estimadas desde cada AP.

En la práctica, los entornos de RF están lejos del modelo idealizado de espacio libre. El desvanecimiento por trayectos múltiples (multipath fading), causado por las reflexiones de la señal en paredes, estanterías metálicas y cuerpos humanos, introduce una varianza significativa en el RSSI. Para mitigar esto, los motores de análisis de grado de producción aplican varias técnicas:

Technique	Purpose	Typical Gain
Algoritmo de Centroide Ponderado	Asigna mayor peso a los APs con lecturas de RSSI más fuertes	Reduce el error de posición en un 15–30%
Filtrado de Kalman	Suaviza las estimaciones de ubicación a lo largo del tiempo para eliminar el ruido transitorio	Reduce la fluctuación en el seguimiento en tiempo real
Mapeo de Huellas (Fingerprint Mapping)	Pre-mapea las firmas RSSI en ubicaciones conocidas para calibración	Mejora la precisión en entornos de RF complejos
Promedio Multi-AP	Promedia el RSSI en múltiples intervalos de muestreo	Reduce el impacto de la interferencia momentánea

Para una trilateración fiable, se aplica la Regla de Tres: un dispositivo debe ser detectado por al menos tres APs simultáneamente con una fuerza de señal de -75 dBm o mejor. Las redes diseñadas puramente para cobertura —donde un solo AP proporciona una señal en un área grande— no soportarán una precisiónanalíticas de ubicación. Esta es una distinción arquitectónica crítica que debe abordarse antes de la implementación.

3. Cálculo Temporal: Definición y Cómputo del Tiempo de Permanencia

Con un flujo de coordenadas de ubicación, el motor de analíticas mapea las posiciones de los dispositivos contra zonas geocercadas definidas dentro de la plataforma. Una geocerca es un polígono virtual dibujado sobre un plano, que representa un área física significativa como una fila de caja, una exhibición promocional o un vestíbulo de hotel.

El tiempo de permanencia no es simplemente la diferencia entre la primera y la última marca de tiempo observadas. Un cálculo robusto debe tener en cuenta los ciclos de suspensión del dispositivo, las breves salidas de zona y el ruido inherente en las estimaciones de ubicación. La lógica de cálculo estándar define tres parámetros clave:

Evento de Entrada: La posición estimada del dispositivo entra en una zona geocercada definida y permanece dentro de ella por un período mínimo — el Umbral de Permanencia — para filtrar a los transeúntes. Un umbral común para entornos minoristas es de 30 segundos; para áreas de espera de atención médica, 60 segundos pueden ser más apropiados.

Evento de Salida: La posición del dispositivo se mueve fuera del límite de la zona, o el dispositivo no es detectado por ningún AP durante un Período de Tiempo de Espera definido (típicamente 3–5 minutos). El tiempo de espera maneja los dispositivos que entran en modo de suspensión o se guardan en una bolsa, evitando la terminación prematura de la sesión.

Duración de la Permanencia: La diferencia entre la marca de tiempo del Evento de Entrada y la marca de tiempo del Evento de Salida, menos cualquier búfer de tiempo de espera. Esta es la métrica reportada al panel de WiFi Analytics .

Guía de Implementación

La implementación de una solución robusta de analíticas de ubicación WiFi requiere una planificación cuidadosa y una alineación entre la arquitectura de red y los objetivos comerciales. Los siguientes pasos representan un marco de implementación neutral para el proveedor, aplicable a cualquier entorno WLAN empresarial.

Paso 1: Evaluación y Densificación de la Infraestructura

Realice un estudio de sitio de RF exhaustivo para evaluar su implementación WLAN existente frente a los requisitos del servicio de ubicación. La pregunta clave es si su ubicación actual de APs soporta la Regla de Tres en todas las zonas objetivo. Utilice una herramienta como Ekahau o iBwave para modelar la cobertura de AP y identificar brechas. Si su red fue diseñada únicamente para rendimiento y cobertura, casi con certeza necesitará densificar la implementación, particularmente en zonas de alto valor. Presupueste APs adicionales y cableado como parte del alcance del proyecto.

Paso 2: Definición de Zonas y Geocercado

Mapee su espacio físico en zonas lógicas dentro de la plataforma de analíticas. Importe sus planos y defina áreas geocercadas que se alineen con sus preguntas de negocio. En un entorno de Retail , las zonas típicas incluyen la entrada, categorías de productos específicas, áreas promocionales y la caja. En un entorno de Hospitality , las zonas relevantes podrían incluir el vestíbulo, restaurante, bar, salas de conferencias y área de piscina. Asegúrese de que las zonas tengan un tamaño apropiado — un mínimo de 20–30 metros cuadrados es un límite inferior práctico para las analíticas de ubicación basadas en WiFi.

Paso 3: Integración del Controlador y Canalización de Datos

Integre su controlador inalámbrico (Cisco, Aruba, Meraki, Ruckus o equivalente) con la plataforma de analíticas. Esto típicamente implica configurar el controlador para reenviar flujos de datos RTLS (Real-Time Location System) o actualizaciones de la API de ubicación al motor de analíticas. Asegúrese de que la canalización de datos esté configurada para una entrega casi en tiempo real — una latencia superior a 30 segundos degradará la calidad de los paneles operativos en vivo. Toda la transmisión de datos debe estar cifrada en tránsito (TLS 1.2 mínimo) y cumplir con GDPR y cualquier regulación de protección de datos aplicable.

Paso 4: Configuración de Umbrales y Establecimiento de la Línea Base

Configure los Umbrales de Permanencia y los Períodos de Tiempo de Espera para cada zona basándose en el comportamiento esperado en esa área. Ejecute el sistema durante un mínimo de cuatro a seis semanas antes de sacar conclusiones, para establecer una línea base estadísticamente robusta. Esta línea base es esencial para identificar desviaciones significativas — una caída repentina en el tiempo de permanencia en una exhibición promocional, por ejemplo, puede indicar un problema de comercialización o una brecha de personal.

Mejores Prácticas

Las siguientes recomendaciones reflejan enfoques estándar de la industria para implementar analíticas de ubicación WiFi a escala.

Calibre el Entorno de RF Regularmente. El entorno físico de un lugar cambia continuamente — nuevas exhibiciones, inventario estacional, densidad de multitudes, todo altera la propagación de RF. Un estudio de sitio realizado en el momento de la implementación no seguirá siendo preciso seis meses después. Incorpore una cadencia de calibración trimestral en su cronograma operativo y recalibre inmediatamente después de cualquier cambio físico significativo en el espacio.

Segmente las Analíticas Pasivas y Autenticadas. Eduque a las partes interesadas sobre la distinción entre analíticas pasivas (dispositivos no autenticados, sujetos a aleatorización de MAC) y analíticas autenticadas (usuarios que han iniciado sesión en el Guest WiFi). Los datos pasivos proporcionan datos de tendencias fiables a escala; los datos autenticados proporcionan seguimiento determinista a nivel individual. Utilice datos pasivos para el análisis de afluencia a nivel macro y popularidad de zonas, y datos autenticados para la atribución de conversiones y el engagement personalizado.

Correlacione con Datos Operacionales. El tiempo de permanencia de forma aislada es una métrica, no una perspectiva. El valor se desbloquea cuando los datos espaciales se correlacionan con datos de Punto de Venta (PoS), horarios de personal o registros de entrega de servicios. Un tiempo de permanencia alto en una fila de caja, por ejemplo, solo es accionable cuando se correlaciona con los volúmenes de transacciones y los niveles de personal. Esta correlación es la base del caso de ROI para la inversión en analíticas de ubicación.

Alinéese con los Requisitos de Privacidad y Cumplimiento. Asegúrese de que su implementación cumpla con GDPR (en el Reino Unido y la UE), y cualquier regulación específica del sector relevante para su industria. En entornos de Atención Médica , los datos de ubicación de los pacientes pueden estar sujetos a requisitos adicionales de protección de datos. Implemente principios de minimización de datos: recopile solo lo necesario, anonimice cuando sea posible y defina políticas claras de retención de datos.

Resolución de Problemas y Mitigación de Riesgos

La siguiente tabla resume los modos de falla más comunes en las implementaciones de tiempo de permanencia de WiFi y los pasos de remediación recomendados.

Modo de Falla	Causa Probable	Remediación
Recuentos de visitantes inflados, tiempos de permanencia cortos	Aleatorización de MAC en dispositivos no autenticados	Impulsar la autenticación de Guest WiFi; usar huellas dactilares heurísticas para datos pasivos
Datos de ubicación erráticos (dispositivos saltando entre zonas)	Densidad de AP insuficiente o desvanecimiento multitrayecto	Densificar APs; ajustar algoritmos de suavizado; recalibrar modelo RF
Zonas que capturan transeúntes	Umbral de permanencia establecido demasiado bajo	Aumentar el umbral de permanencia mínimo para la zona afectada
Zona de pago que captura tráfico de entrada	Definiciones de zona superpuestas o sobredimensionadas	Ajustar los límites de la geocerca; asegurar que las zonas no se superpongan
Datos de panel obsoletos o retrasados	Latencia de la canalización de datos o limitación de velocidad de la API	Revisar la integración del controlador; aumentar la frecuencia de sondeo de la API
Poca precisión en entornos de varios pisos	Trilateración 2D aplicada a espacio 3D	Implementar discriminación a nivel de piso usando datos de elevación de AP

ROI e Impacto Comercial

La implementación de analíticas de ubicación WiFi transforma los espacios físicos en entornos medibles y optimizables. El caso de negocio opera en tres dimensiones: generación de ingresos, eficiencia operativa y experiencia del cliente.

En el lado de los ingresos, los datos de tiempo de permanencia permiten decisiones de merchandising basadas en evidencia. Saber que una exhibición de cabecera específica genera un tiempo de permanencia promedio de 9.2 minutos —frente a 1.6 minutos en la entrada— permite a los gerentes de categoría priorizar productos de alto margen en zonas de alta interacción. Para operadores de Transporte , comprender los patrones de permanencia en las concesiones minoristas informa directamente las negociaciones de arrendamiento y los acuerdos de participación en los ingresos.

En el lado operativo, las analíticas de permanencia en tiempo real permiten una dotación de personal dinámica. Un sistema de gestión de colas que activa una alerta para el personal cuando el tiempo de permanencia en la caja excede un umbral definido puede reducir los tiempos de espera sin el costo de una sobrecarga de personal permanente. Esto contribuye directamente a una mayor satisfacción del cliente —un tema explorado en profundidad en Cómo Mejorar la Satisfacción del Invitado: El Manual Definitivo .

En el lado de la experiencia, la inteligencia de ubicación permite una interacción contextualmente relevante. Cuando se integra con la plataforma de WiFi Analytics de Purple, los datos de permanencia pueden activar notificaciones personalizadas —por ejemplo, una oferta de descuento entregada a un cliente que ha pasado más de cinco minutos en la sección de calzado. Esta capacidad es cada vez más relevante a medida que los lugares exploran modelos de acceso sin contraseña que reducen la fricción de autenticación mientras mantienen la calidad de los datos.

Para organizaciones del sector público e iniciativas de ciudades inteligentes, las analíticas de permanencia proporcionan la base de evidencia para las decisiones de inversión en infraestructura —comprendiendo cómo los ciudadanos utilizan los espacios públicos, los centros de transporte y los edificios cívicos. La creciente capacidad de Purple en el sector público, como se destaca en el nombramiento de Iain Fox como VP de Crecimiento para el Sector Público , refleja la creciente demanda de este tipo de inteligencia espacial en entornos gubernamentales y municipales.

El costo total de propiedad para una implementación de analíticas de ubicación WiFi es típicamente bajo en relación con el valor operativo generado, particularmente cuando la capa de analíticas se implementa sobre una infraestructura WLAN existente. El costo marginal es principalmente la licencia de la plataforma de analíticas y el tiempo de ingeniería requerido para la integración y calibración —no una inversión en hardware desde cero.

Definiciones clave

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.

Ejemplos resueltos

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.

Comentario del examinador: 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.

Comentario del examinador: 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.

Preguntas de práctica

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?

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

Ver respuesta modelo

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?

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

Ver respuesta modelo

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?

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

Ver respuesta modelo

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.