Skip to main content

Microsoft Dynamics 365 y Enriquecimiento de Datos de WiFi para Invitados

Esta guía de referencia técnica detalla la arquitectura, el modelado de datos y la asignación de campos necesarios para integrar los datos de WiFi para invitados con Microsoft Dynamics 365. Proporciona estrategias de implementación prácticas para que los gerentes de TI y los arquitectos de red enriquezcan los perfiles unificados de los clientes e impulsen un ROI medible en ubicaciones físicas.

📖 6 min de lectura📝 1,377 palabras🔧 2 ejemplos3 preguntas📚 8 términos clave

header_image.png

Resumen Ejecutivo

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

Esta guía describe la arquitectura definitiva para la integración de WiFi con Dynamics 365. Detalla cómo enviar detalles de contacto verificados, marcas de tiempo de consentimiento GDPR y métricas de visita 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 contacto 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 tráfico anónimo en un perfil de cliente unificado y accionable.

microsoft_dynamics_365_and_guest_wifi_data_enrichment_podcast.wav

Análisis Técnico Detallado: Arquitectura y Flujo de Datos

La integración de WiFi para invitados con Dynamics 365 requiere una capa de middleware robusta para manejar la resolución de identidades, la deduplicación y la transformación de la carga útil. Los datos brutos se originan en el borde de la red —desde puntos de acceso y Captive Portals— y deben procesarse antes de que entren en el 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 a la 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á lugar a perfiles fragmentados y recuentos de visitas inexactos. Por lo tanto, la integración debe utilizar el identificador autenticado —típicamente 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 hash solo debe usarse como identificador secundario para el seguimiento de sesiones dentro de una única visita.

Estructura de Entidad de Dos Niveles

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

  1. La Entidad de Contacto (Registro Maestro): Esta entidad solo debe actualizarse cuando hay 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 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ífica (por ejemplo, "Lobby", "Sports Bar"). Esta entidad está vinculada a la entidad Contact a través de una relación de uno a muchos (1:N).

Esta separación de preocupaciones es vital para aprovechar Microsoft Dynamics 365 Customer Insights. Al tratar la entidad cr_wifiVisit como un flujo de datos de comportamiento distinto, Customer Insights puede ingerir los registros y construir segmentos dinámicos basados en interacciones en ubicaciones físicas, fusionándolos sin problemas con el historial de compras en línea.

Guía de Implementación: Asignación de Campos y Sincronización

Una implementación exitosa depende de una asignación precisa de campos y una comprensión clara del sistema de registro.

Mejores Prácticas de Asignación de Campos

field_mapping_diagram.png

Al asignar campos de 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 Cadena Clave principal para la deduplicación.
Dirección MAC (Hash) cr_device_mac_hash Cadena Almacenar en la entidad de visita personalizada, no en el contacto.
Marca de Tiempo de Primera Visita cr_wifi_first_visit Fecha y Hora Actualizar solo en la creación inicial del contacto.
Marca de Tiempo de Última Visita cr_wifi_last_visit Fecha y Hora Actualizar en cada visita posterior.
Marca de Tiempo de Consentimiento cr_consent_wifi_date Fecha y Hora Crucial para auditorías de cumplimiento.
Zona del Establecimiento cr_wifi_zone_preference Cadena Puede agregarse en el contacto o registrarse por visita.

Estrategias de Sincronización: Tiempo Real vs. 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 establecimiento. Si el equipo de marketing desea activar un correo electrónico automatizado de "Bienvenido de nuevo" o una oferta de SMS para un café gratis dentro de los cinco minutos de que el invitado se conecte a la red, los webhooks en tiempo real son obligatorios. Esto requiere una sólida puerta de enlace de API gestión para manejar picos de tráfico durante las horas punta del recinto.
  • Procesamiento por lotes (OData / Extracciones programadas de la API): Si el objetivo principal es el WiFi Analytics a largo plazo y la creación semanal de segmentos, 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.

Mejores prácticas para el cumplimiento y la seguridad

