Passer au contenu principal

Microsoft Dynamics 365 et enrichissement des données Guest WiFi

Ce guide de référence technique détaille l'architecture, la modélisation des données et le mappage des champs requis pour intégrer les données de Guest WiFi avec Microsoft Dynamics 365. Il fournit des stratégies de mise en œuvre exploitables pour les responsables informatiques et les architectes réseau afin d'enrichir les profils clients unifiés et de générer un ROI mesurable dans les points de vente physiques.

Par Gavin WheeldonPublié le
📖 6 min de lecture1,505 mots2 exemples concrets3 questions d'entraînement8 définitions clés

Fait partie de notre série principale : Guest WiFi Guide

Microsoft Dynamics 365 et enrichissement des données Guest WiFi

Executive Summary

Per i moderni spazi fisici, dalle catene di negozi agli stadi su larga scala, comprendere il comportamento degli ospiti non è più un'opzione. Tuttavia, mentre le piattaforme di e-commerce offrono analisi comportamentali dettagliate, i luoghi fisici spesso si scontrano con un punto cieco: sanno cosa ha acquistato un cliente, ma non quanto tempo si è trattenuto, quante volte visita il locale senza acquistare o quali zone frequenta. Integrando i dati di autenticazione del Guest WiFi con Microsoft Dynamics 365, i responsabili IT possono colmare questa lacuna.

Questa guida illustra l'architettura definitiva per l'integrazione WiFi di Dynamics 365. Dettaglia come inviare i dati di contatto verificati, i timestamp del consenso GDPR e le metriche di visita dalla piattaforma di analisi WiFi a Dynamics 365. Fondamentalmente, promuove un modello di dati a due livelli, separando gli aggiornamenti dei contatti principali dai log delle visite transazionali ad alto volume, per garantire le prestazioni del CRM e consentire una segmentazione avanzata all'interno di Customer Insights. Per le organizzazioni nei settori Retail e Hospitality , questa integrazione trasforma l'affluenza anonima in un profilo cliente unificato e azionabile.

Approfondimento Tecnico: Architettura e Flusso dei Dati

L'integrazione del WiFi per gli ospiti con Dynamics 365 richiede un livello middleware robusto per gestire la risoluzione delle identità, la deduplicazione e la trasformazione del payload. I dati grezzi hanno origine all'edge della rete, dagli access point e dai Captive Portal, e devono essere elaborati prima di entrare nel CRM.

Microsoft Dynamics 365 et enrichissement des données Guest WiFi - architecture overview

La Pipeline di Ingestione

Quando un ospite si autentica tramite il Captive Portal, la piattaforma WiFi acquisisce il suo indirizzo MAC, il metodo di autenticazione (ad es. social login, modulo e-mail) e il suo consenso esplicito per il marketing. Questo evento attiva un webhook o una chiamata API REST contenente un payload JSON.

Il passaggio cruciale qui è la Risoluzione delle Identità. I moderni sistemi operativi mobili utilizzano la randomizzazione dell'indirizzo MAC per migliorare la privacy degli utenti. Affidarsi esclusivamente all'indirizzo MAC come chiave primaria comporterà profili frammentati e conteggi delle visite imprecisi. Pertanto, l'integrazione deve utilizzare l'identificativo autenticato, in genere l'indirizzo e-mail o il numero di cellulare, come chiave primaria per la corrispondenza dei record in Dynamics 365. L'indirizzo MAC con hashing deve essere utilizzato solo come identificatore secondario per il tracciamento della sessione all'interno di una singola visita.

Struttura delle Entità a Due Livelli

Un anti-pattern architetturale comune consiste nel tentare di scrivere ogni singola sessione WiFi direttamente nell'entità principale Contact. Questo approccio gonfia rapidamente il database, riduce le prestazioni del CRM e complica la reportistica. Al contrario, una struttura di entità a due livelli rappresenta lo standard del settore per l'integrazione WiFi di Dynamics CRM:

  1. L'Entità Contatto (Record Master): Questa entità deve essere aggiornata solo quando si verifica una modifica sostanziale al profilo dell'ospite, come un nuovo indirizzo e-mail, un numero di telefono aggiornato o una modifica del suo stato di consenso GDPR. Può anche memorizzare metriche aggregate, come cr_wifi_visit_count o cr_wifi_avg_dwell, utili per una segmentazione rapida.
  2. L'Entità Visita Personalizzata (cr_wifiVisit): Si tratta di una tabella transazionale in cui ogni sessione WiFi completata viene registrata come una riga distinta. Acquisisce l'ora di inizio sessione, l'ora di fine, la durata e il luogo o la zona specifici (ad es. "Lobby", "Sports Bar"). Questa entità è collegata all'entità Contact tramite una relazione uno-a-molti (1:N).

