Saltar al contenido principal

Microsoft Dynamics 365 and Guest WiFi Data Enrichment

Esta guía de referencia técnica detalla la arquitectura, el modelado de datos y el mapeo de campos necesarios para integrar los datos de WiFi de invitados con Microsoft Dynamics 365. Proporciona estrategias de implementación prácticas para directores de TI y arquitectos de redes con el fin de enriquecer los perfiles unificados de clientes e impulsar un ROI medible en espacios físicos.

📖 6 min de lectura📝 1,377 palabras🔧 2 ejemplos prácticos3 preguntas de práctica📚 8 definiciones clave

header_image.png

Resumen Ejecutivo

Para los espacios físicos modernos —desde cadenas de retail hasta estadios a gran escala— comprender el comportamiento de los clientes ya no es opcional. Sin embargo, mientras que las plataformas de comercio electrónico ofrecen análisis de comportamiento detallados, los espacios físicos a menudo se enfrentan a un punto ciego: saben qué compró un cliente, pero no cuánto tiempo permaneció, con qué frecuencia los visita sin comprar o qué zonas frecuenta. Al integrar los datos de autenticación de Guest WiFi con Microsoft Dynamics 365, los responsables de TI pueden cerrar esta brecha.

Esta guía describe la arquitectura definitiva para la integración de Dynamics 365 WiFi. Detalla cómo enviar datos de contacto verificados, marcas de tiempo de consentimiento de GDPR y métricas de visitas desde la plataforma de análisis de WiFi a Dynamics 365. Fundamentalmente, aboga por un modelo de datos de dos niveles —separando las actualizaciones de contactos principales de los registros de visitas transaccionales de alto volumen— para garantizar el rendimiento del CRM y permitir una segmentación avanzada dentro de Customer Insights. Para las organizaciones de Retail y Hospitality , esta integración transforma el flujo de visitantes anónimos en un perfil de cliente unificado y accionable.

microsoft_dynamics_365_and_guest_wifi_data_enrichment_podcast.wav

Inmersión Técnica: Arquitectura y Flujo de Datos

La integración de WiFi para invitados con Dynamics 365 requiere una capa de middleware robusta para gestionar la resolución de identidad, la deduplicación y la transformación de la carga útil. Los datos brutos se originan en el extremo de la red —desde los puntos de acceso y los Captive Portals— y deben procesarse antes de ingresar al CRM.

architecture_overview.png

El Pipeline de Ingesta

Cuando un invitado se autentica a través del Captive Portal, la plataforma WiFi captura su dirección MAC, el método de autenticación (por ejemplo, inicio de sesión social, formulario de correo electrónico) y su consentimiento explícito para marketing. Este evento activa un webhook o una llamada de API REST que contiene una carga útil JSON.

El paso crítico aquí es la Resolución de Identidad. Los sistemas operativos móviles modernos emplean la aleatorización de direcciones MAC para mejorar la privacidad del usuario. Confiar únicamente en la dirección MAC como clave principal dará como resultado perfiles fragmentados y recuentos de visitas inexactos. Por lo tanto, la integración debe utilizar el identificador autenticado —normalmente la dirección de correo electrónico o el número de teléfono móvil— como clave principal para hacer coincidir los registros en Dynamics 365. La dirección MAC con hash solo debe utilizarse como identificador secundario para el seguimiento de la sesión dentro de una sola visita.

Estructura de Entidad de Dos Niveles

Un antipatrón de arquitectura común es intentar escribir cada sesión de WiFi directamente en la entidad principal Contact. Este enfoque satura rápidamente la base de datos, degrada el rendimiento del CRM y complica la generación de informes. En su lugar, una estructura de entidades de dos niveles es el estándar de la industria para la integración de WiFi con Dynamics CRM:

  1. La entidad Contact (Registro maestro): Esta entidad solo debe actualizarse cuando haya un cambio material en el perfil del invitado, como una nueva dirección de correo electrónico, un número de teléfono actualizado o un cambio en su estado de consentimiento de GDPR. También puede almacenar métricas agregadas, como cr_wifi_visit_count o cr_wifi_avg_dwell, que son útiles para una segmentación rápida.
  2. La entidad de visita personalizada (cr_wifiVisit): Esta es una tabla transaccional donde cada sesión de WiFi completada se registra como una fila distinta. Captura la hora de inicio de la sesión, la hora de finalización, la duración y el lugar o zona específicos (por ejemplo, "Lobby", "Sports Bar"). Esta entidad está vinculada a la entidad Contact a través de una relación de uno a varios (1:N).

