Análise de localização Cisco Meraki: o que obtém nativamente e onde se esgotam as funcionalidades

Os pontos de acesso Cisco Meraki incluem analítica de localização sem necessidade de uma licença separada. Obtém vistas de proximidade, envolvimento e fidelidade, um mapa de calor de planta baixa e a API de verificação para observações brutas. Conta dispositivos anónimos, não pessoas. A aleatorização de MAC enfraquece os números de visitas repetidas, as vistas são delimitadas por rede e não obtém visitantes identificados sem um Captive Portal.

O que é a analítica de localização da Cisco Meraki?

A analítica de localização da Cisco Meraki é o relatório de presença integrado nos pontos de acesso Meraki MR e no painel Meraki. Os seus pontos de acesso escutam dispositivos próximos, incluindo os seus pedidos de sondagem (probe requests) e o seu tráfego. O painel transforma essas deteções em contagens, durações e padrões de visitas repetidas para cada rede.

A Cisco inclui a funcionalidade no sistema sem fios Meraki. Isso faz com que seja o primeiro local onde a maioria das propriedades Meraki procura dados de afluência. Pronto a usar, obtém quatro coisas.

As vistas de proximidade, envolvimento e fidelidade

O painel agrupa os dados de presença em três vistas:

• Proximidade divide os dispositivos detetados em transeuntes, visitantes e ligados. Os transeuntes são ouvidos brevemente ou com fraca intensidade de sinal. Os visitantes são vistos suficientemente perto, por tempo suficiente, para contarem como estando no interior. Os dispositivos ligados aderiram ao seu WiFi.
• Envolvimento agrupa os visitantes por tempo de permanência: 5-20 minutos, 20-60 minutos, 1-6 horas e mais de 6 horas.
• Fidelidade agrupa os visitantes por frequência de regresso: primeira vez, diário, semanal e ocasional.

A documentação da analítica de localização da Cisco define os limiares de sinal e de tempo por trás de cada categoria. Leia essas definições antes de apresentar um número à sua administração.

O mapa de calor de localização Meraki

Posicione os seus pontos de acesso com precisão nas plantas baixas carregadas e o painel mostra a densidade de dispositivos no espaço. Estima a posição a partir do RSSI (indicador de intensidade do sinal recebido), a força com que cada ponto de acesso ouve um dispositivo. As estimativas melhoram quando vários pontos de acesso ouvem o mesmo dispositivo ao mesmo tempo.

A API de verificação Meraki

A API de verificação envia observações brutas dos dispositivos a partir dos seus pontos de acesso para um servidor gerido por si. É o caminho de saída do painel para o seu próprio pipeline de dados. Explicamos como funciona abaixo.

Por que motivo os dados de presença Meraki são importantes para o seu local?

Os dados de presença respondem a perguntas que as caixas registadoras e os leitores de bilhetes não conseguem responder. Quantas pessoas passaram pela entrada sem entrar? Quanto tempo permaneceram? Que zonas ficaram vazias às 15h de uma terça-feira?

As equipas de retalho interpretam a rácio de transeuntes para visitantes como uma métrica de conversão de fachada. Os hotéis utilizam o tempo de permanência no bar do lobby ou no spa para ver onde os hóspedes passam as suas noites. As equipas de gestão de instalações de saúde podem dimensionar as áreas de espera com base nos volumes de visitantes observados, em vez de listas de consultas.

O apelo é óbvio. Os dados já estão a ser recolhidos no hardware que possui. A questão útil é saber até onde estes o levam antes de precisar de mais.

Como funcionam as análises de localização Meraki?

Ativar a funcionalidade

As análises de localização são uma configuração a nível de toda a rede no painel de controlo Cisco Meraki. Ativa-a por rede e, em seguida, posiciona cada ponto de acesso na respetiva planta. Sem um posicionamento preciso, o mapa de calor e as estimativas de coordenadas são meras suposições. Siga a documentação atual da Cisco para ver os passos, uma vez que os menus do painel de controlo mudam entre versões.

Duas verificações antes de confiar em qualquer número:

1. Confirme que todos os pontos de acesso estão fixados no piso correto e na posição correta.
2. Recolha algumas semanas de dados de referência antes de comparar períodos ou locais.

