Análise de localização Cisco Meraki: o que você obtém nativamente e onde ela limita-se

Os pontos de acesso Cisco Meraki incluem análise de localização sem a necessidade de uma licença separada. Você obtém visualizações de proximidade, engajamento e fidelidade, um mapa de calor da planta baixa e a API de verificação para observações brutas. Ele conta dispositivos anônimos, não pessoas. A randomização de MAC enfraquece os números de visitas repetidas, as visualizações são delimitadas por rede e você não obtém visitantes identificados sem um Captive Portal.

O que é a análise de localização do Cisco Meraki?

A análise de localização do Cisco Meraki é o relatório de presença integrado aos pontos de acesso Meraki MR e ao painel da Meraki. Seus pontos de acesso escutam dispositivos próximos, incluindo suas solicitações de sondagem (probe requests) e seu tráfego. O painel transforma essas detecções em contagens, durações e padrões de visitas repetidas para cada rede.

A Cisco inclui o recurso no Meraki wireless. Isso o torna o primeiro lugar que a maioria das estruturas Meraki consulta para obter dados de fluxo de visitantes. Pronto para uso, você recebe quatro coisas.

As visualizações de proximidade, engajamento e fidelidade

O painel agrupa os dados de presença em três visualizações:

• Proximidade divide os dispositivos detectados em transeuntes, visitantes e conectados. Os transeuntes são ouvidos brevemente ou com sinal fraco. Os visitantes são vistos perto o suficiente, por tempo suficiente, para serem contados como dentro do local. Dispositivos conectados ingressaram no seu WiFi.
• Engajamento agrupa os visitantes por tempo de permanência: 5-20 minutos, 20-60 minutos, 1-6 horas e 6+ horas.
• Fidelidade agrupa os visitantes por frequência de retorno: primeira vez, diário, semanal e ocasional.

A documentação de análise de localização da Cisco define os limites de sinal e tempo por trás de cada categoria. Leia essas definições antes de apresentar um número à sua diretoria.

O mapa de calor de localização Meraki

Posicione seus pontos de acesso com precisão nas plantas baixas carregadas e o painel mostrará a densidade de dispositivos no espaço. Ele 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 de dispositivos dos seus pontos de acesso para um servidor que você executa. É o caminho para sair do painel e entrar na sua própria estrutura de dados. Explicamos como ela funciona abaixo.

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

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

Equipes de Varejo interpretam a proporção entre transeuntes e visitantes como um indicador para a conversão de fachada. Hotéis usam o tempo de permanência no bar do saguão ou no spa para ver onde os hóspedes passam as noites. Equipes de instalações de Saúde podem dimensionar áreas de espera com base nos volumes de visitantes observados, em vez de listas de consultas.

O apelo é óbvio. Os dados já estão sendo coletados no hardware que você possui. A pergunta útil é até onde eles te levam antes que você precise de mais.

Como funciona a análise de localização do Meraki?

Ativando o recurso

A análise de localização é uma configuração para toda a rede no painel do Meraki. Você a habilita por rede e, em seguida, posiciona cada ponto de acesso em sua planta baixa. Sem um posicionamento preciso, o mapa de calor e as estimativas de coordenadas não passam de adivinhação. Siga a documentação atual da Cisco para ver os passos, pois os menus do painel mudam entre as versões.

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

1. Confirme se cada ponto de acesso está fixado no andar correto e na posição correta.
2. Colete algumas semanas de dados de referência antes de comparar períodos ou locais.

A densidade do ponto de acesso para localização é uma decisão de projeto, não uma simples chave de alternância. Uma rede projetada puramente para cobertura pode fazer com que os dispositivos sejam detectados por apenas um ponto de acesso. Isso gera uma contagem, mas uma posição imprecisa. Nosso artigo Melhores Práticas de Rede para Locais de Eventos e Empresas em 2026 aborda posicionamento e densidade.

Lendo as três visualizações

Proximidade. Observe as proporções, não a contagem bruta de pessoas que passam. Pessoas que passam incluem dispositivos detectados através de paredes e janelas, e a randomização de MAC infla esse número, conforme explicado abaixo. As contagens de visitantes e de dispositivos conectados são mais estáveis.

Engajamento. Esta é a visualização mais confiável para decisões operacionais, especialmente para dispositivos conectados. Um dispositivo conectado geralmente mantém um endereço privado em sua rede durante toda a visita. Dispositivos que nunca se conectam alternam seus endereços de sonda, o que pode dividir uma visita longa em várias visitas curtas. Compare o mesmo período semana a semana para avaliar se uma alteração no layout reteve as pessoas por mais tempo.

