HPE Aruba Central presence analytics: setup, exports and limits

A análise de presença do Aruba Central conta os dispositivos que os seus pontos de acesso HPE Aruba detetam. De seguida, classifica-os em transeuntes e visitantes utilizando um limiar de RSSI e limites de tempo de permanência que define para cada local. Ative-a por local, calibre o limiar no espaço físico e exporte os agregados através da REST API do Central. Conta dispositivos e nunca identifica pessoas.

O que mede realmente a análise de presença do Aruba Central?

Todos os telemóveis com o WiFi ligado enviam pedidos de deteção (probe requests), que são pequenos pacotes que perguntam quais as redes que estão por perto. Enviam-nos quer se associem ou não à sua rede. Os seus pontos de acesso Aruba detetam esses pacotes e reportam o endereço MAC e a intensidade do sinal de cada dispositivo ao Central. O Central aplica então duas regras que o utilizador controla.

A primeira regra é a intensidade do sinal. O RSSI (received signal strength indicator) é medido em dBm, e os valores mais próximos de zero significam que o dispositivo está mais perto do ponto de acesso. Um dispositivo acima do seu limiar de RSSI é contabilizado como estando dentro do local. Um dispositivo detetado abaixo desse valor é contabilizado como transeunte.

A segunda regra é o tempo de permanência. Entre os dispositivos acima do limiar, o Central utiliza os limites de tempo de permanência para separar as deteções breves das visitas reais. Em seguida, agrupa os visitantes em faixas de duração.

O resultado são os dados agregados de tráfego pedonal Aruba para cada local: transeuntes, visitantes e a distribuição do tempo de permanência. Responde a "quantos dispositivos estiveram aqui e durante quanto tempo". Não consegue responder a "quem eram", e esse limite define tudo o que se segue neste guia.

O modelo de presença próprio da Purple funciona com base na mesma física. A documentação de Presence (Legacy) descreve a contagem de dispositivos não autenticados que comunicam ("ping") com um ponto de acesso a uma distância suficientemente próxima para que o seu endereço MAC seja registado. O RSSI funciona como o sinal de proximidade. A duração mede o tempo que qualquer ponto de acesso no local detetou o dispositivo. Se compreender um modelo, compreende ambos.

De que necessita antes de ativar a análise de presença no Aruba Central?

De cinco coisas, e a última é a que as equipas costumam ignorar.

1. Uma subscrição do Central que inclua a análise de presença. A análise de presença não faz parte de todos os níveis de licença do Central. Verifique a documentação de licenciamento atual da HPE em relação à subscrição atribuída aos APs de cada local.
2. APs atribuídos a um local, e não apenas a um grupo. O Central utiliza grupos para configuração e locais para localização e relatórios. A presença agrega-se por local, pelo que um AP sem local atribuído não contribui com dados úteis.
3. Uma planta de piso com o limite físico marcado. Marque portas, montras de vidro, esplanadas, parques de estacionamento e paredes partilhadas com frações vizinhas. Estes são os locais onde o seu limiar falhará primeiro.
4. Um dispositivo de teste que consiga identificar. As versões modernas do iOS e do Android randomizam o endereço MAC que o dispositivo apresenta, por isso desative a definição de endereço privado no seu telemóvel de teste ou anote o endereço que ele utiliza.
5. Uma posição sobre a privacidade. Os endereços MAC são identificadores de dispositivos. O Considerando 30 do GDPR nomeia os identificadores online fornecidos por dispositivos como informações que podem identificar uma pessoa. Realize uma avaliação de impacto sobre a proteção de dados e coloque sinalização nas entradas antes de iniciar a recolha. O ICO do Reino Unido publicou orientações sobre análise de localização baseadas em sinais de dispositivos, cobrindo ambos os pontos.

Para o trabalho de API, também precisa de uma função de administrador no Central que possa criar clientes API Gateway, e de um destino para os dados: um armazém de dados, uma base de dados ou uma ferramenta de BI.

Como configurar a análise de presença do Aruba Central?

Passo 1: ativar o serviço para cada local

