Automatisation du marketing axée sur les événements et déclenchée par la présence WiFi

Bienvenue dans la série de briefings techniques de Purple. Je suis votre hôte, et aujourd'hui nous abordons un sujet au carrefour de l'infrastructure réseau et de la génération de revenus : l'automatisation de la présence WiFi — plus précisément, comment concevoir des systèmes marketing pilotés par les événements où la présence physique d'un client, détectée via votre réseau WiFi, devient le déclencheur de campagnes marketing personnalisées et en temps réel. Que vous soyez technologue marketing, architecte réseau ou directeur des opérations d'un site, ce briefing vous est destiné. Nous passerons en revue l'architecture de base, les considérations de latence qui séparent une bonne implémentation d'une expérience frustrante, le problème de déduplication que chaque équipe sous-estime, et les cadres de confidentialité que vous ne pouvez pas vous permettre d'ignorer. C'est parti. --- SECTION UN : POURQUOI LA PRÉSENCE EST LE SIGNAL MARKETING LE PLUS PRÉCIEUX QUE VOUS COLLECTEZ DÉJÀ Permettez-moi de commencer par une question. Votre site — qu'il s'agisse d'un hôtel, d'une chaîne de magasins, d'un stade ou d'un centre de congrès — dispose déjà d'une infrastructure WiFi. Vous générez déjà des événements de présence chaque fois qu'un appareil s'associe à un point d'accès. La question n'est pas de savoir si vous disposez des données. La question est de savoir si vous en faites quelque chose d'utile. Le marketing digital traditionnel repose sur des signaux d'intention : quelqu'un recherche un produit, clique sur une publicité, ouvre un e-mail. Ces signaux sont précieux, mais ils se produisent tous en dehors de votre établissement. L'automatisation de la présence WiFi repose sur un signal fondamentalement différent et sans doute plus puissant : la proximité physique. Le client est déjà là. Il a déjà pris la décision de vous rendre visite. Votre rôle est de rendre cette visite plus fructueuse — pour lui comme pour vous. Le défi architectural consiste à convertir un événement réseau brut — une association d'appareil, une requête de sonde, un bail DHCP — en une action marketing contextuelle et personnalisée dans un délai qui reste utile. Dans un environnement de vente au détail, cette fenêtre peut être de deux à cinq minutes. Dans un hôtel, vous disposez de l'intégralité du séjour. L'architecture doit être conçue autour de ces contraintes dès le premier jour. --- SECTION DEUX : L'ARCHITECTURE À QUATRE COUCHES Laissez-moi vous présenter l'architecture de référence que nous recommandons pour l'automatisation de la présence WiFi en entreprise. Elle comporte quatre couches distinctes, et il est essentiel de bien définir les limites entre elles. La première couche est la couche réseau. Il s'agit de votre infrastructure physique : points d'accès, contrôleurs et serveur RADIUS qui gère l'authentification. La décision de conception clé ici concerne les événements que vous faites remonter du réseau. Vous disposez de trois options. Premièrement, les requêtes de sonde — des signaux passifs provenant d'appareils recherchant des réseaux connus. Deuxièmement, les événements d'association — le moment où un appareil se connecte avec succès à votre SSID. Troisièmement, les événements de session authentifiée — où vous disposez d'une identité utilisateur confirmée liée à un appareil, généralement via une connexion par Captive Portal ou une authentification 802.1X. Je vous recommande vivement de baser votre automatisation sur les événements de session authentifiée, et non sur les requêtes de sonde. Voici pourquoi. Depuis iOS 14 et Android 10, Apple et Google ont tous deux implémenté la randomisation des adresses MAC par défaut. Un appareil recherchant des réseaux présentera une adresse MAC aléatoire qui change par réseau et, dans certaines implémentations, par session. Si vous construisez un système de détection de présence basé sur le suivi des adresses MAC par sonde, vous construisez sur du sable. Les événements d'association liés à une connexion par Captive Portal vous fournissent un identifiant persistant et lié au consentement qui survit à la randomisation des adresses MAC. La deuxième couche est le moteur de présence. C'est là que les événements réseau bruts sont transformés en signaux de présence significatifs. La plateforme de Purple gère cela via l'Event Stream Engine, qui remplit quatre fonctions critiques. La détection et le filtrage des sondes — pour distinguer les visites réelles des signaux de passage. Le traitement des événements d'association — pour capturer le moment de la connexion authentifiée. Le calcul du temps de séjour — pour déterminer depuis combien de temps un appareil est présent avant le déclenchement d'une action. Et la déduplication — pour éviter qu'un même appareil ne déclenche plusieurs fois la même campagne au cours d'une fenêtre de suppression. Le composant de déduplication mérite une attention particulière. Dans un environnement de vente au détail très fréquenté, un même appareil peut s'associer, se déconnecter et se réassocier à votre réseau plusieurs fois en une heure au fur et à mesure que le client se déplace dans les différentes zones du magasin. Sans un moteur de déduplication robuste, vous enverrez le même message de bienvenue trois fois en quarante minutes. Ce n'est pas de la personnalisation, c'est du harcèlement. La fenêtre de suppression doit être configurable par type de campagne, par type d'établissement et par segment d'utilisateurs. La troisième couche est la couche d'automatisation. C'est là que réside la logique métier. Dans l'implémentation de Purple, il s'agit de LogicFlow — un moteur de workflow visuel qui permet aux équipes marketing et opérationnelles de définir des conditions de déclenchement, des logiques d'aiguillage et des séquences d'actions sans écrire de code. Le principe architectural clé ici est que la couche d'automatisation doit être découplée de la couche réseau. Les modifications apportées à la logique de votre campagne ne doivent pas nécessiter de modifications de la configuration de votre réseau, et inversement. Cette séparation des responsabilités est ce qui permet aux équipes marketing d'itérer sur les campagnes sans solliciter le service informatique pour chaque modification. La quatrième couche est la couche de diffusion. C'est là que l'action déclenchée atteint concrètement le client : un e-mail, un SMS, une notification push, un webhook vers votre CRM ou une mise à jour de votre plateforme de fidélité. La considération de conception critique ici est que la couche de diffusion doit respecter les données de consentement et de préférence capturées sur le Captive Portal. Si un client a consenti aux SMS mais pas aux e-mails, votre automatisation doit respecter ce choix. Ce n'est pas seulement une bonne pratique — en vertu du GDPR et de la PECR, c'est une obligation légale. --- SECTION TROIS : LA LATENCE — CE QUI EST ACCEPTABLE ET CE QUI NE L'EST PAS Laissez-moi vous donner les chiffres, car c'est là que de nombreuses implémentations échouent. La latence de bout en bout dans un système d'automatisation de la présence WiFi correspond au délai entre l'association d'un appareil à votre réseau et la réception par le client du communication déclenchée. Dans un système bien architecturé sur une infrastructure moderne, cela devrait être réalisable en moins de dix secondes pour la plupart des types de sites. Cependant, la latence acceptable varie considérablement selon le contexte. Dans un hub de transport — un aéroport ou un terminal ferroviaire — vous pouvez avoir un visiteur qui se connecte au WiFi pendant trois minutes en attendant un changement de porte d'embarquement. Votre déclencheur doit s'activer dans les soixante à quatre-vingt-dix secondes suivant la connexion, sinon le moment est passé. Dans un hôtel, où le client restera sur place pendant douze à quarante-huit heures, une latence de dix ou même trente secondes est tout à fait acceptable. Le budget de latence se décompose en trois éléments. La latence réseau-plateforme : le temps nécessaire pour que l'événement d'association voyage du contrôleur de point d'accès vers la plateforme Purple. Dans un déploiement connecté au cloud avec un contrôleur bien configuré, cela devrait prendre moins d'une seconde. La latence de traitement de la plateforme : le temps nécessaire à l'Event Stream Engine pour classifier l'événement, vérifier la déduplication, évaluer les conditions d'automatisation et envoyer l'action. Dans l'architecture de Purple, cela prend généralement moins de deux secondes. La latence du canal de diffusion : le temps nécessaire au canal en aval — fournisseur d'accès de messagerie, passerelle SMS, service de notification push — pour distribuer le message. C'est le composant sur lequel vous avez le moins de contrôle, et c'est là que réside la majeure partie de la variance. L'envoi de SMS via une passerelle de niveau 1 prend généralement moins de fiv secondes. La distribution d'e-mails peut varier de deux secondes à deux minutes selon le serveur de messagerie du destinataire. L'implication pratique : si vous avez besoin d'une distribution de bout en bout en moins de dix secondes, les SMS ou les notifications push sont vos seules options fiables. L'e-mail n'est pas un canal en temps réel, et vous ne devriez pas concevoir votre automatisation de présence comme s'il l'était. --- SECTION QUATRE : LE PROBLÈME DE LA DÉDUPLICATION EN PROFONDEUR Je souhaite passer quelques minutes sur la déduplication car c'est le composant qui cause le plus fréquemment des problèmes de production dans les déploiements d'automatisation de présence. Le problème de base est le suivant : une seule visite physique peut générer des dizaines d'événements réseau. Un client entre dans votre hôtel, se connecte au WiFi dans le hall, se rend dans sa chambre, l'appareil perd brièvement le signal et se reconnecte, il se rend au restaurant et l'appareil bascule sur un autre point d'accès. Du point de vue du réseau, cela représente potentiellement quatre ou cinq événements d'association. Du point de vue du client, il s'agit d'une seule visite. Votre moteur de déduplication doit fonctionner à deux niveaux. La déduplication au niveau de l'appareil regroupe plusieurs événements d'association du même appareil au cours d'une même fenêtre de session en un seul événement de présence. Une fenêtre de session de quinze à trente minutes est appropriée pour la plupart des types de sites — si un appareil se déconnecte et se reconnecte dans cette fenêtre, cela est traité comme la continuation de la même session, et non comme une nouvelle visite. La déduplication au niveau de la campagne empêche la même campagne de se déclencher pour le même client au cours d'une fenêtre de suppression. Cette fenêtre doit être configurable par campagne. Un message de bienvenue devrait avoir une fenêtre de suppression égale à la durée d'un séjour typique — sept jours pour un hôtel, vingt-quatre heures pour un magasin de détail. Une offre limitée dans le temps pourrait avoir une fenêtre de suppression de seulement quatre heures. Un rappel de points de fidélité pourrait être supprimé pendant trente jours. La troisième considération de déduplication est la déduplication multi-appareils. Si un client s'est déjà connecté à votre réseau sur son ordinateur portable et son téléphone, et que les deux appareils sont présents simultanément, vous devez déclencher la campagne une seule fois, et non deux. Cela nécessite une capacité de liaison de profils — généralement mise en œuvre via l'adresse e-mail ou l'identifiant de fidélité saisi sur le Captive Portal — qui associe plusieurs appareils à un profil client unique. --- SECTION CINQ : CADRES DE CONFIDENTIALITÉ — LES INCONTOURNABLES Permettez-moi d'être direct concernant le paysage réglementaire, car j'ai vu des implémentations qui étaient techniquement excellentes mais légalement problématiques. Sous le GDPR et le GDPR britannique, le traitement des données de localisation d'un client — ce que constitue concrètement la détection de présence WiFi — nécessite une base légale. Les deux bases les plus couramment applicables sont le consentement et l'intérêt légitime. Le consentement est l'option la plus claire : le client accepte explicitement le marketing basé sur la présence lors de sa connexion au Captive Portal. L'intérêt légitime nécessite un test de mise en balance documenté démontrant que votre intérêt à envoyer la communication ne l'emporte pas sur les droits à la vie privée du client. Pour la plupart des cas d'usage marketing, le consentement est la base la plus sûre et la plus défendable. La PECR — la réglementation sur la confidentialité et les communications électroniques — ajoute une couche supplémentaire pour le marketing électronique. L'envoi d'un SMS ou d'un e-mail marketing déclenché par la présence WiFi nécessite le consentement préalable du destinataire, indépendamment de votre base légale GDPR. Ce consentement doit être spécifique, éclairé et librement donné. Une case pré-cochée sur un Captive Portal ne constitue pas un consentement PECR valide. Sur le plan technique, la randomisation des adresses MAC a effectivement mis fin à l'ère du suivi passif des appareils sans consentement. Toute architecture qui repose sur le suivi d'adresses MAC randomisées sans le consentement de l'utilisateur est à la fois techniquement peu fiable et juridiquement contestable. La bonne approche consiste à utiliser l'identifiant de session authentifié — l'adresse e-mail ou l'identifiant de fidélité — comme clé de suivi principale, l'adresse MAC étant uniquement utilisée comme identifiant de corrélation au niveau de la session. La conformité PCI DSS exige que votre réseau WiFi invité soit complètement isolé de tout segment de réseau qui traite des données de cartes de paiement. Cela signifie au minimum une séparation par VLAN, avec des règles de pare-feu empêchant tout flux de trafic entre le réseau invité et le réseau de paiement. Votre plateforme d'automatisation de présence doit se situer sur le segment de réseau invité ou s'y connecter, jamais sur le réseau de paiement. --- SECTION SIX : RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES COURANTS Permettez-moi de vous donner les cinq recommandations que je donne à chaque client avant qu'il ne lance un déploiement d'automatisation de présence. Premièrement : commencez par votre modèle de données, pas par vos campagnes. Avante vous configurez une seule règle d'automatisation, définissez votre modèle d'identité invité. Quel est l'identifiant principal ? Comment gérez-vous les appareils multiples par invité ? Comment liez-vous l'identité WiFi à votre CRM ou à votre plateforme de fidélité ? Se tromper au départ crée une dette technique coûteuse à résoudre. Deuxièmement : configurez votre déduplication avant la mise en service. Exécutez le système en mode observation — en enregistrant les événements sans lancer de campagnes — pendant au moins deux semaines avant le lancement. Cela vous donne des données réelles sur la fréquence de vos événements d'association, vos profils de session typiques et vos taux de ré-visite. Utilisez ces données pour calibrer vos fenêtres de suppression. Troisièmement : concevez votre flux de consentement avant votre flux de campagne. Le Captive Portal n'est pas seulement un mécanisme d'accès au réseau — c'est votre point de capture du consentement. Chaque activité de traitement de données que vous prévoyez d'effectuer doit être divulguée et consentie à ce stade. Travaillez avec votre équipe juridique pour vous assurer que la formulation du consentement est suffisamment spécifique pour être valide en vertu de la PECR. Quatrièmement : testez votre latence sous charge. Un système d'automatisation de présence qui fonctionne bien avec dix connexions simultanées peut se dégrader considérablement avec un millier. Testez la charge de votre pipeline de traitement des événements à deux ou trois fois votre nombre maximal attendu d'appareils simultanés avant de lancer l'activité lors d'un événement majeur ou d'une période de pointe commerciale. Cinquièmement : intégrez la gestion des suppressions dans votre flux de travail opérationnel. Les équipes marketing voudront lancer plusieurs campagnes simultanément. Sans une hiérarchie de suppression claire — quelle campagne est prioritaire lorsque plusieurs déclencheurs s'activent simultanément — vous vous retrouverez avec des invités recevant trois messages en cinq minutes. Définissez la hiérarchie avant le lancement des campagnes, pas après la première plainte. --- Q&R RAPIDES Question : Puis-je utiliser l'automatisation de présence WiFi sans Captive Portal ? Réponse : Techniquement oui, en utilisant la détection basée sur les requêtes de sonde, mais pratiquement non pour tout cas d'usage marketing conforme. Sans Captive Portal, vous n'avez aucun mécanisme de capture de consentement et aucun identifiant d'invité persistant. Vous suivez des adresses MAC aléatoires sans base légale. Ne le faites pas. Question : Quelle est la densité minimale de points d'accès pour une détection de présence fiable ? Réponse : Pour une précision du temps de séjour à moins de cinq mètres, vous avez besoin d'une couverture chevauchante d'au moins trois points d'accès. Pour une présence au niveau de la zone — savoir qu'un invité est dans le magasin, pas dans quel rayon — un point d'accès par zone suffit. Concevez votre densité de points d'accès en fonction de votre cas d'usage. Question : Comment intégrer le flux d'événements de Purple avec mon CRM existant ? Réponse : Purple prend en charge l'envoi d'événements via webhook et des intégrations natives via Zapier et API directe. Pour les plateformes CRM d'entreprise comme Salesforce ou HubSpot, l'approche recommandée est un webhook vers une couche intermédiaire qui gère la transformation des données et les appels API du CRM. Cela permet de garder l'intégration lâchement couplée et plus facile à maintenir. --- RÉSUMÉ ET PROCHAINES ÉTAPES L'automatisation de présence WiFi est l'une des applications au ROI le plus élevé de votre infrastructure réseau existante. La technologie est mature, le cadre réglementaire est clair et les modèles de mise en œuvre sont bien établis. La différence entre un déploiement réussi et un déploiement problématique se résume à trois choses : un modèle d'identité robuste qui résiste à la randomisation MAC, un moteur de déduplication calibré pour votre site et vos profils de visite spécifiques, et une architecture de consentement qui satisfait aux exigences du GDPR et de la PECR. Si vous évaluez Purple pour ce cas d'usage, les deux composants sur lesquels vous devez vous concentrer sont l'Event Stream Engine pour le traitement des signaux de présence et LogicFlow pour la logique d'automatisation. Tous deux sont conçus pour fonctionner à l'échelle de l'entreprise avec la configurabilité dont vous avez besoin pour gérer plusieurs types de sites et de campagnes à partir d'une seule plateforme. Pour vos prochaines étapes : examinez la formulation actuelle du consentement de votre Captive Portal par rapport aux exigences de la PECR, auditez votre infrastructure WiFi existante pour vérifier l'adéquation de la densité des points d'accès, et définissez votre modèle d'identité invité avant de toucher à toute configuration d'automatisation. Merci d'avoir écouté la série de briefings techniques de Purple. La documentation complète, les guides d'architecture et les références d'intégration sont disponibles sur purple.ai.