Questa separazione delle competenze è fondamentale per sfruttare Microsoft Dynamics 365 Customer Insights. Trattando l'entità cr_wifiVisit come un flusso di dati comportamentali distinto, Customer Insights può importare i log e creare segmenti dinamici basati sulle interazioni nei luoghi fisici, unendoli perfettamente con la cronologia degli acquisti online.

Vous avez des questions sur votre configuration spécifique ?

Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.

Guida all'Implementazione: Mappatura dei Campi e Sincronizzazione

Il successo dell'implementazione dipende da una mappatura precisa dei campi e da una chiara comprensione del sistema di record.

Best Practice per la Mappatura dei Campi

Microsoft Dynamics 365 et enrichissement des données Guest WiFi - field mapping diagram

Durante la mappatura dei campi dalla piattaforma Purple a Dynamics 365, assicurarsi che i tipi di dati corrispondano e che vengano creati campi personalizzati dove necessario.

Campo Sorgente Purple WiFi Campo Destinazione Dynamics 365 Tipo di Dato Note
E-mail Ospite emailaddress1 Stringa Chiave primaria per la deduplicazione.
Indirizzo MAC (con Hashing) cr_device_mac_hash Stringa Memorizzare nell'entità visita personalizzata, non nel contatto.
Timestamp Prima Visita cr_wifi_first_visit DateTime Aggiornare solo alla creazione iniziale del contatto.
Timestamp Ultima Visita cr_wifi_last_visit DateTime Aggiornare a ogni visita successiva.
Timestamp Consenso cr_consent_wifi_date DateTime Fondamentale per gli audit di conformità.
Zona del Locale cr_wifi_zone_preference Stringa Può essere aggregata sul contatto o registrata per visita.

Strategie di Sincronizzazione: Tempo Reale vs. Batch

La scelta tra sincronizzazione in tempo reale e batch dipende interamente dal caso d'uso aziendale.

  • Tempo Reale (Webhook): Essenziale per l'attivazione all'interno del locale. Se il team di marketing desidera attivare un'e-mail automatica di "Bentornato" o un'offerta SMS per un caffè in omaggio entro cinque minuti dalla connessione dell'ospite alla rete, i webhook in tempo reale sono obbligatori. Ciò richiede un gateway API robusto di gestione per gestire i picchi di traffico durante le ore di punta della struttura.
  • Batch (OData / Pull API pianificate): Se l'obiettivo principale è l'analisi a lungo termine di WiFi Analytics e la creazione di segmenti settimanali, una sincronizzazione batch notturna è molto più efficiente. Riduce il carico API su Dynamics 365 e consente l'aggregazione dei dati prima dell'inserimento.

Best Practice per la Conformità e la Sicurezza

Quando si gestiscono i dati degli ospiti, la conformità a framework come il GDPR e il PCI DSS non è negoziabile. Per una comprensione più approfondita della conformità, fare riferimento alla nostra guida ISO 27001 Guest WiFi: A Compliance Primer .

  1. Il Consenso è il Sistema di Riferimento: Il Captive Portal è il punto di acquisizione dei dati e il sistema di riferimento principale per il consenso. Quando si inviano dati a Dynamics 365, il timestamp del consenso e lo specifico canale di opt-in devono essere mappati accuratamente. Se un ospite revoca successivamente il consenso tramite un'e-mail di marketing di Dynamics 365, tale revoca deve essere sincronizzata nuovamente con la piattaforma WiFi per impedire il tracciamento futuro.
  2. Minimizzazione dei Dati: Inviare solo i dati necessari per i casi d'uso di marketing o operativi definiti. Non inviare richieste di probe grezze e non autenticate nel CRM.
  3. Transito Sicuro: Tutti i dati in transito tra la piattaforma WiFi e Dynamics 365 devono essere crittografati utilizzando TLS 1.2 o superiore. Evitare di esporre le chiavi API nel codice lato client; utilizzare una comunicazione server-to-server sicura. Per considerazioni sulla sicurezza a livello di rete, consultare la nostra guida sul Filtraggio DNS per il Guest WiFi .

