Saltar para o conteúdo principal

Como Calcular o Tempo de Permanência Usando Análise de Localização WiFi

Este guia fornece uma referência técnica abrangente para o cálculo do tempo de permanência wifi usando análise de localização WiFi, cobrindo a arquitetura completa desde a captura de pedidos de sonda 802.11, passando pela trilateração baseada em RSSI, até à análise de zonas georreferenciadas. É concebido para gestores de IT, arquitetos de rede e diretores de operações de espaços que necessitam de implementar inteligência de localização precisa e escalável em ambientes de retalho, hotelaria, saúde e setor público. Os leitores obterão orientações de implementação acionáveis, estudos de caso reais e uma estrutura clara para traduzir dados espaciais brutos em resultados de negócio mensuráveis.

📖 9 min de leitura📝 2,134 palavras🔧 2 exemplos práticos3 perguntas de prática📚 10 definições principais

Ouça este guia

Ver transcrição do 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

Resumo Executivo

Para espaços empresariais — desde grandes áreas de retalho a estádios extensos — compreender o comportamento dos visitantes já não é um luxo de marketing; é um requisito operacional crítico. O tempo de permanência wifi, a duração em que um dispositivo permanece dentro de uma zona física definida, serve como métrica fundamental para medir o envolvimento espacial. No entanto, calcular com precisão o tempo de permanência usando a infraestrutura sem fios existente requer navegar em ambientes de RF complexos, randomização de MAC e frequências de sonda de dispositivo variáveis.

Este guia fornece a profissionais de IT seniores, arquitetos de rede e diretores de operações uma referência técnica definitiva sobre como calcular o tempo de permanência usando análise de localização WiFi. Exploramos a mecânica da deteção de dispositivos, o papel do Indicador de Força do Sinal Recebido (RSSI) e da trilateração, e como plataformas como a Purple traduzem pedidos de sonda brutos em inteligência de negócio acionável. Ao alavancar a sua infraestrutura de Guest WiFi existente, as organizações podem implementar análises escaláveis sem redes de hardware de sobreposição dispendiosas. O caso de ROI é convincente: os espaços que implementam análise de localização reportam consistentemente melhorias mensuráveis nas taxas de conversão, eficiência operacional e satisfação do cliente.


Análise Técnica Detalhada: A Mecânica do Tempo de Permanência

O cálculo do tempo de permanência é fundamentalmente um problema de resolução espacial e temporal. Requer a identificação de um dispositivo, a estimativa da sua posição e o rastreamento contínuo dessa posição ao longo do tempo. Cada uma destas três fases introduz os seus próprios desafios técnicos, e uma solução robusta deve abordá-los a todos.

1. Deteção e Identificação de Dispositivos

O processo começa com a deteção passiva de 802.11 probe requests. Os dispositivos móveis transmitem continuamente estes quadros de gestão para descobrir redes sem fios disponíveis. Os Access Points (APs) que atuam como sensores capturam estes quadros, que contêm o MAC address do dispositivo, um carimbo de data/hora e a força do sinal no AP recetor (RSSI).

Historicamente, o MAC address fornecia um identificador persistente ao nível do hardware. No entanto, os sistemas operativos móveis modernos — iOS 14+, Android 10+ e Windows 10+ — implementam a MAC randomization para melhorar a privacidade do utilizador. Quando um dispositivo não está associado a uma rede, utiliza um MAC address temporário e aleatório que roda periodicamente. Isto desafia diretamente o cálculo passivo do tempo de permanência, uma vez que um único dispositivo físico pode aparecer como múltiplos visitantes únicos ao longo de uma sessão.

Para manter a continuidade da sessão para um cálculo preciso do tempo de permanência, as plataformas de análise devem empregar uma de duas estratégias. A primeira é o heuristic fingerprinting, que envolve a análise dos Information Elements (IEs) dentro do quadro de pedido de sonda — como taxas de dados suportadas, listas de canais e campos específicos do fornecedor — para ligar probabilisticamente os pedidos de sonda do mesmo dispositivo, mesmo quando o MAC address muda. A segunda abordagem, e muito mais fiável, é depender de authenticated sessions. Quando um utilizador se conecta explicitamente à rede Guest WiFi , a plataforma recebe o verdadeiro MAC address de hardware do dispositivo e pode ligá-lo a um perfil de utilizador persistente. Esta identificação determinística é o padrão ouro para métricas de permanência precisas e de longo prazo.