Ative a análise de presença ao nível do local no Central. O caminho exato do menu difere entre o Aruba Central clássico e a interface mais recente do HPE Aruba Networking Central. Siga a documentação atual da HPE para a sua versão em vez de uma captura de ecrã de uma versão mais antiga. Aguarde que os primeiros dados sejam preenchidos antes de fazer qualquer avaliação, e espere que os números do dia de abertura pareçam incorretos até realizar a calibração.

Passo 2: calibrar o limite de RSSI

Não existe um limite universal de RSSI da Aruba para a contagem de visitantes. O valor correto depende da altura de montagem dos APs, do padrão da antena, do material da parede, dos vidros e da proximidade dos APs em relação ao limite do espaço. Um número copiado de outro local irá classificar incorretamente os dispositivos no seu. Em vez disso, calibre-o:

1. Percorra o limite do espaço. Leve o dispositivo de teste a três pontos: logo dentro da entrada, no próprio limite da entrada e no passeio ou via pública no exterior. Permaneça em cada ponto durante alguns minutos e anote o RSSI que o Central reporta.
2. Repita numa hora de ponta. As pessoas absorvem a energia da radiofrequência, pelo que as leituras nas horas de maior afluência são mais baixas do que as leituras num edifício vazio. Calibre com base nas condições de pico, porque é nessa altura que as contagens importam.
3. Defina o limite entre "logo dentro" e "exterior". Ajuste-o mais próximo da leitura interior se o tráfego de pedestres passar perto do vidro. Ajuste-o mais próximo da leitura exterior se a entrada for recuada e ninguém permanecer por perto.
4. Registe o valor e a data. Todas as comparações posteriores dependem de saber qual o limite que produziu cada conjunto de números.

Passo 3: definir os limites de tempo de permanência que separam os transeuntes dos visitantes

O RSSI por si só classifica incorretamente qualquer pessoa que passe perto do vidro. O tempo mínimo de permanência do visitante remove-as. Defina-o para a visita real mais curta no seu espaço, e não para uma média do setor. As faixas de tempo mais longas descreverão então o nível de envolvimento dos seus visitantes.

Tipo de espaço	Como se parece um transeunte	Referência para o tempo mínimo de permanência do visitante	Dados reais para validação
Retalho de rua	Pedestre a caminhar em frente à montra	Compra real mais rápida, como um artigo para levar no momento	Contagem de transações de caixa
Lobby de hotel	Hóspede a dirigir-se aos elevadores ou ao restaurante	Interação mais curta de check-in ou de receção	Registo de check-in da receção
Foyer do centro de conferências	Delegado a passar entre pavilhões	Permanência mínima na sessão	Leituras de cartões por sessão
Concurso do estádio	Adepto a mover-se entre a bancada e o quiosque	Compra mais rápida no quiosque	Contagem de transações no quiosque
Biblioteca ou ponto de atendimento municipal	Peão na rua adjacente	Consulta mais rápida no balcão	Registo de consultas no balcão ou contador de portas

Altere uma definição de cada vez. Se mover o limite de RSSI e o limite de permanência em simultâneo, não conseguirá saber qual das alterações alterou a contagem.

Passo 4: exportar dados de presença através da API Central

Os painéis do Central são ótimos para uma consulta rápida, mas os relatórios a jusante precisam de extrair os dados. Uma exportação de API do Aruba Central segue quatro passos.

1. Criar um cliente de API no API Gateway. O Central autentica chamadas REST com tokens de acesso OAuth 2.0. Os tokens de acesso são de curta duração, por isso guarde o token de atualização num gestor de segredos e automatize a renovação.
2. Chamar os endpoints de análise de presença. Estes devolvem agregados ao nível do site para uma janela de tempo que especificar. Utilize a referência do programador da HPE para obter os caminhos e parâmetros atuais dos endpoints, pois estes mudam entre versões da API.
3. Agendar a extração. Um trabalho diário que solicita o dia anterior por site é fácil de auditar. Guarde o ID do site, a janela de tempo em UTC e as definições de limite e permanência em vigor na altura.
4. Respeitar os limites de taxa. O Central aplica limites de taxa de API por conta. As grandes propriedades devem desfasar os pedidos dos sites em vez de extrair todos os sites no mesmo minuto.