Risoluzione dei Problemi e Mitigazione dei Rischi

Anche con un'architettura solida, le integrazioni possono fallire. Di seguito sono riportati i casi di errore più comuni e come mitigarli.

Limiti di Velocità delle API

Dynamics 365 impone limiti di velocità alle API per garantire la stabilità del servizio. Durante un grande evento in uno stadio, migliaia di ospiti potrebbero accedere contemporaneamente al WiFi, scatenando un flusso di webhook.

  • Mitigazione: Implementare una coda di messaggi (ad esempio, Azure Service Bus) tra la piattaforma WiFi e Dynamics 365. La coda assorbe il picco di traffico e inserisce i payload in Dynamics a una velocità controllata che rispetta i limiti delle API.

Creazione di Contatti Duplicati

Se la logica di deduplicazione è difettosa, il CRM si riempirà rapidamente di record duplicati, distruggendo il profilo cliente unificato.

  • Mitigazione: Non affidarsi esclusivamente alle regole di rilevamento dei duplicati asincrone di Dynamics 365 per gli inserimenti API ad alto volume. Il middleware di integrazione deve eseguire una ricerca esplicita (ad esempio, interrogando per indirizzo e-mail) prima di eseguire un'operazione di creazione. Se viene trovata una corrispondenza, eseguire invece un aggiornamento.

Distorsione da Randomizzazione MAC

Come menzionato, la randomizzazione del MAC gonfierà artificialmente il conteggio delle visite se non gestita correttamente.

  • Mitigazione: Dare sempre la priorità all'identità autenticata (e-mail/telefono) rispetto all'indirizzo MAC del dispositivo. Utilizzare gli indirizzi MAC solo per la continuità della sessione all'interno di un singolo periodo di 24 ore, scartandoli per la risoluzione dell'identità a lungo termine.

ROI e Impatto sul Business

L'integrazione di Dynamics 365 con i dati del guest WiFi trasforma la rete da un centro di costo a una risorsa di intelligence in grado di generare ricavi.

  • Efficienza della Marketing Automation: Attivando campagne basate sulla presenza fisica effettiva piuttosto che sulla semplice apertura delle e-mail, i tassi di conversione migliorano in modo significativo. Una catena di vendita al dettaglio può inviare automaticamente un'offerta promozionale a un membro del programma fedeltà nel momento stesso in cui entra nel negozio.
  • Profili Cliente Unificati: L'integrazione offre una vista a 360 gradi del cliente, fondendo i dati dell'e-commerce con il comportamento nel mondo fisico. Ciò consente a Customer Insights di generare modelli predittivi altamente accurati per il churn e il lifetime value.
  • Intelligence Operativa: Oltre al marketing, i dati di Wayfinding e del tempo di permanenza possono informare le decisioni operative, come l'ottimizzazione degli orari del personale in base alle ore di punta o la riprogettazione del layout dei negozi in base alla popolarità delle zone.

Implementando l'architettura a due livelli e aderendo alle best practice descritte in questa guida, i leader IT possono fornire una pipeline di dati robusta, conforme e di grande valore che potenzia l'intera organizzazione.

Définitions clés

Résolution d'identité

Le processus consistant à faire correspondre un identifiant d'appareil anonyme (comme une adresse MAC) à un profil client connu (comme une adresse e-mail) à travers plusieurs systèmes.

Crucial pour s'assurer que les données WiFi enrichissent le bon enregistrement de Contact dans Dynamics 365 plutôt que de créer des doublons.

Randomisation des adresses MAC

Une fonctionnalité de confidentialité dans les systèmes d'exploitation modernes (iOS, Android) où l'appareil génère une adresse MAC temporaire et aléatoire lors de la recherche ou de la connexion à des réseaux.

Force les intégrateurs à s'appuyer sur des données authentifiées (connexions via Captive Portal) plutôt que sur une détection réseau passive pour un suivi client précis.

Architecture d'entité à deux niveaux

Une approche de modélisation des données dans Dynamics 365 où les données de référence (Contact) sont séparées des données transactionnelles à volume élevé (Visites WiFi) à l'aide d'une relation 1:N.