Fidelidade. Trate esta visualização com o máximo de cautela. Ela depende do reconhecimento do mesmo endereço de dispositivo em um dia posterior, e os telefones modernos foram projetados exatamente para impedir isso. A seção de limitações explica esse efeito.

Usando a API de varredura do Meraki

A API de varredura do Meraki é a forma como sua equipe de dados obtém observações brutas em seu próprio fluxo de trabalho. A documentação da API de varredura da Cisco apresenta a versão atual e o esquema de carga útil. Em resumo:

• Você registra um URL receptor no painel. O Meraki envia uma solicitação de validação e seu servidor deve retornar a string validadora exibida no painel.
• Em seguida, o Meraki envia cargas úteis JSON de observações em lotes, aproximadamente uma vez por minuto, de acordo com a documentação da Cisco.
• Cada carga útil carrega um segredo compartilhado que você define, para que seu receptor possa rejeitar qualquer coisa que não tenha vindo da sua rede.
• As observações de 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 seu RSSI. Dispositivos conectados também informam o SSID.
• As estimativas de localização chegam como coordenadas x/y e latitude/longitude, com um número de variação que mostra o grau de confiança da estimativa.

A API coloca o controle em suas mãos. Você define sua própria definição de visitante, usando um limite de RSSI e tempo mínimo de permanência adequados ao seu edifício. É possível descartar posições cuja variação seja ampla demais para ser útil. Você pode aplicar hash aos endereços MAC na chegada para que identificadores brutos nunca cheguem ao seu armazenamento de dados.

Ela também transfere a propriedade para você. Você hospeda o receptor, o mantém disponível, absorve mudanças de esquema entre versões da API e cumpre as obrigações da GDPR para identificadores de dispositivos. Reserve tempo da equipe de engenharia para isso, e não apenas para a construção inicial.

Onde ela se posiciona em relação ao que você já executa?

As visualizações nativas da Meraki e a API de varredura medem dispositivos. Um Captive Portal mede pessoas que optaram por se identificar. Um Captive Portal é a página web que um dispositivo visualiza antes de obter acesso à internet, onde o visitante faz login ou aceita os termos. Os dois respondem a perguntas diferentes, portanto, a maioria das empresas consolidadas utiliza ambos.

A Purple executa Captive Portal e WiFi Analytics como uma sobreposição em nuvem nos seus pontos de acesso Meraki existentes. A Purple é independente de hardware, funcionando com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet.

Recurso	Visualizações do painel Meraki	API de varredura Meraki	Purple no Meraki
O que mede	Contagem de dispositivos anônimos, tempo de permanência e frequência de retorno	Observações brutas por dispositivo em lotes aproximadamente uma vez por minuto	Visitantes conectados com um perfil e um registro de consentimento
Escopo	Uma rede por vez	Todas as redes que você apontar para o seu receptor	Todos os locais em um único painel de controle
Histórico	Janela de retenção publicada pela Cisco para dados de localização	O que seu próprio armazenamento mantiver	Mantido na plataforma Purple (certificação ISO 27001)
Impacto da randomização de MAC	Fidelidade e transeuntes distorcidos	Mesma distorção, mas você pode modelá-la	Visitas repetidas associadas ao perfil de login
Identifica o visitante	Não	Não	Sim, por meio de opt-ins de escolha consciente
Consentimento de marketing	Não capturado	Não capturado	Capturado no login
Esforço para executar	Ativar por rede, posicionar pontos de acesso nas plantas baixas	Criar, hospedar e manter um receptor, armazenamento e modelo de dados	Configurar o Captive Portal no Meraki, sem novos hardwares
Custo	Incluído no Meraki wireless	Incluído, mais seu tempo de hospedagem e engenharia	Assinatura da Purple junto com sua licença Meraki

Quais são os limites do Meraki location analytics?

Janelas de retenção

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

Se você precisa de um histórico longo, faça o streaming por meio da API de varredura para o seu próprio armazenamento desde o primeiro dia. A API envia observações em tempo quase real. Ela não reexibe o histórico, portanto, qualquer informação que seu receptor tenha perdido será perdida definitivamente.

Seu próprio armazenamento traz suas próprias obrigações. O princípio de limitação de conservação do GDPR, Artigo 5(1)(e), exige que você não guarde dados pessoais por mais tempo do que o necessário. Defina um período de retenção, documente-o e exclua conforme o cronograma.

Agregação em nível de local

As visualizações nativas são construídas em torno de uma única rede, o que geralmente significa um único local. Uma rede de 60 lojas se torna 60 conjuntos de gráficos. A comparação entre locais significa exportar rede por rede ou criar seu próprio pipeline na API de escaneamento.

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

Randomização de MAC e as categorias de fidelidade

