Analítica de ubicación de Cisco Meraki: qué incluye y dónde están sus límites

Los puntos de acceso Cisco Meraki incluyen analíticas de ubicación sin necesidad de una licencia independiente. Obtendrá vistas de proximidad, interacción y fidelización, un mapa de calor del plano de la planta y la API de escaneo para observaciones en bruto. Contabiliza dispositivos anónimos, no personas. La aleatorización de MAC debilita las cifras de visitas recurrentes, las vistas están delimitadas por red y no obtendrá visitantes identificados sin un Captive Portal.

¿Qué son las analíticas de ubicación de Cisco Meraki?

Las analíticas de ubicación de Cisco Meraki son los informes de presencia integrados en los puntos de acceso Meraki MR y en el panel de control de Meraki. Sus puntos de acceso detectan los dispositivos cercanos, incluidas sus solicitudes de sondeo (probe requests) y su tráfico. El panel de control transforma esas detecciones en recuentos, duraciones y patrones de visitas recurrentes para cada red.

Cisco incluye esta función con las soluciones inalámbricas de Meraki. Esto la convierte en el primer lugar al que recurren la mayoría de las instalaciones de Meraki para obtener datos de afluencia. De forma predeterminada, obtendrá cuatro elementos.

Las vistas de proximidad, interacción y fidelización

El panel de control agrupa los datos de presencia en tres vistas:

• Proximidad divide los dispositivos detectados en transeúntes, visitantes y conectados. Los transeúntes se detectan brevemente o con una intensidad de señal baja. Los visitantes se ven lo suficientemente cerca y durante el tiempo suficiente como para contabilizarse como dentro. Los dispositivos conectados se han unido a su WiFi.
• Interacción clasifica a los visitantes por tiempo de permanencia: 5-20 minutos, 20-60 minutos, 1-6 horas y más de 6 horas.
• Fidelización agrupa a los visitantes por frecuencia de retorno: primera vez, diarios, semanales y ocasionales.

La documentación sobre analíticas de ubicación de Cisco define los umbrales de señal y tiempo que respaldan cada categoría. Lea esas definiciones antes de presentar cualquier cifra a su junta directiva.

El mapa de calor de ubicación de Meraki

Ubique sus puntos de acceso de forma precisa en los planos cargados y el panel de control mostrará la densidad de dispositivos en todo el espacio. Estima la posición a partir del RSSI (indicador de intensidad de la señal recibida), la intensidad con la que cada punto de acceso detecta un dispositivo. Las estimaciones mejoran cuando varios puntos de acceso detectan el mismo dispositivo a la vez.

La API de escaneo de Meraki

La API de escaneo envía observaciones de dispositivos en bruto desde sus puntos de acceso a un servidor administrado por usted. Es la vía de salida del panel de control hacia su propia canalización de datos. A continuación explicamos cómo funciona.

¿Por qué son importantes los datos de presencia de Meraki para su recinto?

Los datos de presencia responden a preguntas que las cajas registradoras y los escáneres de entradas no pueden contestar. ¿Cuántas personas pasaron por la entrada sin entrar? ¿Cuánto tiempo se quedaron? ¿Qué zonas permanecieron vacías a las 15:00 un martes?

Los equipos de Retail interpretan la relación entre transeúntes y visitantes como un indicador de la conversión del escaparate. Los Hoteles utilizan el tiempo de permanencia en el bar del vestíbulo o en el spa para ver dónde pasan las tardes los huéspedes. Los equipos de gestión de recintos de Sanidad pueden dimensionar las salas de espera según los volúmenes de visitantes observados en lugar de basarse en listas de citas.

El atractivo es evidente. Los datos ya se están recopilando en un hardware de su propiedad. La pregunta útil es hasta dónde le llevan antes de que necesite más.

¿Cómo funciona la analítica de ubicación de Meraki?

Activación

La analítica de ubicación es una configuración a nivel de toda la red en el panel de control de Meraki. Se habilita por red y, a continuación, se ubica cada punto de acceso en su plano de planta. Sin una ubicación precisa, el mapa de calor y las estimaciones de coordenadas son puras conjeturas. Siga la documentación actual de Cisco para conocer los pasos, ya que los menús del panel de control cambian entre versiones.

Dos comprobaciones antes de confiar en cualquier cifra:

1. Confirme que cada punto de acceso esté fijado en la planta correcta y en la posición exacta.
2. Recopile unas semanas de datos de referencia antes de comparar periodos o instalaciones.

La densidad de puntos de acceso para la ubicación es una decisión de diseño, no una opción conmutable. Una red diseñada puramente para cobertura puede hacer que solo un punto de acceso detecte los dispositivos. Eso genera un recuento, pero una posición deficiente. Nuestras Buenas prácticas de red para recintos y empresas en 2026 cubren la ubicación y la densidad.

Interpretación de las tres vistas

Proximidad. Tenga en cuenta las proporciones, no el recuento bruto de transeúntes. Los transeúntes incluyen dispositivos detectados a través de paredes y ventanas, y la aleatorización de MAC infla la cifra, tal y como se explica más adelante. Los recuentos de visitantes y de dispositivos conectados son más estables.

Engagement. Esta es la vista más fiable para decisiones operativas, especialmente para dispositivos conectados. Un dispositivo conectado suele mantener una única dirección privada en su red durante toda la visita. Los dispositivos que nunca se conectan van rotando sus direcciones de sondeo, lo que puede dividir una visita larga en varias cortas. Compare el mismo grupo semana tras semana para evaluar si un cambio de distribución retuvo a las personas durante más tiempo.

Fidelización. Trate esta vista con la máxima precaución. Depende de reconocer la misma dirección de dispositivo en un día posterior, y los teléfonos modernos están diseñados precisamente para evitar eso. La sección de límites explica este efecto.

Uso de la API de escaneo de Meraki

La API de escaneo de Meraki es la forma en que su equipo de datos introduce observaciones brutas en su propio flujo de trabajo. La documentación de la API de escaneo de Cisco establece la versión actual y el esquema de carga útil. A grandes rasgos:

• Registra una URL de receptor en el panel de control. Meraki envía una solicitud de validación y su servidor debe devolver la cadena del validador que muestra el panel de control.
• A continuación, Meraki envía por POST cargas útiles de observaciones en JSON en lotes, aproximadamente una vez por minuto según la documentación de Cisco.
• Cada carga útil lleva un secreto compartido configurado por usted, de modo que su receptor pueda rechazar cualquier elemento que no proceda de su red.
• Las observaciones de WiFi y Bluetooth Low Energy (BLE) llegan como transmisiones independientes.
• Cada observación incluye la dirección MAC del cliente, el fabricante y el punto de acceso más cercano con su RSSI. Los dispositivos conectados también comunican el SSID.
• Las estimaciones de ubicación llegan como coordenadas x/y y latitud/longitud, con una cifra de varianza que muestra la confiabilidad de la estimación.

La API le otorga un control total. Puede definir sus propios criterios de visitante utilizando un umbral RSSI y un tiempo de permanencia mínimo adecuados para sus instalaciones. Puede descartar las posiciones cuya varianza sea demasiado amplia para resultar útil. Además, puede aplicar un algoritmo hash a las direcciones MAC en cuanto se registran, garantizando que los identificadores sin procesar nunca lleguen a su almacén de datos.

También le otorga la propiedad completa. Usted aloja el receptor, mantiene su disponibilidad, asimila los cambios de esquema entre versiones de la API y asume las obligaciones relativas al GDPR para los identificadores de dispositivos. Reserve tiempo de ingeniería para ello, no solo para la configuración inicial.

¿Cómo se integra con lo que ya está utilizando?

Tanto las vistas nativas de Meraki como la API de escaneo miden dispositivos. Un Captive Portal mide a las personas que han decidido identificarse. Un Captive Portal es la página web que ve un dispositivo antes de acceder a internet, donde el visitante inicia sesión o acepta los términos. Ambos responden a preguntas diferentes, por lo que la mayoría de las organizaciones maduras utilizan ambos.

Purple ejecuta el Captive Portal y WiFi Analytics como una capa en la nube sobre sus puntos de acceso Meraki existentes. Purple es independiente del hardware y funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet.