Esta separación de conceptos es vital para aprovechar Microsoft Dynamics 365 Customer Insights. Al tratar la entidad cr_wifiVisit como un flujo de datos de comportamiento independiente, Customer Insights puede ingerir los registros y crear segmentos dinámicos basados en las interacciones físicas en el establecimiento, fusionándolos a la perfección con el historial de compras online.

Guía de implementación: mapeo de campos y sincronización

El éxito de la implementación depende de un mapeo de campos preciso y de una comprensión clara del sistema de registro.

Buenas prácticas de mapeo de campos

field_mapping_diagram.png

Al mapear campos desde la plataforma Purple a Dynamics 365, asegúrese de que los tipos de datos coincidan y de que se creen campos personalizados donde sea necesario.

Campo de origen de Purple WiFi Campo de destino de Dynamics 365 Tipo de datos Notas
Correo electrónico del invitado emailaddress1 String Clave primaria para la deduplicación.
Dirección MAC (Hachada) cr_device_mac_hash String Almacenar en la entidad de visita personalizada, no en el contacto.
Marca de tiempo de primera visita cr_wifi_first_visit DateTime Actualizar solo en la creación inicial del contacto.
Marca de tiempo de última visita cr_wifi_last_visit DateTime Actualizar en cada visita posterior.
Marca de tiempo de consentimiento cr_consent_wifi_date DateTime Crucial para las auditorías de cumplimiento.
Zona del establecimiento cr_wifi_zone_preference String Se puede agregar en el contacto o registrar por visita.

Estrategias de sincronización: tiempo real frente a lotes

La elección entre la sincronización en tiempo real y por lotes depende completamente del caso de uso empresarial.

  • Tiempo real (Webhooks): Esencial para la activación en el propio establecimiento. Si el equipo de marketing desea activar un correo electrónico automatizado de "Bienvenido de nuevo" o una oferta por SMS para un café gratis dentro de los cinco minutos posteriores a que el invitado se conecte a la red, los webhooks en tiempo real son obligatorios. Esto requiere una gestión sólida de la pasarela de API para gestionar los picos de tráfico durante las horas de mayor afluencia en el establecimiento.
  • Lotes (OData / Extracciones de API programadas): Si el objetivo principal es el análisis de WiFi a largo plazo ( WiFi Analytics ) y la creación de segmentos semanales, una sincronización por lotes nocturna es mucho más eficiente. Reduce la carga de la API en Dynamics 365 y permite la agregación de datos antes de la inserción.

Buenas prácticas de cumplimiento y seguridad

Al gestionar datos de invitados, el cumplimiento de marcos normativos como el GDPR y PCI DSS no es negociable. Para comprender mejor el cumplimiento, consulte nuestra guía ISO 27001 Guest WiFi: A Compliance Primer .

  1. El consentimiento es el sistema de registro: El Captive Portal es el punto de captura de datos y el sistema de registro principal para el consentimiento. Al enviar datos a Dynamics 365, la marca de tiempo del consentimiento y el canal de suscripción específico deben asignarse con precisión. Si un invitado revoca posteriormente el consentimiento a través de un correo electrónico de marketing de Dynamics 365, esa revocación debe sincronizarse de nuevo con la plataforma WiFi para evitar un seguimiento futuro.
  2. Minimización de datos: Envíe únicamente los datos necesarios para los casos de uso de marketing u operativos definidos. No envíe solicitudes de sondeo sin procesar y no autenticadas al CRM.
  3. Tránsito seguro: Todos los datos en tránsito entre la plataforma WiFi y Dynamics 365 deben cifrarse mediante TLS 1.2 o superior. Evite exponer las claves de API en el código del lado del cliente; utilice una comunicación segura de servidor a servidor. Para conocer las consideraciones de seguridad a nivel de red, consulte nuestra guía sobre DNS Filtering for Guest WiFi .

