Microsoft Dynamics 365 et enrichissement des données WiFi des invités
Ce guide de référence technique détaille l'architecture, la modélisation des données et le mappage des champs nécessaires pour intégrer les données WiFi des invités à Microsoft Dynamics 365. Il fournit des stratégies de mise en œuvre concrètes pour les responsables informatiques et les architectes réseau afin d'enrichir les profils clients unifiés et de générer un retour sur investissement mesurable dans les lieux physiques.
- Résumé analytique
- Plongée technique : Architecture et flux de données
- Le pipeline d'ingestion
- Structure d'entité à deux niveaux
- Guide d'implémentation : Mappage des champs et synchronisation
- Bonnes pratiques de mappage des champs
- Stratégies de synchronisation : Temps réel vs. Lot
- Bonnes pratiques pour la conformité et la sécurité
- Dépannage et atténuation des risques
- Limitation du taux d'API
- Création de contacts en double
- Biais de randomisation MAC
- ROI et impact commercial

Résumé analytique
Pour les lieux physiques modernes — des chaînes de magasins aux stades de grande envergure — la compréhension du comportement des invités n'est plus une option. Cependant, alors que les plateformes de commerce électronique offrent des analyses comportementales riches, les lieux physiques sont souvent confrontés à un angle mort : ils savent ce qu'un client a acheté, mais pas combien de temps il est resté, à quelle fréquence il visite sans acheter, ou quelles zones il fréquente. En intégrant les données d'authentification Guest WiFi à Microsoft Dynamics 365, les responsables informatiques peuvent combler cette lacune.
Ce guide décrit l'architecture définitive pour l'intégration WiFi de Dynamics 365. Il détaille comment transférer les coordonnées vérifiées, les horodatages de consentement GDPR et les métriques de visite de la plateforme d'analyse WiFi vers Dynamics 365. De manière cruciale, il préconise un modèle de données à deux niveaux — séparant les mises à jour de contacts de base des journaux de visites transactionnels à volume élevé — pour garantir les performances du CRM et permettre une segmentation avancée au sein de Customer Insights. Pour les organisations du Commerce de détail et de l' Hôtellerie , cette intégration transforme le flux de visiteurs anonymes en un profil client unifié et exploitable.
Plongée technique : Architecture et flux de données
L'intégration du WiFi des invités avec Dynamics 365 nécessite une couche middleware robuste pour gérer la résolution d'identité, la déduplication et la transformation de la charge utile. Les données brutes proviennent de la périphérie du réseau — des points d'accès et des Captive Portals — et doivent être traitées avant d'entrer dans le CRM.

Le pipeline d'ingestion
Lorsqu'un invité s'authentifie via le Captive Portal, la plateforme WiFi capture son adresse MAC, la méthode d'authentification (par exemple, connexion sociale, formulaire d'e-mail) et son consentement explicite pour le marketing. Cet événement déclenche un webhook ou un appel API REST contenant une charge utile JSON.
L'étape critique ici est la Résolution d'identité. Les systèmes d'exploitation mobiles modernes utilisent la randomisation des adresses MAC pour améliorer la confidentialité des utilisateurs. Se fier uniquement à l'adresse MAC comme clé primaire entraînera des profils fragmentés et des comptages de visites inexacts. Par conséquent, l'intégration doit utiliser l'identifiant authentifié — généralement l'adresse e-mail ou le numéro de téléphone mobile — comme clé primaire pour faire correspondre les enregistrements dans Dynamics 365. L'adresse MAC hachée ne doit être utilisée que comme identifiant secondaire pour le suivi de session au sein d'une seule visite.
Structure d'entité à deux niveaux
Un anti-modèle architectural courant consiste à tenter d'écrire chaque session WiFi directement dans l'entité Contact principale. Cette approche gonfle rapidement la base de données, dégrade les performances du CRM et complique les rapports. Au lieu de cela, une structure d'entité à deux niveaux est la norme de l'industrie pour l'intégration WiFi de Dynamics CRM :
- L'entité Contact (Enregistrement principal) : Cette entité ne doit être mise à jour qu'en cas de modification substantielle du profil de l'invité, telle qu'une nouvelle adresse e-mail, un numéro de téléphone mis à jour ou un changement de son statut de consentement GDPR. Elle peut également stocker des métriques agrégées, telles que
cr_wifi_visit_countoucr_wifi_avg_dwell, qui sont utiles pour une segmentation rapide. - L'entité de visite personnalisée (
cr_wifiVisit) : Il s'agit d'une table transactionnelle où chaque session WiFi terminée est enregistrée comme une ligne distincte. Elle capture l'heure de début, l'heure de fin, la durée de la session et le lieu ou la zone spécifique (par exemple, "Lobby", "Sports Bar"). Cette entité est liée à l'entitéContactvia une relation un-à-plusieurs (1:N).
Cette séparation des préoccupations est vitale pour tirer parti de Microsoft Dynamics 365 Customer Insights. En traitant l'entité cr_wifiVisit comme un flux de données comportementales distinct, Customer Insights peut ingérer les journaux et construire des segments dynamiques basés sur les interactions dans les lieux physiques, en les fusionnant de manière transparente avec l'historique des achats en ligne.
Guide d'implémentation : Mappage des champs et synchronisation
Une implémentation réussie repose sur un mappage précis des champs et une compréhension claire du système d'enregistrement.
Bonnes pratiques de mappage des champs