Este é o limite que mais importa para um analista de insights. Desde o iOS 14 e o Android 10, os telefones usam um endereço MAC privado e randomizado para cada rede por padrão. As solicitações de sondagem (probe requests) de dispositivos que nunca se conectam usam endereços randomizados que mudam frequentemente há ainda mais tempo. A Apple e o Google documentam esse comportamento.

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

• Transeuntes inflacionam. Um telefone que nunca se conecta pode aparecer como vários dispositivos à medida que seu endereço de sondagem rotaciona.
• Visitantes de primeira viagem inflacionam. Um telefone que retorna, mas não se conecta, apresenta um novo endereço, fazendo com que o painel registre um estranho.
• A fidelidade diária e semanal deflaciona. Visitas repetidas deixam de ser contadas pelo mesmo motivo.

Dispositivos conectados se saem melhor, porque o endereço privado por rede geralmente persiste no seu SSID. Lançamentos recentes da Apple adicionam uma opção de rotação que altera até mesmo esse endereço ao longo do tempo. Espere que a fidelidade de dispositivos conectados diminua à medida que a adoção crescer.

A regra prática: informe a fidelidade como uma tendência para dispositivos conectados, nunca como uma parcela absoluta de visitantes recorrentes. Nunca apresente isso para a empresa como "clientes recorrentes".

Sem camada de visitantes identificados

A análise nativa nunca sabe quem é a pessoa. Ela não tem nome, endereço de e-mail, registro de consentimento e nenhum vínculo com seu CRM ou sistema de gestão de propriedades. Você pode ver que o tempo de permanência aumentou 12% em uma zona. Você não pode enviar nada a esses visitantes nem medir o que eles gastaram.

Essa camada precisa de um Captive Portal onde os visitantes optam por se identificar. O Guest WiFi da Purple captura dados primários (first-party data) por meio de opt-ins de escolha consciente e se integra a plataformas de CRM e marketing. As visitas repetidas são então contadas em relação ao perfil com o qual o visitante faz login, e não apenas pelo endereço do dispositivo. A Purple processou 440 milhões de logins em mais de 80.000 locais ativos em 2024 (dados da Purple).

Como a análise de localização da Meraki funciona em locais reais

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

Cenário 1: um varejista de moda com 60 lojas comparando estabelecimentos

Situação. A equipe de insights queria um ranking semanal de lojas por tempo de permanência dos clientes. Cada loja operava sua própria rede Meraki. Criar o relatório significava abrir 60 painéis e copiar dados de engajamento em uma planilha, cerca de um dia de trabalho por semana.

O que foi feito. A equipe de TI configurou um receptor de API de varredura e direcionou todas as 60 redes para ele. Eles aplicaram hash nos endereços MAC na chegada, aplicaram um único limite de RSSI em todo o patrimônio e descartaram observações com grande variação. Definiram um período de retenção de 13 meses, documentado em seus registros de GDPR.

Resultado. O relatório semanal tornou-se uma consulta automatizada cobrindo todas as 60 lojas. A equipe também confirmou o que as categorias de fidelidade estavam ocultando. Em lojas com pouca adesão ao WiFi, mais de 80% dos visitantes foram registrados como novos, em comparação com um número muito menor nos dados do próprio aplicativo do varejista. A fidelidade foi removida do pacote da diretoria e substituída pelo tempo de permanência e pelas proporções de visitantes em relação a passantes.

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

Situação. A equipe comercial interpretou a visualização de fidelidade do Meraki como sua métrica de hóspedes recorrentes. A visualização mostrava a maioria dos dispositivos como novos. Isso contradizia o sistema de reservas, que mostrava uma grande parcela de reservas repetidas.

O que foi feito. A equipe aceitou que as categorias de fidelidade medem endereços de dispositivos, não hóspedes. Eles adicionaram um Captive Portal da Purple nos pontos de acesso Meraki existentes, com opt-ins de marketing de escolha consciente no login. Eles mantiveram a visualização de engajamento do Meraki para o tempo de permanência por zona no bar, restaurante e spa.

Resultado. Os hóspedes recorrentes passaram a ser identificados no login, em vez de inferidos por endereços. Os hóspedes que optaram por participar foram direcionados ao CRM para ofertas pré-chegada. Os dados de engajamento continuaram a orientar o dimensionamento da equipe no bar. Se você estiver especificando isso para um novo contrato, nosso Checklist de RFP para WiFi de hotéis: autenticação, filtragem de conteúdo e marketing de hóspedes lista as perguntas a serem feitas.

O que você deve fazer a seguir?

Comece decidindo qual pergunta você está tentando responder. Contagens de dispositivos e visitantes identificados são produtos diferentes.