Al manejar datos de invitados, el cumplimiento de marcos como GDPR y PCI DSS es innegociable. Para una comprensión más profunda del cumplimiento, consulte nuestra 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 mapearse 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 el seguimiento futuro.
  2. Minimización de datos: Solo envíe los datos necesarios para los casos de uso de marketing u operativos definidos. No envíe solicitudes de sondeo sin autenticar al CRM.
  3. Tránsito seguro: Todos los datos en tránsito entre la plataforma WiFi y Dynamics 365 deben cifrarse utilizando TLS 1.2 o superior. Evite exponer las claves API en el código del lado del cliente; utilice comunicación segura de servidor a servidor. Para 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. Aquí se presentan los modos de fallo más comunes y cómo mitigarlos.

Limitación de la tasa de la API

Dynamics 365 aplica límites de tasa de la 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 desencadena 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 a Dynamics a una velocidad controlada 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 con registros duplicados, destruyendo el perfil unificado del cliente.

  • Mitigación: No confíe únicamente en las reglas de detección de duplicados asíncronas de Dynamics 365 para inserciones de API de alto 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.

Sesgo de aleatorización de MAC

Como se mencionó, la aleatorización de MAC inflará artificialmente los recuentos de visitas si no se maneja correctamente.

  • Mitigación: Priorice siempre la identidad autenticada (correo electrónico/teléfono) sobre la dirección MAC del dispositivo. Utilice las direcciones MAC solo para la continuidad de la sesión dentro de un período de 24 horas, descartándolas para la resolución de 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 aperturas de correo electrónico, las tasas de conversión mejoran significativamente. Una cadena minorista puede enviar automáticamente una oferta promocional a un miembro de fidelidad en el momento en que entra en la tienda.
  • Perfiles de cliente unificados: La integración proporciona una vista de 360 grados del cliente, combinando datos de comercio electrónico con el comportamiento del mundo físico. Esto permite a Customer Insights generar modelos predictivos altamente precisos para la rotación y el valor de vida del cliente.
  • Inteligencia operativa: Más allá del marketing, los datos de Wayfinding y tiempo de permanencia pueden informar decisiones operativas, como la optimización de los horarios del personal en función de los momentos de mayor afluencia o el rediseño de los diseños de las tiendas en función de la popularidad de las zonas.

Al implementar la arquitectura de dos niveles y adherirse a las mejores prácticas descritas en esta guía, los líderes de TI pueden ofrecer una canalización de datos robusta, compatible y de gran valor que empodera a toda la organización.

Términos clave y definiciones

Identity Resolution

The process of matching an anonymous device identifier (like a MAC address) to a known customer profile (like an email address) across multiple systems.

Critical for ensuring that WiFi data enriches the correct Contact record in Dynamics 365 rather than creating duplicates.

MAC Address Randomisation

A privacy feature in modern operating systems (iOS, Android) where the device generates a temporary, random MAC address when probing or connecting to networks.

Forces integrators to rely on authenticated data (captive portal logins) rather than passive network probing for accurate customer tracking.

Two-Tier Entity Architecture

A data modelling approach in Dynamics 365 where master data (Contact) is separated from high-volume transactional data (WiFi Visits) using a 1:N relationship.

Essential for maintaining CRM database performance and enabling clean segmentation in Customer Insights.

OData (Open Data Protocol)

An ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs.

The recommended protocol for executing efficient, large-scale batch synchronisation of WiFi visit logs into Dynamics 365.

Webhook

A method of augmenting or altering the behaviour of a web page or web application with custom callbacks, delivering data to other applications as it happens.

Used to push real-time WiFi authentication events to Dynamics 365 for immediate in-venue marketing activation.

Customer Insights

Microsoft's customer data platform (CDP) that unifies data from multiple sources to create a single view of customers and discover insights.

The primary destination for aggregated WiFi visit data to build complex behavioural segments combining online and offline activity.

Captive Portal

A web page that the user of a public-access network is obliged to view and interact with before access is granted.

The primary point of data capture and GDPR consent collection for the Dynamics 365 integration.

Dwell Time

The duration of time a guest spends connected to the network or within a specific physical zone.