O Passo 3 importa mais do que parece. Quando alguém alterar um limite daqui a seis meses, as definições guardadas permitem que os analistas dividam as séries em vez de reportarem uma queda fantasma nos visitantes.

Como verificar se as contagens estão corretas?

Valide em relação a algo que já contabiliza. Escolha uma fonte de verdade factual por site a partir da tabela acima e compare-a com a contagem de visitantes do Central todos os dias durante, pelo menos, uma semana.

Não está à procura de números iguais. Vários clientes chegam juntos, os funcionários transportam telemóveis e alguns visitantes não transportam qualquer dispositivo. Está à procura de um rácio estável. Se os visitantes se mantiverem num múltiplo consistente de transações, a configuração é sólida e o rácio torna-se uma métrica de taxa de captura que pode reportar.

Execute quatro verificações de bom senso antes de confiar nos dados:

• Contagens noturnas. Os visitantes registados após o encerramento costumam apontar para dispositivos de funcionários, dispositivos fixos ou equipamentos de vizinhos acima do seu limite.
• Capacidade. Os visitantes presentes em simultâneo nunca devem exceder a lotação licenciada do local.
• Painel versus API. Os totais diários da sua extração de API devem corresponder ao painel do Central para o mesmo site e janela de tempo. Uma divergência costuma significar um erro de fuso horário.
• Site versus site. Compare sites com atividade comercial semelhante. Um site com o dobro dos visitantes e metade das transações tem um problema de calibração, não um problema de vendas.

Como é que se traduz a afinação num local real?

Os dois cenários abaixo utilizam valores ilustrativos para demonstrar o método. Os seus próprios números serão diferentes, mas a aritmética é a mesma.

Cenário 1: uma loja de moda de rua com uma fachada de vidro

Situação. Uma loja de um único piso tem dois APs a poucos metros de uma fachada de vidro de altura total junto a um passeio movimentado. Num sábado típico, o Central reporta 3.200 visitantes face a 410 transações de caixa. A taxa de captura implícita de cerca de 13% parece implausivelmente fraca face à experiência da equipa comercial.

O que foi feito. O engenheiro de rede percorreu o limite exterior na hora de almoço de sábado. Descobriu que os dispositivos no passeio diretamente no exterior do vidro apresentavam uma leitura quase tão forte como os dispositivos mesmo dentro da porta. Ele aumentou o limiar de RSSI para ficar entre essas duas leituras. Em seguida, definiu o tempo mínimo de permanência de visitante para o tempo necessário para comprar um único artigo na caixa.

Resultado. No sábado seguinte, o Central reportou 1.150 visitantes face a 425 transações, um rácio de aproximadamente 2,7 visitantes por venda. Esse rácio manteve-se numa banda estreita ao longo dos quatro fins de semana seguintes. O analista de dados reporta agora este valor semanalmente como um indicador de conversão para a análise comercial de retail da loja.

Cenário 2: o foyer de um centro de conferências com um hotel adjacente

Situação. Um centro de conferências partilha um corredor de ligação envidraçado com um hotel de 200 quartos. Os organizadores de eventos pretendem dados de permanência por dia para definir o preço dos stands dos patrocinadores no foyer. A distribuição de permanência do Central mostra um grande pico na banda mais curta, independentemente de estar a decorrer um evento.

O que foi feito. O engenheiro descobriu que os hóspedes do hotel que caminhavam pelo corredor de ligação ficavam acima do limiar de RSSI dos APs do foyer. Alterar apenas o limiar teria excluído delegados reais que estivessem perto do corredor. Em vez disso, a equipa aumentou o tempo mínimo de permanência de visitante para um valor superior ao tempo necessário para percorrer o corredor de uma ponta à outra. Em seguida, validaram as contagens comparando-as com as leituras de cartões de identificação em três dias de evento.