Resolución de problemas y mitigación de riesgos

Incluso con una arquitectura sólida, las integraciones pueden fallar. Estos son los modos de fallo más comunes y cómo mitigarlos.

Limitación de la tasa de API

Dynamics 365 impone límites de tasa de API para garantizar la estabilidad del servicio. Durante un evento importante en un estadio, miles de invitados pueden iniciar sesión en el WiFi simultáneamente, lo que provoca una avalancha de webhooks.

  • Mitigación: Implemente una cola de mensajes (por ejemplo, Azure Service Bus) entre la plataforma WiFi y Dynamics 365. La cola absorbe el pico de tráfico y alimenta las cargas útiles en Dynamics a un ritmo controlado que respeta los límites de la API.

Creación de contactos duplicados

Si la lógica de deduplicación es defectuosa, el CRM se llenará rápidamente de registros duplicados, destruyendo el perfil de cliente unificado.

  • Mitigación: No confíe únicamente en las reglas de detección de duplicados asíncronas de Dynamics 365 para inserciones de API de gran volumen. El middleware de integración debe realizar una búsqueda explícita (por ejemplo, consultando por dirección de correo electrónico) antes de ejecutar una operación de creación. Si se encuentra una coincidencia, ejecute una actualización en su lugar.

Desviación por aleatorización de direcciones MAC

Como se ha mencionado, la aleatorización de direcciones MAC inflará artificialmente el recuento de visitas si no se gestiona correctamente.

  • Mitigación: Priorice siempre la identidad autenticada (correo electrónico/teléfono) sobre la dirección MAC del dispositivo. Utilice las direcciones MAC únicamente para la continuidad de la sesión dentro de un único periodo de 24 horas, descartándolas para la resolución de la identidad a largo plazo.

ROI e impacto empresarial

La integración de Dynamics 365 con los datos de WiFi de invitados transforma la red de un centro de costes en un activo de inteligencia generador de ingresos.

  • Eficiencia de la automatización de marketing: Al activar campañas basadas en la presencia física real en lugar de solo en la apertura de correos electrónicos, las tasas de conversión mejoran significativamente. Una cadena de tiendas puede enviar automáticamente una oferta promocional a un miembro de su programa de fidelización en el momento en que entra en el establecimiento.
  • Perfiles de cliente unificados: La integración proporciona una visión de 360 grados del cliente, combinando los datos de comercio electrónico con el comportamiento en el mundo físico. Esto permite a Customer Insights generar modelos predictivos muy precisos sobre la pérdida de clientes y el valor del tiempo de vida del cliente.
  • Inteligencia operativa: Más allá del marketing, los datos de Wayfinding y del tiempo de permanencia pueden fundamentar decisiones operativas, como la optimización de los horarios del personal en función de las horas de mayor afluencia o el rediseño de la distribución de las tiendas según la popularidad de las zonas.

Al implementar la arquitectura de dos niveles y seguir las mejores prácticas descritas en esta guía, los responsables de TI pueden ofrecer un flujo de datos robusto, conforme a la normativa y de gran valor que empodere a toda la organización.

Definiciones clave

Resolución de identidad

El proceso de asociar un identificador de dispositivo anónimo (como una dirección MAC) con un perfil de cliente conocido (como una dirección de correo electrónico) a través de múltiples sistemas.

Crucial para garantizar que los datos de WiFi enriquezcan el registro de contacto correcto en Dynamics 365 en lugar de crear duplicados.

Aleatorización de direcciones MAC

Una función de privacidad en los sistemas operativos modernos (iOS, Android) donde el dispositivo genera una dirección MAC temporal y aleatoria al sondear o conectarse a redes.

Obliga a los integradores a depender de datos autenticados (inicios de sesión en el Captive Portal) en lugar de sondeos de red pasivos para un seguimiento preciso de los clientes.

Arquitectura de entidades de dos niveles

Un enfoque de modelado de datos en Dynamics 365 donde los datos maestros (Contacto) se separan de los datos transaccionales de gran volumen (Visitas de WiFi) mediante una relación 1:N.