Capacidad	Vistas del panel de Meraki	API de escaneo de Meraki	Purple sobre Meraki
Qué mide	Recuento anónimo de dispositivos, tiempo de permanencia y frecuencia de retorno	Observaciones individuales no procesadas por dispositivo enviadas en lotes aproximadamente cada minuto	Visitantes registrados con un perfil y un registro de consentimiento
Alcance	Una red a la vez	Cada red que vincule a su receptor	Cada ubicación en un único panel de control
Historial	Período de retención publicado por Cisco para datos de ubicación	El que mantenga su propio almacén de datos	Alojado en la plataforma Purple (certificada ISO 27001)
Impacto de la aleatorización MAC	Fidelidad y visitantes ocasionales distorsionados	Misma distorsión, aunque se puede modelar	Visitas recurrentes asociadas al perfil de inicio de sesión
Identifica al visitante	No	No	Sí, mediante una autorización expresa y consciente
Consentimiento de marketing	No se captura	No se captura	Se captura en el inicio de sesión
Esfuerzo de gestión	Habilitar por red y ubicar puntos de acceso en los planos de planta	Crear, alojar y mantener un receptor, almacén y modelo de datos	Configurar el Captive Portal en Meraki, sin necesidad de nuevo hardware
Coste	Incluido con Meraki wireless	Incluido, más sus costes de alojamiento e ingeniería	Suscripción a Purple junto con su licencia de Meraki

¿Cuáles son los límites de los análisis de ubicación de Meraki?

Períodos de retención

El panel de control está diseñado para ofrecer vistas operativas recientes, no un historial de varios años. Cisco publica los períodos de retención en su documentación sobre retención de datos de Meraki. Consulte la cifra actual antes de comprometerse a ofrecer comparativas interanuales.

Si necesita un historial prolongado, transmita los datos a través de la API de escaneo a su propio almacén desde el primer día. La API envía las observaciones casi en tiempo real. No vuelve a reproducir el historial, por lo que cualquier dato que su receptor no haya capturado se perderá de forma permanente.

Su propio almacenamiento conlleva sus propias obligaciones. El principio de limitación del plazo de conservación del GDPR, artículo 5(1)(e), exige que no conserve los datos personales más tiempo del necesario. Establezca un periodo de retención, documéntelo y elimine los datos según lo programado.

Agregación a nivel de centro

Las vistas nativas están diseñadas en torno a una sola red, lo que suele significar un solo centro. Una red de 60 tiendas se convierte en 60 conjuntos de gráficos. Comparar varios centros implica exportar red por red o crear su propia canalización en la API de escaneo.

Las vistas nativas tampoco pueden indicarle si un comprador visitó sus tiendas de Leeds y Manchester en la misma semana. Cada red ve sus propios dispositivos y las direcciones aleatorias impiden cualquier intento de coincidencia entre centros.

Aleatorización de MAC y los segmentos de fidelización

Este es el límite más importante para un analista de datos. Desde iOS 14 y Android 10, los teléfonos utilizan por defecto una dirección MAC privada y aleatoria para cada red. Las solicitudes de sondeo de dispositivos que nunca se conectan llevan aún más tiempo utilizando direcciones aleatorias que cambian con frecuencia. Tanto Apple como Google documentan este comportamiento.

Los efectos en los datos de presencia de Meraki son predecibles:

• Aumento de transeúntes. Un teléfono que nunca se conecta puede aparecer como varios dispositivos a medida que su dirección de sondeo rota.
• Aumento de visitantes nuevos. Un teléfono que regresa pero no se conecta presenta una nueva dirección, por lo que el panel de control registra a un desconocido.
• Disminución de la fidelidad diaria y semanal. Las visitas repetidas no se contabilizan por la misma razón.

A los dispositivos conectados les va mejor, porque la dirección privada por red suele persistir en su SSID. Las versiones recientes de Apple añaden una opción de rotación que cambia incluso esa dirección con el tiempo. Es de esperar que la fidelidad de los dispositivos conectados disminuya a medida que aumente la adopción.

La regla práctica: informe sobre la fidelidad como una tendencia para los dispositivos conectados, nunca como una cuota absoluta de visitantes recurrentes. Nunca la presente a la empresa como "clientes habituales".

Sin capa de visitantes identificados

La analítica nativa nunca sabe quién es nadie. No tiene nombre, ni dirección de correo electrónico, ni registro de consentimiento, ni enlace a su CRM o sistema de gestión de propiedades. Puede ver que el tiempo de permanencia aumentó un 12 % en una zona, pero no puede enviar nada a esos visitantes ni medir lo que gastaron.