2. Estimativa Espacial: RSSI e Trilateração

Uma vez detetado um dispositivo, o sistema deve determinar a sua localização física. A abordagem mais amplamente implementada utiliza a trilateração baseada em RSSI, uma técnica explicada em profundidade no guia The Mechanics of WiFi Wayfinding: Trilateration and RSSI Explained .

O princípio é direto: o RSSI decai previsivelmente com a distância de acordo com o modelo Free-Space Path Loss (FSPL). Ao medir a força do sinal em múltiplos APs, o sistema pode estimar a distância do dispositivo a cada AP. Quando três ou mais APs detetam o mesmo pedido de sonda, o motor de análise pode calcular a posição do dispositivo encontrando a interseção de círculos (ou esferas num ambiente 3D de vários andares) cujos raios correspondem às distâncias estimadas de cada AP.

dwell_time_architecture_overview.png

Na prática, os ambientes de RF estão longe do modelo idealizado de espaço livre. O multipath fading, causado por reflexões de sinal em paredes, prateleiras metálicas e corpos humanos, introduz uma variância significativa no RSSI. Para mitigar isto, os motores de análise de nível de produção aplicam várias técnicas:

Técnica Propósito Ganho Típico
Algoritmo de Centroide Ponderado Atribui maior peso aos APs com leituras de RSSI mais fortes Reduz o erro de posição em 15–30%
Filtragem de Kalman Suaviza as estimativas de localização ao longo do tempo para remover ruído transitório Reduz o jitter no rastreamento em tempo real
Mapeamento por Impressão Digital Pré-mapeia assinaturas RSSI em locais conhecidos para calibração Melhora a precisão em ambientes de RF complexos
Média de Múltiplos APs Média do RSSI em múltiplos intervalos de amostragem Reduz o impacto de interferências momentâneas

Para uma trilateração fiável, aplica-se a Regra dos Três: um dispositivo deve ser detetado por pelo menos três APs simultaneamente com uma força de sinal de -75 dBm ou superior. Redes concebidas puramente para cobertura — onde um único AP fornece um sinal numa grande área — não suportarão precianalítica de localização. Esta é uma distinção arquitetónica crítica que deve ser abordada antes da implementação.

3. Cálculo Temporal: Definição e Computação do Tempo de Permanência

Com um fluxo de coordenadas de localização, o motor de analítica mapeia as posições dos dispositivos em relação a zonas georreferenciadas definidas na plataforma. Uma geocerca é um polígono virtual desenhado sobre uma planta, representando uma área física significativa, como uma fila de caixa, um expositor promocional ou um lobby de hotel.

O tempo de permanência não é simplesmente o delta entre o primeiro e o último carimbo de data/hora observados. Um cálculo robusto deve ter em conta os ciclos de suspensão do dispositivo, as breves saídas da zona e o ruído inerente nas estimativas de localização. A lógica de cálculo padrão define três parâmetros chave:

Evento de Entrada: A posição estimada do dispositivo entra numa zona georreferenciada definida e permanece nela por um período mínimo — o Limiar de Permanência — para filtrar os transeuntes. Um limiar comum para ambientes de retalho é de 30 segundos; para áreas de espera de saúde, 60 segundos podem ser mais apropriados.

Evento de Saída: A posição do dispositivo move-se para fora do limite da zona, ou o dispositivo não é detetado por nenhum AP durante um Período de Tempo Limite definido (tipicamente 3–5 minutos). O tempo limite lida com dispositivos que entram em modo de suspensão ou são colocados numa mala, evitando a terminação prematura da sessão.

Duração da Permanência: O delta entre o carimbo de data/hora do Evento de Entrada e o carimbo de data/hora do Evento de Saída, menos qualquer buffer de tempo limite. Esta é a métrica reportada ao dashboard de WiFi Analytics .


Guia de Implementação

A implementação de uma solução robusta de analítica de localização WiFi requer um planeamento cuidadoso e alinhamento entre a arquitetura de rede e os objetivos de negócio. Os passos seguintes representam um framework de implementação neutro em relação ao fornecedor, aplicável a qualquer ambiente WLAN empresarial.

Passo 1: Avaliação e Densificação da Infraestrutura