A densidade de pontos de acesso para localização é uma decisão de conceção, não um botão de alternância. Uma rede projetada puramente para cobertura pode fazer com que os dispositivos sejam detetados por apenas um ponto de acesso. Isso produz uma contagem, mas uma posição fraca. As nossas Melhores Práticas de Rede para Recintos e Grandes Empresas em 2026 cobrem o posicionamento e a densidade.

Ler as três visualizações

Proximidade. Observe os rácios, não a contagem bruta de transeuntes. Os transeuntes incluem dispositivos detetados através de paredes e janelas, e a aleatorização de MAC inflaciona o valor, como explicado abaixo. As contagens de visitantes e de dispositivos ligados são mais estáveis.

Engagement. Esta é a visualização mais fiável para decisões operacionais, especialmente para dispositivos ligados. Um dispositivo ligado mantém geralmente um endereço privado na sua rede durante toda a visita. Os dispositivos que nunca se ligam alternam os seus endereços de sonda, o que pode dividir uma visita longa em várias curtas. Compare o mesmo segmento semana a semana para julgar se uma alteração de layout reteve as pessoas por mais tempo.

Fidelidade. Trate esta visualização com o máximo cuidado. Depende do reconhecimento do mesmo endereço de dispositivo num dia posterior, e os telemóveis modernos são concebidos exatamente para evitar isso. A secção de limites explica o efeito.

Utilizar a API de varredura Meraki

A API de varredura Meraki é a forma como a sua equipa de dados obtém observações brutas no seu próprio pipeline. A documentação da API de varredura da Cisco estabelece a versão atual e o esquema de payload. Em resumo:

• Regista um URL recetor no painel de controlo. A Meraki envia um pedido de validação e o seu servidor deve devolver a string do validador apresentada no painel de controlo.
• A Meraki envia depois payloads JSON de observações em lotes, aproximadamente uma vez por minuto, segundo a documentação da Cisco.
• Cada payload transporta um segredo partilhado definido por si, para que o seu recetor possa rejeitar tudo o que não tenha origem na sua rede.
• As observações WiFi e Bluetooth Low Energy (BLE) chegam como fluxos separados.
• Cada observação inclui o endereço MAC do cliente, o fabricante e o ponto de acesso mais próximo com o respetivo RSSI. Os dispositivos ligados também reportam o SSID.
• As estimativas de localização chegam como coordenadas x/y e latitude/longitude, com um valor de variância que mostra o grau de confiança da estimativa.

A API dá-lhe o controlo. Define a sua própria definição de visitante, utilizando um limiar de RSSI e uma permanência mínima adequados ao seu edifício. Pode descartar posições cuja variação seja demasiado ampla para ser útil. Pode fazer o hash de endereços MAC à chegada, para que os identificadores brutos nunca cheguem ao seu armazém de dados.

Também lhe concede a propriedade. Aloja o recetor, mantém-no disponível, absorve alterações de esquema entre versões da API e assume as obrigações do GDPR relativas aos identificadores de dispositivos. Reserve tempo de engenharia para isso, e não apenas para a construção inicial.

Onde se enquadra juntamente com o que já executa?

As visualizações nativas da Meraki e a API de varrimento medem ambas dispositivos. Um portal cativo mede pessoas que escolheram identificar-se. Um portal cativo é a página web que um dispositivo vê antes de obter acesso à internet, onde o visitante inicia sessão ou aceita os termos. Os dois respondem a perguntas diferentes, pelo que a maioria das infraestruturas maduras executa ambos.

A Purple executa o portal cativo e a Análise de WiFi como uma sobreposição em nuvem nos seus pontos de acesso Meraki existentes. A Purple é agnóstica em relação ao hardware, funcionando em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