Esa capa necesita un Captive Portal donde los visitantes elijan identificarse. Guest WiFi de Purple captura datos de primera mano a través de opciones de inclusión voluntaria conscientes y se integra con plataformas de CRM y marketing. Las visitas repetidas se contabilizan entonces con respecto al perfil con el que inicia sesión un visitante, no solo con la dirección del dispositivo. Purple procesó 440 millones de inicios de sesión en más de 80 000 ubicaciones activas en 2024 (datos de Purple).

Cómo funciona la analítica de ubicación de Meraki en recintos reales

Los dos escenarios siguientes son ejemplos prácticos ilustrativos. Las cifras muestran el método, no los resultados de un centro específico.

Escenario 1: un minorista de moda con 60 tiendas que compara establecimientos

Situación. El equipo de analítica quería una clasificación semanal de tiendas según la permanencia de los compradores. Cada tienda operaba su propia red Meraki. Elaborar el informe implicaba abrir 60 paneles de control y copiar las cifras de interacción en una hoja de cálculo, lo que suponía aproximadamente un día de trabajo a la semana.

Lo que se hizo. El equipo de TI configuró un receptor de API de escaneo y le vinculó las 60 redes. Encriptaron las direcciones MAC a la llegada, aplicaron un único umbral RSSI en toda la propiedad y descartaron las observaciones con gran varianza. Establecieron un periodo de conservación de 13 meses, documentado en sus registros de GDPR.

Resultado. El informe semanal se convirtió en una consulta automatizada que cubría las 60 tiendas. El equipo también confirmó lo que ocultaban los segmentos de fidelización. En tiendas con poco uso de WiFi, más del 80% de los visitantes figuraban como nuevos, frente a una cifra mucho menor en los datos de la propia aplicación del minorista. La fidelización se eliminó del informe para la junta directiva y se sustituyó por la permanencia y las proporciones entre visitantes y transeúntes.

Escenario 2: un hotel de 200 habitaciones que busca fidelizar huéspedes

Situación. El equipo comercial interpretaba la vista de fidelización de Meraki como su métrica de huéspedes recurrentes. La vista mostraba la mayoría de los dispositivos como nuevos. Esto contradecía el sistema de reservas, que reflejaba una gran proporción de reservas repetidas.

Lo que se hizo. El equipo aceptó que los segmentos de fidelización miden direcciones de dispositivos, no huéspedes. Añadieron un Captive Portal de Purple en los puntos de acceso Meraki existentes, con consentimiento explícito de marketing al iniciar sesión. Mantuvieron la vista de interacción de Meraki para el tiempo de permanencia por zonas en el bar, el restaurante y el spa.

Resultado. Los huéspedes recurrentes ahora se identificaban al iniciar sesión en lugar de deducirse de las direcciones. Los huéspedes con consentimiento registrado pasaban al CRM para recibir ofertas previas a la llegada. Los datos de interacción siguieron guiando la asignación de personal en el bar. Si está especificando esto para un nuevo contrato, nuestra Lista de verificación de RFP para WiFi de hotel: autenticación, filtrado de contenido y marketing de invitados detalla las preguntas que debe hacerse.

¿Qué debería hacer a continuación?

Empiece por decidir qué pregunta intenta responder. El recuento de dispositivos y los visitantes identificados son productos distintos.

Su situación	Qué utilizar
Un solo centro, preguntas operativas sobre zonas y horas concurridas	Vistas del panel de control de Meraki y el mapa de calor de ubicación
Múltiples centros, un equipo de datos, necesidad de un historial amplio	API de escaneo de Meraki integrada en su propio almacén de datos
Necesidad de informar sobre visitas recurrentes con datos justificables	Captive Portal con inicios de sesión, no segmentos de fidelización por dispositivo
Necesidad de contactar con visitantes o vincular visitas con el gasto	Purple Guest WiFi y WiFi Analytics en Meraki
Capacidad de ingeniería limitada, múltiples centros	Purple WiFi Analytics en lugar de una canalización propia

A continuación, siga estos cuatro pasos:

1. Audite la ubicación en el plano en cada red antes de confiar en cualquier mapa de calor.
2. Elimine las cifras de fidelización de los informes ejecutivos hasta que pueda atribuirlas a visitantes con sesión iniciada.
3. Decida su periodo de conservación y transmita los datos a través de la API de escaneo desde ahora si necesita disponer de historial.
4. Añada una capa identificada mediante un Captive Portal allí donde necesite personas y no dispositivos.