Resultado. Nos dias sem eventos, os visitantes do foyer diminuíram para um nível consistente com os funcionários e prestadores de serviços. Nos dias de evento, as contagens de visitantes acompanharam as leituras de cartões de identificação num rácio estável. Os organizadores puderam então apresentar aos patrocinadores um valor sustentável para os delegados que passaram mais de um determinado tempo no foyer. O tráfego de guest do hotel deixou de poluir os dados do evento.

Cenário 3: uma biblioteca municipal com uma paragem de autocarro no exterior

Situação. Uma biblioteca pública situa-se ao lado de uma paragem de autocarro onde as pessoas aguardam durante vários minutos, bem dentro do alcance do AP da entrada. O município pretende números de visitas para o seu relatório de serviço anual.

O que foi feito. Nem o RSSI nem o tempo de permanência isoladamente separavam um passageiro de autocarro em espera de um visitante da biblioteca. A equipa definiu o limiar utilizando leituras obtidas na própria paragem de autocarro. Em seguida, cruzaram as contagens com o contador de porta existente durante um mês. Resultado. A contagem de presenças e a contagem de portas acompanharam-se mutuamente dentro de uma margem consistente. O município manteve o contador de portas como o valor oficial e utilizou os dados de presença para o padrão hora a hora, que o contador de portas não conseguia fornecer. O padrão serviu de base para alterações na dotação de pessoal no balcão de atendimento.

O que corre mal e como se resolve?

As contagens de visitantes são muito superiores a qualquer realidade no terreno

O limiar de RSSI é demasiado permissivo, normalmente devido a vidro, uma divisória fina ou um AP montado perto da entrada. Repita o percurso pelo limite nas horas de ponta e aumente o limiar. Se a colocação do AP impossibilitar uma separação limpa, considere movê-lo para mais longe do limite.

As contagens sofrem alterações após uma atualização do SO móvel

A aleatorização de endereços MAC significa que um dispositivo físico pode aparecer como vários endereços ao longo do tempo. Cada alteração ao comportamento de aleatorização no iOS ou Android pode alterar as suas contagens e diminuir os valores de visitas repetidas. Anote as suas séries de relatórios com as datas de lançamento das principais versões de SO. Trate as métricas de visitas repetidas de dispositivos não autenticados com precaução.

Visitantes noturnos ou de manhã cedo

Telemóveis de funcionários, leitores portáteis, impressoras e dispositivos inteligentes permanecem acima do limiar o dia todo. Exclua os endereços de dispositivos conhecidos onde o Aruba Central o permita, ou exclua as horas fora do período de funcionamento nos seus relatórios downstream.

As chamadas de API devolvem erros de autorização

O token de acesso expirou e a etapa de atualização falhou ou nunca foi executada. Verifique se o seu trabalho utiliza o token de atualização, armazena o novo par de tokens recebido e emite um alerta em caso de falha, em vez de registar silenciosamente dias vazios.

Uma mudança repentina e abrupta nas comparações históricas

Alguém alterou um limiar ou limite de tempo de permanência. É por isso que o Passo 4 armazena as definições a cada extração. Divida a série na data da alteração e reporte os dois períodos separadamente.

Problemas no Captive Portal distorcem as métricas autenticadas

Se também opera um Captive Portal, que é a página web que um dispositivo vê antes de obter acesso à rede, as falhas de redirecionamento reduzem as visitas autenticadas. Estas não afetam as contagens de presença. Investigue os redirecionamentos do portal como um problema separado da calibração de presença.

Quais são os limites da análise do Aruba Central?

A análise de presença nativa é útil e vem incluída com o seu parque Aruba. Tem também limitações rígidas que deve expor claramente às partes interessadas antes de estas construírem um programa de relatórios com base nela.