Esencial para mantener el rendimiento de la base de datos del CRM y permitir una segmentación limpia en Customer Insights.

OData (Open Data Protocol)

Un estándar OASIS aprobado por ISO/IEC que define un conjunto de mejores prácticas para crear y consumir APIs RESTful.

El protocolo recomendado para ejecutar una sincronización por lotes eficiente y a gran escala de los registros de visitas de WiFi en Dynamics 365.

Webhook

Un método para aumentar o alterar el comportamiento de una página o aplicación web con devoluciones de llamada (callbacks) personalizadas, entregando datos a otras aplicaciones a medida que ocurren.

Se utiliza para enviar eventos de autenticación de WiFi en tiempo real a Dynamics 365 para la activación inmediata del marketing en el establecimiento.

Customer Insights

La plataforma de datos de clientes (CDP) de Microsoft que unifica datos de múltiples fuentes para crear una vista única de los clientes y descubrir información de valor.

El destino principal para los datos agregados de visitas de WiFi para crear segmentos de comportamiento complejos que combinan la actividad online y offline.

Captive Portal

Una página web que el usuario de una red de acceso público está obligado a ver e interactuar con ella antes de que se le conceda acceso.

El punto principal de captura de datos y recopilación de consentimiento de GDPR para la integración con Dynamics 365.

Tiempo de permanencia

La duración del tiempo que un invitado pasa conectado a la red o dentro de una zona física específica.

Una métrica clave que se envía a Dynamics 365 para medir la interacción en el establecimiento y activar campañas de marketing basadas en la duración.

Ejemplos prácticos

Un hotel de 200 habitaciones necesita activar un SMS personalizado de "Bienvenido al Spa" a través de Dynamics 365 Marketing cuando un huésped VIP se conecta al WiFi en la zona de bienestar.

  1. Configurar la plataforma Purple para etiquetar los puntos de acceso en el área de bienestar con la zona "Spa".
  2. Configurar un webhook en tiempo real en Purple que se active con el evento "Authentication Success", filtrando por la zona "Spa".
  3. El payload del webhook se envía a una Azure Logic App. La Logic App analiza el payload y extrae el correo electrónico y la dirección MAC del huésped.
  4. La Logic App consulta Dynamics 365 por correo electrónico para verificar el estado VIP del huésped y comprobar su indicador de consentimiento de marketing.
  5. Si el huésped es VIP y ha dado su consentimiento, la Logic App crea un nuevo registro en la entidad personalizada cr_wifiVisit y activa un Dynamics 365 Marketing Journey específico que envía el SMS.
Comentario del examinador: Este enfoque utiliza correctamente webhooks en tiempo real para una activación inmediata, al tiempo que confía en una capa de middleware (Azure Logic Apps) para gestionar la lógica de negocio y la deduplicación antes de llamar a la API de Dynamics. Evita codificar de forma rígida la lógica de marketing en la capa de red.

Una cadena de tiendas con 50 ubicaciones quiere crear un segmento en Dynamics 365 Customer Insights de "Compradores en tienda inactivos" (clientes que compraron online recientemente pero no han visitado una tienda física en 90 días).

  1. Implementar una sincronización por lotes nocturna (a través de OData) desde la plataforma WiFi a Dynamics 365.
  2. La sincronización actualiza el campo cr_wifi_last_visit en la entidad principal Contact para todos los invitados que se conectaron ese día.
  3. En Dynamics 365 Customer Insights, ingerir la entidad Contact como fuente de datos.
  4. Crear una regla de segmento: Condición 1: Last_Online_Purchase_Date < hace 30 días Y Condición 2: cr_wifi_last_visit > hace 90 días.
  5. Exportar este segmento a Dynamics 365 Marketing para una campaña de correo electrónico de reactivación segmentada.
Comentario del examinador: Este escenario demuestra el valor del enfoque de sincronización por lotes para cargas de trabajo analíticas. Al actualizar un campo agregado simple (`cr_wifi_last_visit`) en el registro de contacto maestro, la lógica de segmentación en Customer Insights se vuelve altamente eficiente sin necesidad de consultar millones de registros de visitas individuales.