Nada de esto requiere nuevos puntos de acceso. Nuestro blog Por qué su próxima actualización de WiFi no necesita nuevo hardware explica el enfoque superpuesto en Meraki.

Preguntas frecuentes

¿Se incluyen los análisis de ubicación de Cisco Meraki en la licencia de Meraki?

Sí, los análisis de ubicación y la API de escaneo se incluyen con las soluciones inalámbricas de Meraki sin coste adicional. No se paga nada extra por habilitar las vistas de proximidad, interacción y fidelización, o el mapa de calor de ubicación. La API de escaneo también está incluida. Sin embargo, usted asume el coste de alojar un receptor, almacenar las observaciones y mantener la infraestructura. Para una red multisitio, ese tiempo de ingeniería suele ser el coste más elevado.

¿Pueden los análisis de ubicación de Meraki decirme quiénes son mis visitantes?

No, los análisis de ubicación de Meraki cuentan dispositivos anónimos, no personas identificadas. Registran las direcciones de los dispositivos, la potencia de la señal y la posición estimada, sin nombre, correo electrónico ni registro de consentimiento. Para identificar a los visitantes, necesita un Captive Portal en el que elijan iniciar sesión. Purple añade esa capa sobre sus puntos de acceso Meraki existentes, capturando datos de primera fuente mediante suscripciones voluntarias y vinculando las visitas a un perfil.

¿Durante cuánto tiempo conserva Meraki los datos de los análisis de ubicación?

Meraki conserva los datos de ubicación durante el periodo establecido en la documentación publicada por Cisco sobre la retención de datos de Meraki. Consulte la cifra actual allí antes de planificar informes comparativos interanuales. Si necesita un historial más prolongado, transmita las observaciones a través de la API de escaneo a su propio almacenamiento desde el primer día. La API no reproduce datos pasados. Su propio almacenamiento deberá cumplir entonces con el principio de limitación del plazo de conservación del GDPR.

¿Son los datos de presencia de Meraki datos personales según el GDPR?

Sí, las direcciones MAC pueden considerarse datos personales en virtud del GDPR, ya que están relacionadas con un dispositivo portado por una persona identificable. La ICO del Reino Unido lo ha indicado en su guía sobre análisis de ubicación WiFi. Aplique funciones hash o descomponga las direcciones a la llegada, documente su base jurídica, establezca un periodo de retención y coloque señalización clara. Un Captive Portal añade el consentimiento explícito para uso de marketing.

¿Qué precisión tienen los datos de fidelidad de visitantes de Meraki?

Los datos de fidelidad de Meraki no son fiables como medida absoluta debido a la aleatorización de las direcciones MAC. Desde iOS 14 y Android 10, los teléfonos utilizan direcciones aleatorias que hacen que los dispositivos que regresan parezcan nuevos. Los recuentos de primera visita se inflan y los de visitas repetidas se reducen. Los dispositivos conectados ofrecen mayor estabilidad, ya que su dirección por red suele ser persistente. Utilice la fidelidad únicamente como una tendencia de dispositivos conectados y cuente las visitas repetidas a partir de los inicios de sesión.

¿Funciona Purple con mis puntos de acceso Cisco Meraki existentes?

Sí, Purple se ejecuta en sus puntos de acceso de Cisco Meraki existentes como una superposición en la nube. Configura el Captive Portal en Meraki y conserva su hardware y licencias actuales. Purple es independiente del hardware, por lo que el mismo enfoque funciona en HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Las redes con varios proveedores presentan informes a través de una sola vista de WiFi Analytics.\n\n### ¿Debo desarrollar sobre la API de escaneo de Meraki o utilizar una plataforma de analítica?\n\nDesarrolle sobre la API de escaneo si cuenta con un equipo de datos y desea un control total sobre las definiciones y el almacenamiento. Elija una plataforma si carece de capacidad de ingeniería o necesita visitantes identificados. La API solo proporciona observaciones de dispositivos sin procesar, por lo que seguirá enfrentándose a la aleatorización de MAC y no tendrá ningún registro de consentimiento. Muchas instalaciones utilizan ambos: la API para la permanencia de dispositivos y Purple para los visitantes registrados.