• Agregação ao nível do local. O Aruba Central reporta por local. Se necessitar de comparações entre zonas dentro de um local, ou classificações num parque de grandes dimensões com regras consistentes, terá de construir essa estrutura downstream por si próprio.
• Retenção. O Aruba Central guarda os dados de presença por um período limitado definido pela plataforma e pela sua subscrição. A comparação anual depende da sua própria exportação, por isso inicie o pipeline da API logo no primeiro dia.- Sem camada de identificação. Os dados de presença são contagens de dispositivos anónimos. Não é possível associar uma visita a um contacto que tenha dado consentimento, a uma conta de fidelização ou a um registo de CRM. Os endereços MAC aleatórios tornam as contagens de visitas repetidas anónimas pouco fiáveis a longo prazo.
• Visão de fornecedor único. O Central vê pontos de acesso Aruba. Os espaços que misturam Aruba com Cisco Meraki, Ruckus ou Juniper Mist em locais adquiridos obtêm uma imagem parcial.
• Necessidade constante de calibração. Cada remodelação, mudança de AP ou nova instalação de vidros altera o ambiente de rádio. Os limiares que estavam corretos no momento da instalação sofrem desvios a menos que alguém volte a percorrer o limite.

Nenhum destes pontos é um defeito. Representam apenas o âmbito da funcionalidade de análise de um fornecedor de rede e definem onde uma camada de plataforma ganha o seu espaço.

Quanto custa e quando é que uma camada de plataforma adicional compensa?

A via nativa custa tempo de engenharia e de analistas, em vez de gastos adicionais com licenças, desde que a sua subscrição do Central já inclua a análise de presença. Preveja no orçamento uma verificação de limites por local, uma semana de validação, uma pipeline de API para criar e manter, e uma recalibração após alterações físicas.

O WiFi Analytics da Purple adiciona uma camada diferente em vez de duplicar o Central. Funciona como um overlay na nuvem agnóstico em termos de hardware nos pontos de acesso Aruba que já possui, sem necessidade de substituição de equipamentos. O Captive Portal de Guest WiFi da Purple adiciona uma camada autenticada através de adesões por escolha consciente, o que lhe fornece dados em primeira mão que a presença anónima não consegue obter.

Funcionalidade	Análise de presença do Aruba Central	Purple WiFi Analytics nos seus APs Aruba
O que conta	Dispositivos anónimos acima de um limiar de RSSI	Visitas onde a força do sinal colocou o dispositivo dentro do local, além de visitantes autenticados
Identidade	Nenhuma, apenas endereço MAC	Visitantes autenticados com dados em primeira mão consentidos
Relatórios de permanência	Intervalos de duração por local	Tempo médio de permanência por visita para visitantes autenticados
Padrões temporais	Painéis de controlo do local num período escolhido	Mapa de calor de visitas por dia da semana e hora do dia
Visão multi-local	Por local, criada posteriormente para a totalidade dos espaços	Top 10 e bottom 10 de locais por visitas, classificados na plataforma
Hardware	Apenas HPE Aruba	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet
Visualização em tempo real	Painéis de controlo do Central	Últimos 25 minutos em intervalos de um minuto, atualizados a cada minuto (Presence Legacy)
A quem se adequa	Espaços com um único fornecedor que necessitam de padrões de ocupação anónimos	Espaços multi-local ou com vários fornecedores que necessitam de dados de visitantes identificados e consentidos

As capacidades de Purple nesta tabela provêm da documentação da Purple sobre WiFi Analytics - Presence e Presence (Legacy). Uma ressalva desses documentos: os dados de visitantes não autenticados podem demorar mais tempo a processar do que os dados de visitantes autenticados.

Mantenha-se nativo se gere um único parque Aruba, necessita de padrões de ocupação e permanência anónimos, e tem um engenheiro que possa assumir a calibração e o fluxo de API.

Adicione uma camada de plataforma quando se verificar qualquer uma destas situações: opera hardware misto; compara e classifica muitos locais entre si; ou necessita de dados de visitantes identificados e consentidos para marketing ou design de serviços. Isto aplica-se a hotéis que criam perfis de hóspedes e a cadeias de retalho que associam visitas a campanhas. O Purple funciona em mais de 80 000 locais ativos e processou 440 milhões de inícios de sessão em 2024 (dados do próprio Purple). A maioria desses locais utiliza hardware que já estava instalado.

Perguntas frequentes