Essentiel pour maintenir les performances de la base de données CRM et permettre une segmentation propre dans Customer Insights.

OData (Open Data Protocol)

Une norme approuvée par l'ISO/CEI et standardisée par l'OASIS qui définit un ensemble de meilleures pratiques pour la création et la consommation d'APIs RESTful.

Le protocole recommandé pour exécuter une synchronisation par lots efficace et à grande échelle des journaux de visites WiFi dans Dynamics 365.

Webhook

Une méthode pour augmenter ou modifier le comportement d'une page ou d'une application web avec des rappels (callbacks) personnalisés, transmettant les données à d'autres applications au moment où elles se produisent.

Utilisé pour envoyer des événements d'authentification WiFi en temps réel vers Dynamics 365 pour une activation marketing immédiate sur le point de vente.

Customer Insights

La plateforme de données client (CDP) de Microsoft qui unifie les données provenant de multiples sources pour créer une vue unique des clients et découvrir des insights.

La destination principale des données agrégées de visites WiFi pour créer des segments comportementaux complexes combinant les activités en ligne et hors ligne.

Captive Portal

Une page web que l'utilisateur d'un réseau d'accès public est obligé de consulter et avec laquelle il doit interagir avant que l'accès ne lui soit accordé.

Le point principal de capture des données et de collecte du consentement GDPR pour l'intégration Dynamics 365.

Temps de séjour

La durée pendant laquelle un visiteur reste connecté au réseau ou présent au sein d'une zone physique spécifique.

Une métrique clé envoyée à Dynamics 365 pour mesurer l'engagement sur le point de vente et déclencher des campagnes marketing basées sur la durée.

Exemples concrets

Un hôtel de 200 chambres doit déclencher un SMS personnalisé « Bienvenue au Spa » via Dynamics 365 Marketing lorsqu'un client VIP se connecte au WiFi dans la zone de bien-être.

  1. Configurer la plateforme Purple pour taguer les points d'accès de la zone de bien-être avec la zone « Spa ».
  2. Configurer un webhook en temps réel dans Purple qui se déclenche sur l'événement « Authentication Success », en filtrant pour la zone « Spa ».
  3. Le payload du webhook est envoyé à une Azure Logic App. La Logic App analyse le payload, extrait l'e-mail et l'adresse MAC du client.
  4. La Logic App interroge Dynamics 365 par e-mail pour vérifier le statut VIP du client et vérifier son indicateur de consentement marketing.
  5. Si le client est un VIP et a donné son consentement, la Logic App crée un nouvel enregistrement dans l'entité personnalisée cr_wifiVisit et déclenche un parcours Dynamics 365 Marketing spécifique qui envoie le SMS.
Commentaire de l'examinateur : Cette approche utilise correctement des webhooks en temps réel pour une activation immédiate tout en s'appuyant sur une couche middleware (Azure Logic Apps) pour gérer la logique métier et la déduplication avant d'appeler l'API Dynamics. Cela évite d'intégrer la logique marketing en dur dans la couche réseau.