Sua situação	O que usar
Um local, dúvidas operacionais sobre zonas e horários de pico	Visualizações do painel Meraki e o mapa de calor de localização
Vários locais, uma equipe de dados, necessidade de histórico longo	API de varredura do Meraki integrada ao seu próprio repositório
Necessidade de relatar visitas recorrentes de forma defensável	Captive Portal com logins, não categorias de fidelidade de dispositivos
Necessidade de contatar visitantes ou vincular visitas a gastos	Purple Guest WiFi e WiFi Analytics no Meraki
Capacidade limitada de engenharia, muitos locais	Purple WiFi Analytics em vez de um fluxo criado por conta própria

Em seguida, siga quatro etapas:

1. Audite o posicionamento na planta de cada rede antes de confiar em qualquer mapa de calor.
2. Remova os dados de fidelidade dos relatórios executivos até poder atribuí-los a visitantes conectados.
3. Decida seu período de retenção e faça o streaming pela API de varredura agora se precisar de histórico.
4. Adicione uma camada identificada por meio de um Captive Portal onde você precisa de pessoas, não de dispositivos.

Nada disso exige novos pontos de acesso. Nosso blog Por que sua próxima atualização de WiFi não precisa de novo hardware explica a abordagem de sobreposição na Meraki.

Perguntas frequentes

O Cisco Meraki location analytics está incluído na licença Meraki?

Sim, o location analytics e a API de verificação acompanham o Meraki sem fio sem cobrança separada. Você não paga nada a mais para ativar as visualizações de proximidade, engajamento e fidelidade ou o mapa de calor de localização. A API de verificação também está incluída. No entanto, você arca com o custo de hospedar um receptor, armazenar observações e manter o fluxo de dados. Para uma empresa com vários locais, esse tempo de engenharia é geralmente o maior custo.

O Meraki location analytics pode me dizer quem são meus visitantes?

Não, o Meraki location analytics conta dispositivos anônimos, não pessoas identificadas. Ele registra endereços de dispositivos, intensidade de sinal e posição estimada, sem nome, e-mail ou registro de consentimento. Para identificar visitantes, você precisa de um Captive Portal onde eles optem por fazer login. O Purple adiciona essa camada aos seus pontos de acesso Meraki existentes, capturando dados primários por meio de adesões por escolha consciente e vinculando visitas a um perfil.

Por quanto tempo a Meraki mantém os dados de location analytics?

A Meraki mantém os dados de localização pelo período definido na documentação oficial de retenção de dados da Meraki da Cisco. Verifique o valor atual lá antes de planejar relatórios comparativos anuais. Se precisar de um histórico mais longo, transmita as observações por meio da API de verificação para seu próprio armazenamento desde o primeiro dia. A API não reproduz dados passados. Seu próprio armazenamento deve, então, seguir o princípio de limitação de armazenamento do GDPR.

Os dados de presença da Meraki são dados pessoais de acordo com o GDPR?

Sim, os endereços MAC podem ser considerados dados pessoais de acordo com o GDPR, pois se referem a um dispositivo transportado por uma pessoa identificável. O ICO do Reino Unido afirmou isso em suas orientações sobre location analytics de WiFi. Aplique hash ou truncamento aos endereços na chegada, documente sua base legal, defina um período de retenção e exiba sinalização clara. Um Captive Portal adiciona consentimento explícito para uso em marketing.

Quão precisos são os dados de fidelidade de visitantes da Meraki?

Os dados de fidelidade da Meraki não são confiáveis como uma medida absoluta devido à randomização de MAC. Desde o iOS 14 e o Android 10, os telefones usam endereços randomizados que fazem com que dispositivos antigos pareçam novos. As contagens de primeira visita inflam e as contagens de visitas repetidas desinflam. Os dispositivos conectados são mais estáveis, porque seu endereço por rede geralmente persiste. Use a fidelidade apenas como uma tendência de dispositivos conectados e conte os visitantes recorrentes a partir dos logins.

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

Sim, o Purple roda nos seus pontos de acesso Cisco Meraki existentes como uma sobreposição em nuvem. Você configura o Captive Portal no Meraki e mantém seu hardware e licenças atuais. O Purple é agnóstico em relação ao hardware, então a mesma abordagem funciona em HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Ambientes de múltiplos fornecedores geram relatórios por meio de uma única visualização do WiFi Analytics.

Devo criar na API de scanning do Meraki ou usar uma plataforma de analytics?

Crie na API de scanning se você tiver uma equipe de dados e quiser controle total sobre definições e armazenamento. Escolha uma plataforma se não tiver capacidade de engenharia ou precisar de visitantes identificados. A API fornece apenas observações brutas de dispositivos, portanto você ainda enfrentará a randomização de MAC e não terá registro de consentimento. Muitos ambientes usam ambos: a API para permanência de dispositivos e o Purple para visitantes conectados.