A key metric pushed to Dynamics 365 to measure venue engagement and trigger duration-based marketing campaigns.

Casos de éxito

A 200-room hotel needs to trigger a personalised 'Welcome to the Spa' SMS via Dynamics 365 Marketing when a VIP guest connects to the WiFi in the wellness zone.

  1. Configure the Purple platform to tag the access points in the wellness area with the zone 'Spa'.
  2. Set up a real-time webhook in Purple that fires on the 'Authentication Success' event, filtering for the 'Spa' zone.
  3. The webhook payload is sent to an Azure Logic App. The Logic App parses the payload, extracts the guest's email and MAC address.
  4. The Logic App queries Dynamics 365 by email to verify the guest's VIP status and check their marketing consent flag.
  5. If the guest is a VIP and has consented, the Logic App creates a new record in the cr_wifiVisit custom entity and triggers a specific Dynamics 365 Marketing Journey that sends the SMS.
Notas de implementación: This approach correctly uses real-time webhooks for immediate activation while relying on a middleware layer (Azure Logic Apps) to handle the business logic and deduplication before hitting the Dynamics API. It avoids hardcoding marketing logic into the network layer.

A retail chain with 50 locations wants to build a segment in Dynamics 365 Customer Insights of 'Lapsed In-Store Shoppers' (customers who bought online recently but haven't visited a physical store in 90 days).

  1. Implement a nightly batch sync (via OData) from the WiFi platform to Dynamics 365.
  2. The sync updates the cr_wifi_last_visit field on the core Contact entity for all guests who connected that day.
  3. In Dynamics 365 Customer Insights, ingest the Contact entity as a data source.
  4. Create a segment rule: Condition 1: Last_Online_Purchase_Date < 30 days ago AND Condition 2: cr_wifi_last_visit > 90 days ago.
  5. Export this segment to Dynamics 365 Marketing for a targeted re-engagement email campaign.
Notas de implementación: This scenario demonstrates the value of the batch sync approach for analytical workloads. By updating a simple aggregated field (`cr_wifi_last_visit`) on the master contact record, the segmentation logic in Customer Insights becomes highly efficient without needing to query millions of individual visit logs.

Análisis de escenarios

Q1. Your marketing team wants to send an email to any customer who has visited the flagship store more than 5 times this month but hasn't purchased anything online. How should you architect the data flow to support this without overloading the CRM?

💡 Sugerencia:Consider the Two-Tier Entity Architecture and the role of Customer Insights.

Mostrar enfoque recomendado

Do not write every visit to the Contact entity. Instead, use a nightly batch sync to push visit logs to a custom cr_wifiVisit entity linked to the Contact. Then, use Dynamics 365 Customer Insights to ingest both the custom visit entity and the e-commerce purchase history. Build a segment in Customer Insights combining the two criteria (cr_wifiVisit count > 5 AND online purchases = 0) and export that segment to Dynamics 365 Marketing.

Q2. During a load-testing exercise, your middleware (Azure Logic Apps) starts receiving HTTP 429 (Too Many Requests) errors from the Dynamics 365 API. What is the most appropriate architectural fix?

💡 Sugerencia:Think about how to decouple the real-time network events from the API insertion process.

Mostrar enfoque recomendado

Implement a message queue, such as Azure Service Bus, between the webhook receiver and the Dynamics 365 API connector. The webhook writes the payload to the queue immediately, and a separate process reads from the queue and inserts the records into Dynamics 365 at a controlled rate that respects the API limits.

Q3. A guest logs into the WiFi using their email address and accepts the marketing consent. Three weeks later, they click 'Unsubscribe' on a marketing email sent from Dynamics 365. What must happen at the integration layer?

💡 Sugerencia:Consider the system of record and compliance requirements.

Mostrar enfoque recomendado

The integration must be bidirectional for consent. When the 'Unsubscribe' event occurs in Dynamics 365, a webhook or automated flow must trigger an API call back to the Purple WiFi platform to update the guest's profile and revoke their marketing consent flag. This ensures that future WiFi logins do not inadvertently re-subscribe the user or trigger non-compliant marketing actions.