A análise de presença está incluída na minha licença do Aruba Central?

Não em todos os casos. A análise de presença faz parte de níveis de subscrição específicos do Aruba Central, por isso confirme se os APs em cada local possuem um nível que a inclua. Verifique a documentação de licenciamento atual da HPE em relação às subscrições atribuídas na sua conta Central antes de planear uma implementação. Se alguns locais tiverem um nível inferior, terá lacunas nos relatórios de todo o parque. Corrija primeiro o licenciamento e depois calibre.

O Purple funciona com os meus pontos de acesso HPE Aruba existentes?

Sim. O Purple é agnóstico em termos de hardware e funciona como uma sobreposição na cloud em pontos de acesso HPE Aruba, a par de Cisco Meraki, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Mantém a sua configuração do Aruba Central e os seus APs existentes. O Purple adiciona a Captive Portal, os dados de visitantes autenticados e a camada de análise por cima, pelo que não há projeto de substituição de hardware.

Posso exportar dados de presença do Aruba Central para um armazém de dados ou ferramenta de BI?

Sim, através da REST API do Central. Crie um cliente API no API Gateway, autentique com tokens OAuth 2.0 e chame os endpoints de análise de presença para agregados ao nível do local. Agende uma recolha diária por local, armazene os registos de data/hora em UTC e registe as definições de limiar em vigor. Como a retenção do Central é limitada, a sua exportação torna-se o registo de longo prazo para comparações ano a ano.

Os dados de presença WiFi são dados pessoais ao abrigo do GDPR?

Trate-os como dados pessoais. O Considerando 30 do GDPR designa os identificadores online fornecidos pelos dispositivos como informações que podem identificar uma pessoa, e a análise de presença processa endereços MAC. Conclua uma avaliação de impacto sobre a proteção de dados, coloque sinalética clara nas entradas e mantenha a retenção proporcional. As contagens agregadas apresentam menor risco do que os identificadores em bruto, mas a etapa de recolha continua a enquadrar-se no âmbito do regulamento.

Quanto tempo demora a configurar e calibrar o Aruba presence analytics?

Planeie uma ronda de validação de limites por local e, pelo menos, uma semana de validação. A ativação do serviço demora minutos. A calibração implica caminhar pela entrada na hora de ponta, definir o limiar de RSSI e os limites de permanência, e depois comparar as contagens com caixas registadoras, check-ins ou contadores de portas. O pipeline de API é um trabalho de engenharia independente. Recalibre após qualquer remodelação, alteração de AP ou mudança de vidros.

A randomização de endereços MAC tornará as contagens de presença Aruba inúteis?

Não, mas limita o significado das contagens. O total de visitantes e os padrões de permanência continuam a ser utilizáveis quando validados face a uma fonte de dados real, como as transações de caixa. Os valores de visitas repetidas e de fidelização de dispositivos não autenticados não são fiáveis, porque um telemóvel pode apresentar vários endereços ao longo do tempo. Para obter dados fiáveis de visitas repetidas, precisa de visitantes autenticados que iniciem sessão através de um captive portal com consentimento.

Devo escolher o Aruba Central presence analytics ou o Purple WiFi Analytics?

A maioria dos parques instalados Aruba executa ambos, porque respondem a perguntas diferentes. O Central fornece padrões anónimos de ocupação e permanência por local sem custos adicionais de licença, se o seu nível de subscrição o incluir. O Purple adiciona dados de visitantes autenticados e com consentimento, classificações entre vários locais e suporte para hardware misto. Mantenha-se no sistema nativo para contagens anónimas num parque de um único fornecedor. Adicione o Purple quando precisar de dados proprietários identificados.

Preciso de hardware novo para adicionar uma camada de análise identificada?

Não. O Purple funciona sobre os pontos de acesso HPE Aruba que já possui, pelo que não há necessidade de substituir equipamentos. A camada identificada provém de um captive portal com aceitações explícitas de livre escolha, e não de novos rádios. A sua configuração existente do Central, o presence analytics e as exportações de API continuam a funcionar em paralelo.