Funcionalidade	Visualizações do painel Meraki	API de varrimento Meraki	Purple na Meraki
O que mede	Contagens anónimas de dispositivos, tempo de permanência e frequência de regresso	Observações brutas por dispositivo em lotes, aproximadamente uma vez por minuto	Visitantes com sessão iniciada, com um perfil e um registo de consentimento
Âmbito	Uma rede de cada vez	Todas as redes que apontar para o seu recetor	Todos os locais num único painel de controlo
Histórico	Janela de retenção publicada pela Cisco para dados de localização	Tudo o que o seu próprio armazenamento mantiver	Mantido na plataforma Purple (certificação ISO 27001)
Impacto da aleatorização de MAC	Fidelização e transeuntes distorcidos	Mesma distorção, mas pode modelá-la	Visitas repetidas associadas ao perfil de início de sessão
Identifica o visitante	Não	Não	Sim, através de adesões por escolha consciente
Consentimento de marketing	Não capturado	Não capturado	Capturado no início de sessão
Esforço de execução	Ativar por rede, posicionar pontos de acesso nos planos de piso	Construir, alojar e manter um recetor, armazenamento e modelo de dados	Configurar o portal cativo na Meraki, sem novo hardware
Custo	Incluído com o wireless Meraki	Incluído, mais o seu tempo de alojamento e engenharia	Subscrição da Purple juntamente com a sua licença Meraki

Quais são os limites da análise de localização da Meraki?

Janelas de retenção

O painel foi concebido para visualizações operacionais recentes, não para históricos de vários anos. A Cisco publica os períodos de retenção na sua documentação de retenção de dados Meraki. Verifique o valor atual antes de prometer a alguém uma comparação ano a ano.

Se precisar de um histórico longo, faça o streaming através da API de varrimento para o seu próprio armazenamento desde o primeiro dia. A API envia observações em tempo quase real. Não reproduz o histórico, pelo que tudo o que o seu recetor tenha perdido é irrecuperável.

O seu próprio armazenamento implica as suas próprias obrigações. O princípio da limitação da conservação do GDPR, Artigo 5(1)(e), exige que não mantenha os dados pessoais durante mais tempo do que o necessário. Defina um período de retenção, documente-o e elimine dentro do prazo.

Agregação ao nível do local

As visualizações nativas são construídas em torno de uma única rede, o que geralmente significa um único local. Um património de 60 lojas transforma-se em 60 conjuntos de gráficos. A comparação entre locais significa exportar rede a rede ou criar a sua própria pipeline na API de verificação.

As visualizações nativas também não lhe conseguem dizer que um comprador visitou as suas lojas de Leeds e Manchester na mesma semana. Cada rede vê os seus próprios dispositivos, e os endereços aleatórios anulam qualquer tentativa de correspondência entre locais.

Aleatorização de MAC e os segmentos de fidelização

Este é o limite que mais importa para um analista de insights. Desde o iOS 14 e o Android 10, os telemóveis utilizam por predefinição um endereço MAC privado e aleatório para cada rede. Os pedidos de sondagem de dispositivos que nunca se ligam utilizam endereços aleatórios que mudam frequentemente há ainda mais tempo. A Apple e a Google documentam ambas este comportamento.

Os efeitos nos dados de presença da Meraki são previsíveis:

• Os transeuntes inflam. Um telemóvel que nunca se liga pode aparecer como vários dispositivos à medida que o seu endereço de sondagem altera.
• Os visitantes pela primeira vez inflam. Um telemóvel que regressa, mas não se liga, apresenta um novo endereço, pelo que o painel regista um estranho.
• A fidelização diária e semanal reduz. As visitas repetidas não são contadas pela mesma razão.

Os dispositivos ligados têm um desempenho melhor, porque o endereço privado por rede normalmente persiste no seu SSID. Lançamentos recentes da Apple adicionam uma opção rotativa que altera até mesmo esse endereço ao longo do tempo. Espere que a fidelização de dispositivos ligados diminua à medida que a adoção cresce.

A regra prática: comunique a fidelização como uma tendência para dispositivos ligados, nunca como uma quota absoluta de visitantes recorrentes. Nunca a apresente ao negócio como "clientes recorrentes".

Sem camada de visitantes identificados

A analítica nativa nunca sabe quem é cada pessoa. Não tem nome, nem endereço de e-mail, nem registo de consentimento, nem ligação ao seu CRM ou sistema de gestão de propriedades. Pode ver que o tempo de permanência aumentou 12% numa zona. Não pode enviar nada a esses visitantes nem medir o que gastaram.