Lors du mappage des champs de la plateforme Purple vers Dynamics 365, assurez-vous que les types de données s'alignent et que des champs personnalisés sont créés si nécessaire.
| Champ source Purple WiFi | Champ cible Dynamics 365 | Type de données | Notes |
|---|---|---|---|
| E-mail de l'invité | emailaddress1 |
String | Clé primaire pour la déduplication. |
| Adresse MAC (hachée) | cr_device_mac_hash |
String | Stocker sur l'entité de visite personnalisée, pas sur le contact. |
| Horodatage de première visite | cr_wifi_first_visit |
DateTime | Mettre à jour uniquement lors de la création initiale du contact. |
| Horodatage de dernière visite | cr_wifi_last_visit |
DateTime | Mettre à jour à chaque visite ultérieure. |
| Horodatage de consentement | cr_consent_wifi_date |
DateTime | Crucial pour les audits de conformité. |
| Zone du lieu | cr_wifi_zone_preference |
String | Peut être agrégé sur le contact ou enregistré par visite. |
Stratégies de synchronisation : Temps réel vs. Lot
Le choix entre la synchronisation en temps réel et par lot dépend entièrement du cas d'utilisation métier.
- Temps réel (Webhooks) : Essentiel pour l'activation sur place. Si l'équipe marketing souhaite déclencher un e-mail automatisé "Bienvenue de retour" ou une offre SMS pour un café gratuit dans les cinq minutes suivant la connexion de l'invité au réseau, les webhooks en temps réel sont obligatoires. Cela nécessite une passerelle API robustegestion pour gérer les pics de trafic pendant les heures de pointe du site.
- Traitement par lots (OData / Extractions API planifiées) : Si l'objectif principal est l' Analyse WiFi à long terme et la création de segments hebdomadaires, une synchronisation par lots nocturne est bien plus efficace. Elle réduit la charge de l'API sur Dynamics 365 et permet l'agrégation des données avant l'insertion.
Bonnes pratiques pour la conformité et la sécurité
Lors du traitement des données des invités, la conformité avec des cadres comme le GDPR et le PCI DSS est non négociable. Pour une compréhension plus approfondie de la conformité, consultez notre WiFi Invité ISO 27001 : Un guide de conformité .
- Le consentement est le système d'enregistrement : Le Captive Portal est le point de capture des données et le système d'enregistrement principal pour le consentement. Lors de l'envoi de données à Dynamics 365, l'horodatage du consentement et le canal d'opt-in spécifique doivent être mappés avec précision. Si un invité révoque ultérieurement son consentement via un e-mail marketing de Dynamics 365, cette révocation doit être synchronisée avec la plateforme WiFi pour empêcher tout suivi futur.
- Minimisation des données : Ne transférez que les données nécessaires aux cas d'utilisation marketing ou opérationnels définis. Ne transférez pas de requêtes de sondage brutes et non authentifiées dans le CRM.
- Transit sécurisé : Toutes les données en transit entre la plateforme WiFi et Dynamics 365 doivent être chiffrées à l'aide de TLS 1.2 ou supérieur. Évitez d'exposer les clés API dans le code côté client ; utilisez une communication sécurisée de serveur à serveur. Pour les considérations de sécurité au niveau du réseau, consultez notre guide sur le Filtrage DNS pour le WiFi Invité .
Dépannage et atténuation des risques
Même avec une architecture solide, les intégrations peuvent échouer. Voici les modes de défaillance les plus courants et comment les atténuer.
Limitation du taux d'API
Dynamics 365 applique des limites de taux d'API pour assurer la stabilité du service. Lors d'un événement majeur dans un stade, des milliers d'invités peuvent se connecter au WiFi simultanément, déclenchant un flot de webhooks.
- Atténuation : Implémentez une file d'attente de messages (par exemple, Azure Service Bus) entre la plateforme WiFi et Dynamics 365. La file d'attente absorbe le pic de trafic et alimente Dynamics avec les charges utiles à un rythme contrôlé qui respecte les limites de l'API.
Création de contacts en double
Si la logique de déduplication est défectueuse, le CRM se remplira rapidement d'enregistrements en double, détruisant le profil client unifié.
- Atténuation : Ne vous fiez pas uniquement aux règles de détection asynchrone des doublons de Dynamics 365 pour les insertions API à volume élevé. Le middleware d'intégration doit effectuer une recherche explicite (par exemple, en interrogeant par adresse e-mail) avant d'exécuter une opération de création. Si une correspondance est trouvée, exécutez plutôt une mise à jour.
Biais de randomisation MAC
Comme mentionné, la randomisation MAC gonflera artificiellement le nombre de visites si elle n'est pas gérée correctement.
- Atténuation : Priorisez toujours l'identité authentifiée (e-mail/téléphone) par rapport à l'adresse MAC de l'appareil. Utilisez les adresses MAC uniquement pour la continuité de session sur une période de 24 heures, en les écartant pour la résolution d'identité à long terme.
ROI et impact commercial
L'intégration de Dynamics 365 avec les données WiFi des invités transforme le réseau d'un centre de coûts en un actif d'intelligence générateur de revenus.
- Efficacité de l'automatisation marketing : En déclenchant des campagnes basées sur la présence physique réelle plutôt que sur de simples ouvertures d'e-mails, les taux de conversion s'améliorent considérablement. Une chaîne de magasins peut envoyer automatiquement une offre promotionnelle à un membre de son programme de fidélité dès qu'il entre dans le magasin.
- Profils clients unifiés : L'intégration offre une vue à 360 degrés du client, mélangeant les données e-commerce avec le comportement dans le monde physique. Cela permet à Customer Insights de générer des modèles prédictifs très précis pour le taux de désabonnement et la valeur à vie.
- Intelligence opérationnelle : Au-delà du marketing, les données de Wayfinding et de temps de présence peuvent éclairer les décisions opérationnelles, telles que l'optimisation des plannings du personnel en fonction des heures de pointe d'affluence ou la refonte des agencements de magasins en fonction de la popularité des zones.
En mettant en œuvre l'architecture à deux niveaux et en adhérant aux bonnes pratiques décrites dans ce guide, les leaders informatiques peuvent fournir un pipeline de données robuste, conforme et très précieux qui renforce l'ensemble de l'organisation.
Termes clés et définitions
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.
Études de cas
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.
- Configure the Purple platform to tag the access points in the wellness area with the zone 'Spa'.
- Set up a real-time webhook in Purple that fires on the 'Authentication Success' event, filtering for the 'Spa' zone.
- The webhook payload is sent to an Azure Logic App. The Logic App parses the payload, extracts the guest's email and MAC address.
- The Logic App queries Dynamics 365 by email to verify the guest's VIP status and check their marketing consent flag.
- If the guest is a VIP and has consented, the Logic App creates a new record in the
cr_wifiVisitcustom entity and triggers a specific Dynamics 365 Marketing Journey that sends the SMS.
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).
- Implement a nightly batch sync (via OData) from the WiFi platform to Dynamics 365.
- The sync updates the
cr_wifi_last_visitfield on the coreContactentity for all guests who connected that day. - In Dynamics 365 Customer Insights, ingest the
Contactentity as a data source. - Create a segment rule:
Condition 1: Last_Online_Purchase_Date < 30 days agoANDCondition 2: cr_wifi_last_visit > 90 days ago. - Export this segment to Dynamics 365 Marketing for a targeted re-engagement email campaign.
Analyse de scénario
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?
💡 Astuce :Consider the Two-Tier Entity Architecture and the role of Customer Insights.
Afficher l'approche recommandée
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?
💡 Astuce :Think about how to decouple the real-time network events from the API insertion process.
Afficher l'approche recommandée
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?
💡 Astuce :Consider the system of record and compliance requirements.
Afficher l'approche recommandée
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.