Une chaîne de vente au détail comptant 50 points de vente souhaite créer un segment dans Dynamics 365 Customer Insights pour les « Clients en magasin inactifs » (les clients qui ont acheté en ligne récemment mais n'ont pas visité de magasin physique depuis 90 jours).

  1. Mettre en œuvre une synchronisation par lot nocturne (via OData) de la plateforme WiFi vers Dynamics 365.
  2. La synchronisation met à jour le champ cr_wifi_last_visit sur l'entité principale Contact pour tous les clients qui se sont connectés ce jour-là.
  3. Dans Dynamics 365 Customer Insights, ingérer l'entité Contact en tant que source de données.
  4. Créer une règle de segment : Condition 1 : Last_Online_Purchase_Date < il y a 30 jours ET Condition 2 : cr_wifi_last_visit > il y a 90 jours.
  5. Exporter ce segment vers Dynamics 365 Marketing pour une campagne d'e-mailing de réengagement ciblée.
Commentaire de l'examinateur : Ce scénario démontre la valeur de l'approche de synchronisation par lot pour les charges de travail analytiques. En mettant à jour un simple champ agrégé (`cr_wifi_last_visit`) sur la fiche contact principale, la logique de segmentation dans Customer Insights devient extrêmement efficace sans avoir à interroger des millions de journaux de visites individuels.

Questions d'entraînement

Q1. Votre équipe marketing souhaite envoyer un e-mail à tout client ayant visité le magasin phare plus de 5 fois ce mois-ci mais n'ayant effectué aucun achat en ligne. Comment devez-vous concevoir le flux de données pour prendre cela en charge sans surcharger le CRM ?

Conseil : Considérez l'architecture d'entités à deux niveaux et le rôle de Customer Insights.

Voir la réponse type

N'écrivez pas chaque visite dans l'entité Contact. Utilisez plutôt une synchronisation par lot nocturne pour pousser les journaux de visite vers une entité personnalisée cr_wifiVisit liée au Contact. Ensuite, utilisez Dynamics 365 Customer Insights pour ingérer à la fois l'entité de visite personnalisée et l'historique des achats e-commerce. Créez un segment dans Customer Insights combinant les deux critères (nombre de cr_wifiVisit > 5 ET achats en ligne = 0) et exportez ce segment vers Dynamics 365 Marketing.

Q2. Lors d'un exercice de test de charge, votre middleware (Azure Logic Apps) commence à recevoir des erreurs HTTP 429 (Too Many Requests) de la part de l'API Dynamics 365. Quel est le correctif architectural le plus approprié ?

Conseil : Pensez à la manière de découpler les événements réseau en temps réel du processus d'insertion de l'API.

Voir la réponse type

Implémentez une file d'attente de messages, telle qu'Azure Service Bus, entre le récepteur de webhook et le connecteur d'API Dynamics 365. Le webhook écrit immédiatement la charge utile dans la file d'attente, et un processus distinct lit la file d'attente et insère les enregistrements dans Dynamics 365 à un rythme contrôlé qui respecte les limites de l'API.

Q3. Un visiteur se connecte au WiFi en utilisant son adresse e-mail et accepte le consentement marketing. Trois semaines plus tard, il clique sur "Se désabonner" dans un e-mail marketing envoyé depuis Dynamics 365. Que doit-il se passer au niveau de la couche d'intégration ?

Conseil : Considérez le système d'enregistrement et les exigences de conformité.

Voir la réponse type

L'intégration doit être bidirectionnelle pour le consentement. Lorsque l'événement "Se désabonner" se produit dans Dynamics 365, un webhook ou un flux automatisé doit déclencher un appel API vers la plateforme Purple WiFi pour mettre à jour le profil du visiteur et révoquer son indicateur de consentement marketing. Cela garantit que les futures connexions WiFi ne réabonnent pas l'utilisateur par inadvertance ou ne déclenchent pas d'actions marketing non conformes.

Continuer la lecture de cette série

WLC Cisco Catalyst et WiFi invité : configuration du captive portal avec Purple

Comment un contrôleur LAN sans fil Cisco Catalyst 9800 (IOS-XE) fonctionne avec le WiFi invité de Purple : authentification web externe, RADIUS et walled garden, avec un lien vers le guide de configuration étape par étape de Purple pour les paramètres exacts.

Lire le guide →

Intégration de Salesforce avec le Guest WiFi pour l'Account Intelligence

Ce guide de référence technique détaille comment les équipes IT et RevOps peuvent intégrer les événements d'authentification du guest WiFi avec Salesforce pour générer de l'Account Intelligence exploitable. Il couvre l'architecture requise, la logique de résolution d'identité et les configurations de modèle de données nécessaires pour transformer les visites physiques sur site en signaux CRM de haute fidélité.

Lire le guide →

Comment intégrer les données WiFi invité à votre CRM

Ce guide fournit une référence technique complète pour les responsables informatiques, les architectes réseau et les directeurs marketing sur l'intégration des analyses WiFi invité avec les plateformes CRM telles que Salesforce et HubSpot. Il couvre la justification stratégique, les modèles d'architecture de base (API directe et Webhooks), les champs de données disponibles et un guide de déploiement étape par étape. Les exploitants de sites dans les secteurs de l'hôtellerie, du commerce de détail et de l'événementiel y trouveront des cadres exploitables pour mettre en place un pipeline de données de première partie conforme à la GDPR et évolutif, générant un ROI marketing mesurable.

Lire le guide →

Vous avez des questions sur votre configuration spécifique ?

Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.