Essa camada precisa de um Captive Portal onde os visitantes escolhem identificar-se. O Guest WiFi da Purple recolhe dados de primeira parte através de autorizações por escolha consciente e integra-se com plataformas de CRM e marketing. As visitas repetidas são então contadas em relação ao perfil com que o visitante inicia sessão, e não apenas pelo endereço do dispositivo. A Purple processou 440 milhões de inícios de sessão em mais de 80 000 locais ativos em 2024 (dados da Purple).

Como a analítica de localização da Meraki se comporta em locais reais

Os dois cenários abaixo são exemplos práticos ilustrativos. Os valores mostram o método, não os resultados de um local específico.

Cenário 1: um retalhista de moda com 60 lojas a comparar estabelecimentos

Situação. A equipa de estatísticas pretendia uma classificação semanal das lojas por tempo de permanência dos clientes. Cada loja operava a sua própria rede Meraki. Elaborar o relatório significava abrir 60 painéis de controlo e copiar os valores de envolvimento para uma folha de cálculo, cerca de um dia de trabalho por semana.

O que foi feito. A equipa de TI configurou um recetor de API de varrimento e apontou todas as 60 redes para ele. Anonimizaram os endereços MAC à chegada, aplicaram um limite de RSSI em toda a propriedade e eliminaram observações com grande variação. Definiram um período de retenção de 13 meses, documentado ao abrigo dos seus registos de GDPR.

Resultado. O relatório semanal tornou-se numa consulta automatizada que abrange todas as 60 lojas. A equipa também confirmou o que os segmentos de fidelização estavam a ocultar. Em lojas com pouca adesão ao WiFi, mais de 80% dos visitantes eram registados como sendo pela primeira vez, em comparação com um valor muito inferior nos dados da própria aplicação do retalhista. A fidelização foi removida do conjunto de relatórios da administração e substituída pelo tempo de permanência e pelos rácio de visitantes em relação a transeuntes.

Cenário 2: um hotel de 200 quartos em busca de hóspedes recorrentes

Situação. A equipa comercial interpretava a visualização de fidelização da Meraki como a sua métrica de hóspedes recorrentes. A visualização mostrava a maioria dos dispositivos como sendo pela primeira vez. Isso contradizia o sistema de reservas, que mostrava uma grande quota de reservas repetidas.

O que foi feito. A equipa aceitou que os segmentos de fidelização medem endereços de dispositivos e não hóspedes. Adicionaram um Captive Portal da Purple nos pontos de acesso Meraki existentes, com opt-ins de marketing de escolha consciente no início de sessão. Mantiveram a visualização de envolvimento da Meraki para o tempo de permanência por zonas no bar, restaurante e spa.

Resultado. Os hóspedes recorrentes passaram a ser identificados no início de sessão em vez de serem deduzidos através de endereços. Os hóspedes com opt-in ativo passaram diretamente para o CRM para ofertas antes da chegada. Os dados de envolvimento continuaram a orientar a gestão de pessoal no bar. Se estiver a especificar isto para um novo contrato, a nossa Lista de verificação RFP para WiFi de hotel: autenticação, filtragem de conteúdos e marketing de hóspedes apresenta as perguntas que deve fazer.

O que deve fazer a seguir?

Comece por decidir qual é a pergunta a que está a tentar responder. As contagens de dispositivos e os visitantes identificados são produtos diferentes.

A sua situação	O que utilizar
Um local, questões operacionais sobre zonas e horários de pico	Visualizações do painel de controlo Meraki e o mapa de calor de localização
Vários locais, uma equipa de dados, necessidade de histórico longo	API de varrimento da Meraki integrada no seu próprio repositório de dados
Necessidade de relatar visitas repetidas de forma justificável	Captive Portal com inícios de sessão, em vez de segmentos de fidelização por dispositivo
Necessidade de contactar visitantes ou associar visitas a consumos	Purple Guest WiFi e WiFi Analytics em Meraki
Capacidade de engenharia limitada, múltiplos locais	Purple WiFi Analytics em vez de uma infraestrutura desenvolvida internamente

Depois, siga estes quatro passos:

1. Audite a disposição da planta em cada rede antes de confiar em qualquer mapa de calor.
2. Remova os dados de fidelização dos relatórios executivos até que os possa atribuir a visitantes com início de sessão efetuado.
3. Decida o seu período de retenção e comece a transmitir dados através da API de varrimento agora, se precisar de histórico.
4. Adicione uma camada identificada através de um Captive Portal onde precisa de pessoas, não de dispositivos.

Nada disto necessita de novos pontos de acesso. O nosso blog Why your next WiFi upgrade doesn't need new hardware explica a abordagem de sobreposição no Meraki.

Perguntas frequentes

A análise de localização do Cisco Meraki está incluída na licença Meraki?

Sim, a análise de localização e a API de verificação vêm com a rede sem fios Meraki sem qualquer custo adicional. Não paga nada mais para ativar as visualizações de proximidade, envolvimento e fidelização ou o mapa de calor de localização. A API de verificação também está incluída. No entanto, suporta os custos de alojamento de um recetor, armazenamento de observações e manutenção do fluxo de dados. Para uma propriedade com vários locais, esse tempo de engenharia é normalmente o custo maior.

A análise de localização do Meraki pode dizer-me quem são os meus visitantes?

Não, a análise de localização do Meraki conta dispositivos anónimos, não pessoas identificadas. Regista endereços de dispositivos, intensidade de sinal e posição estimada, sem nome, e-mail ou registo de consentimento. Para identificar os visitantes, precisa de um Captive Portal onde estes optem por iniciar sessão. O Purple adiciona essa camada aos seus pontos de acesso Meraki existentes, capturando dados de primeira parte através de adesões por escolha consciente e associando as visitas a um perfil.

Durante quanto tempo o Meraki guarda os dados de análise de localização?

O Meraki guarda os dados de localização pelo período definido na documentação publicada da Cisco sobre retenção de dados Meraki. Verifique o valor atual aí contido antes de planejar relatórios homólogos. Se precisar de um histórico mais longo, transmita as observações através da API de verificação para o seu próprio armazenamento desde o primeiro dia. A API não reproduz dados passados. O seu próprio armazenamento deve depois seguir o princípio de limitação da conservação do GDPR.

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

Sim, os endereços MAC podem contar como dados pessoais ao abrigo do GDPR, porque se relacionam com um dispositivo transportado por uma pessoa identificável. O ICO do Reino Unido declarou-o na sua orientação sobre análise de localização por WiFi. Aplique hash ou truncagem aos endereços à chegada, documente a sua base legal, defina um período de retenção e afixe sinalética clara. Um Captive Portal adiciona consentimento explícito para utilização em marketing.

Qual é a precisão dos dados de fidelização de visitantes do Meraki?

Os dados de fidelização do Meraki não são fiáveis como medida absoluta devido à aleatorização de MAC. Desde o iOS 14 e o Android 10, os telemóveis utilizam endereços aleatórios que fazem com que os dispositivos que regressam pareçam novos. As contagens de primeira visita inflam e as contagens de visitas repetidas desflam. Os dispositivos ligados são mais estáveis, porque o seu endereço por rede geralmente persiste. Utilize a fidelização apenas como uma tendência de dispositivos ligados e conte os visitantes repetidos a partir dos inícios de sessão.

O Purple funciona com os meus pontos de acesso Cisco Meraki existentes?

Sim, o Purple é executado nos seus pontos de acesso Cisco Meraki existentes como uma sobreposição na nuvem. Configura o captive portal no Meraki e mantém o seu hardware e licenças atuais. O Purple é agnóstico em relação ao hardware, pelo que a mesma abordagem funciona em HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. As infraestruturas com vários fornecedores apresentam relatórios através de uma única vista de WiFi Analytics.\n\n### Devo criar com base na API de varrimento do Meraki ou utilizar uma plataforma de analítica?\n\nCrie com base na API de varrimento se tiver uma equipa de dados e pretender controlo total sobre as definições e o armazenamento. Escolha uma plataforma se não tiver capacidade de engenharia ou se precisar de identificar visitantes. A API fornece apenas observações brutas de dispositivos, pelo que continua a enfrentar a aleatorização de endereços MAC e não tem qualquer registo de consentimento. Muitas infraestruturas utilizam ambos: a API para o tempo de permanência do dispositivo e o Purple para visitantes com sessão iniciada.