Realize um levantamento de rádio frequência (RF) exaustivo para avaliar a sua implementação WLAN existente em relação aos requisitos de serviço de localização. A questão chave é se a sua colocação atual de APs suporta a Regra dos Três em todas as zonas alvo. Utilize uma ferramenta como Ekahau ou iBwave para modelar a cobertura dos APs e identificar lacunas. Se a sua rede foi projetada apenas para débito e cobertura, será quase certamente necessário densificar a implementação, particularmente em zonas de alto valor. Orçamente APs e cablagem adicionais como parte do âmbito do projeto.

Passo 2: Definição de Zonas e Georreferenciação

Mapeie o seu espaço físico em zonas lógicas dentro da plataforma de analítica. Importe as suas plantas e defina áreas georreferenciadas que se alinhem com as suas questões de negócio. Num ambiente de Retalho , as zonas típicas incluem a entrada, categorias de produtos específicas, áreas promocionais e o checkout. Num ambiente de Hotelaria , as zonas relevantes podem incluir o lobby, restaurante, bar, salas de conferência e área da piscina. Garanta que as zonas são dimensionadas apropriadamente — um mínimo de 20–30 metros quadrados é um limite inferior prático para a analítica de localização baseada em WiFi.

Passo 3: Integração do Controlador e Pipeline de Dados

Integre o seu controlador sem fios (Cisco, Aruba, Meraki, Ruckus, ou equivalente) com a plataforma de analítica. Isto tipicamente envolve a configuração do controlador para encaminhar fluxos de dados RTLS (Real-Time Location System) ou atualizações da API de localização para o motor de analítica. Garanta que o pipeline de dados está configurado para entrega quase em tempo real — latência acima de 30 segundos degradará a qualidade dos dashboards operacionais em tempo real. Toda a transmissão de dados deve ser encriptada em trânsito (TLS 1.2 mínimo) e cumprir com o GDPR e quaisquer regulamentos de proteção de dados aplicáveis.

Passo 4: Configuração de Limiares e Estabelecimento da Linha de Base

Configure os Limiares de Permanência e Períodos de Tempo Limite para cada zona com base no comportamento esperado nessa área. Execute o sistema por um mínimo de quatro a seis semanas antes de tirar conclusões, para estabelecer uma linha de base estatisticamente robusta. Esta linha de base é essencial para identificar desvios significativos — uma queda súbita no tempo de permanência num expositor promocional, por exemplo, pode indicar um problema de merchandising ou uma lacuna de pessoal.

dwell_time_heatmap_infographic.png


Boas Práticas

As seguintes recomendações refletem abordagens padrão da indústria para a implementação de analítica de localização WiFi em escala.

Calibre o Ambiente de RF Regularmente. O ambiente físico de um local muda continuamente — novos expositores, inventário sazonal, densidade da multidão, tudo altera a propagação de RF. Um levantamento do local realizado na implementação não permanecerá preciso seis meses depois. Inclua uma cadência de calibração trimestral no seu cronograma operacional e recalibre imediatamente após qualquer alteração física significativa no espaço.

Segmente a Analítica Passiva e Autenticada. Eduque as partes interessadas sobre a distinção entre analítica passiva (dispositivos não autenticados, sujeitos à randomização de MAC) e analítica autenticada (utilizadores que iniciaram sessão no Guest WiFi). Os dados passivos fornecem dados de tendências fiáveis em escala; os dados autenticados fornecem rastreamento determinístico ao nível individual. Utilize dados passivos para análise de fluxo de pessoas a nível macro e popularidade de zonas, e dados autenticados para atribuição de conversão e envolvimento personalizado.

Correlacione com Dados Operacionais. O tempo de permanência isolado é uma métrica, não uma perspetiva. O valor é desbloqueado quando os dados espaciais são correlacionados com dados de Ponto de Venda (PoS), horários de pessoal ou registos de entrega de serviços. Um tempo de permanência elevado numa fila de caixa, por exemplo, só é acionável quando correlacionado com volumes de transação e níveis de pessoal. Esta correlação é a base do caso de ROI para o investimento em analítica de localização.