Preguntas de práctica

Q1. ¿Su equipo de marketing quiere enviar un correo electrónico a cualquier cliente que haya visitado la tienda insignia más de 5 veces este mes pero no haya comprado nada online. ¿Cómo debería estructurar el flujo de datos para soportar esto sin sobrecargar el CRM?

Sugerencia: Considere la arquitectura de entidades de dos niveles y el papel de Customer Insights.

Ver respuesta modelo

No registre cada visita en la entidad Contacto. En su lugar, utilice una sincronización por lotes nocturna para enviar los registros de visitas a una entidad personalizada cr_wifiVisit vinculada al Contacto. Luego, utilice Dynamics 365 Customer Insights para ingerir tanto la entidad de visita personalizada como el historial de compras de comercio electrónico. Cree un segmento en Customer Insights que combine ambos criterios (recuento de cr_wifiVisit > 5 Y compras online = 0) y exporte ese segmento a Dynamics 365 Marketing.

Q2. Durante un ejercicio de pruebas de carga, su middleware (Azure Logic Apps) comienza a recibir errores HTTP 429 (Demasiadas solicitudes) de la API de Dynamics 365. ¿Cuál es la solución arquitectónica más adecuada?

Sugerencia: Piense en cómo desacoplar los eventos de red en tiempo real del proceso de inserción de la API.

Ver respuesta modelo

Implemente una cola de mensajes, como Azure Service Bus, entre el receptor del webhook y el conector de la API de Dynamics 365. El webhook escribe la carga útil en la cola de inmediato, y un proceso independiente lee de la cola e inserta los registros en Dynamics 365 a una velocidad controlada que respete los límites de la API.

Q3. Un invitado inicia sesión en el WiFi utilizando su dirección de correo electrónico y acepta el consentimiento de marketing. Tres semanas después, hace clic en "Darse de baja" en un correo electrónico de marketing enviado desde Dynamics 365. ¿Qué debe ocurrir en la capa de integración?

Sugerencia: Considere el sistema de registro y los requisitos de cumplimiento.

Ver respuesta modelo

La integración debe ser bidireccional para el consentimiento. Cuando se produce el evento "Darse de baja" en Dynamics 365, un webhook o un flujo automatizado debe activar una llamada de API de vuelta a la plataforma Purple WiFi para actualizar el perfil del invitado y revocar su indicador de consentimiento de marketing. Esto garantiza que los futuros inicios de sesión de WiFi no vuelvan a suscribir involuntariamente al usuario ni activen acciones de marketing que no cumplan con la normativa.

Continúe leyendo esta serie

Integración de CommScope Ruckus con Purple WiFi: Guía de instalación y configuración

Esta guía de referencia técnica proporciona un manual de configuración definitivo para integrar arquitecturas de CommScope Ruckus con Purple WiFi. Detalla implementaciones paso a paso para captive portals de Guest WiFi, WiFi seguro para el personal a través de 802.1X y aislamiento de red multiinquilino mediante Ruckus Dynamic PSK.

Leer la guía →

Integración de puntos de acceso Allied Telesis con Purple WiFi

Esta guía proporciona un manual de configuración completo para integrar los puntos de acceso de la serie TQ de Allied Telesis con Purple WiFi. Cubre la redirección externa de Captive Portal, la autenticación RADIUS 802.1X y el direccionamiento dinámico de VLAN mediante claves precompartidas privadas (PPSK) para despliegues multiinquilino seguros.

Leer la guía →

Integración de los puntos de acceso Grandstream GWN con Purple WiFi

Esta guía técnica de referencia autorizada detalla cómo integrar los puntos de acceso Grandstream GWN con la plataforma de análisis y Guest WiFi de Purple. Cubre la configuración del Captive Portal de Grandstream, los ajustes de RADIUS AAA, la configuración de walled garden, la autenticación segura para el personal mediante 802.1X con direccionamiento dinámico de VLAN y la segmentación PPSK multiinquilino, proporcionando una guía práctica paso a paso para MSP e instalaciones de TI que desplieguen WiFi para invitados y personal a gran escala.

Leer la guía →