Alinhe com os Requisitos de Privacidade e Conformidade. Garanta que a sua implementação cumpre com o GDPR (em o Reino Unido e a UE), e quaisquer regulamentos específicos do setor relevantes para a sua indústria. Em ambientes de Saúde , os dados de localização de pacientes podem estar sujeitos a requisitos adicionais de proteção de dados. Implemente princípios de minimização de dados — recolha apenas o que é necessário, anonimize sempre que possível e defina políticas claras de retenção de dados.


Resolução de Problemas e Mitigação de Riscos

A tabela seguinte resume os modos de falha mais comuns em implementações de tempo de permanência WiFi e as etapas de remediação recomendadas.

Modo de Falha Causa Provável Remediação
Contagens de visitantes inflacionadas, tempos de permanência curtos Aleatorização de MAC em dispositivos não autenticados Promova a autenticação Guest WiFi; utilize impressões digitais heurísticas para dados passivos
Dados de localização erráticos (dispositivos a saltar entre zonas) Densidade de APs insuficiente ou desvanecimento por múltiplos percursos Densifique os APs; ajuste os algoritmos de suavização; recalibre o modelo de RF
Zonas a capturar transeuntes Limiar de Permanência definido muito baixo Aumente o limiar mínimo de permanência para a zona afetada
Zona de checkout a capturar tráfego de entrada Definições de zona sobrepostas ou sobredimensionadas Aperte os limites da geofence; garanta que as zonas não se sobrepõem
Dados do dashboard desatualizados ou atrasados Latência do pipeline de dados ou limitação de taxa da API Reveja a integração do controlador; aumente a frequência de polling da API
Baixa precisão em ambientes multi-piso Trilateração 2D aplicada a espaço 3D Implemente discriminação ao nível do piso usando dados de elevação de AP

ROI e Impacto no Negócio

A implementação de análises de localização WiFi transforma espaços físicos em ambientes mensuráveis e otimizáveis. O caso de negócio opera em três dimensões: geração de receita, eficiência operacional e experiência do cliente.

No lado da receita, os dados de tempo de permanência permitem decisões de merchandising baseadas em evidências. Saber que um expositor de ponta de gôndola específico gera um tempo de permanência médio de 9,2 minutos — versus 1,6 minutos na entrada — permite aos gestores de categoria priorizar produtos de alta margem em zonas de alto envolvimento. Para operadores de Transporte , compreender os padrões de permanência em concessões de retalho informa diretamente as negociações de arrendamento e os acordos de partilha de receita.

No lado operacional, as análises de permanência em tempo real permitem uma gestão dinâmica de pessoal. Um sistema de gestão de filas que aciona um alerta para o pessoal quando o tempo de permanência no checkout excede um limiar definido pode reduzir os tempos de espera sem o custo de excesso de pessoal permanente. Isto contribui diretamente para a melhoria da satisfação do cliente — um tópico explorado em profundidade em Como Melhorar a Satisfação do Convidado: O Guia Definitivo .

No lado da experiência, a inteligência de localização permite um envolvimento contextualmente relevante. Quando integrados com a plataforma WiFi Analytics da Purple, os dados de permanência podem acionar notificações personalizadas — uma oferta de desconto entregue a um cliente que passou mais de cinco minutos na secção de calçado, por exemplo. Esta capacidade é cada vez mais relevante à medida que os locais exploram modelos de acesso sem palavra-passe que reduzem o atrito da autenticação, mantendo a qualidade dos dados.

Para organizações do setor público e iniciativas de cidades inteligentes, as análises de permanência fornecem a base de evidências para decisões de investimento em infraestruturas — compreendendo como os cidadãos utilizam espaços públicos, centros de transporte e edifícios cívicos. A capacidade crescente da Purple no setor público, conforme destacado na nomeação de Iain Fox como VP de Crescimento para o Setor Público , reflete a crescente procura por este tipo de inteligência espacial em ambientes governamentais e municipais.

O custo total de propriedade para uma implementação de análises de localização WiFi é tipicamente baixo em relação ao valor operacional gerado, particularmente onde a camada de análise é implementada sobre uma infraestrutura WLAN existente. O custo marginal é principalmente a licença da plataforma de análise e o tempo de engenharia necessário para integração e calibração — não um investimento em hardware de raiz.

Definições Principais

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.

Exemplos Práticos

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.

Comentário do 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.

Comentário do 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.

Perguntas de Prática

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?

Dica: 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 resposta 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?

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

Ver resposta 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?

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

Ver resposta 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.