HubSpot et Guest WiFi : Enrichissement et segmentation des leads

Ce guide fournit aux responsables informatiques, aux administrateurs HubSpot et aux équipes des opérations marketing un manuel d'intégration pratique pour connecter Purple Guest WiFi à HubSpot. Il couvre l'architecture technique complète — de la capture de données du Captive Portal et du mappage des propriétés à l'automatisation des étapes du cycle de vie, la déduplication et la segmentation des listes — permettant aux exploitants de sites de convertir les connexions WiFi anonymes en contacts CRM enrichis et exploitables.

📖 9 min de lecture📝 2,047 mots🔧 2 exemples❓ 3 questions📚 9 termes clés

🎧 Écouter ce guide

Voir la transcription

Welcome to the Purple Integration Playbook. I'm your host, and today we are looking at the architecture of our native HubSpot integration. Specifically, how to pipe guest WiFi data into HubSpot for lead enrichment and segmentation. If you are an IT manager, a network architect, or managing CRM operations at a large venue — whether that's a stadium, a retail chain, or a hotel — this session is for you. We are skipping the marketing fluff. Today is about data flow, property mapping, and lifecycle automation. Let's get into it.

First, let's establish the context. The guest WiFi network is one of the most underutilised data assets in any venue. Every time a visitor connects, they are providing a verified identity signal — their name, their email address, and crucially, their explicit consent to be contacted. Most organisations capture this data and then let it sit in a disconnected WiFi management platform, completely isolated from the CRM. That is a significant missed opportunity. The Purple HubSpot integration exists specifically to close that gap.

Now, let's start with the data capture layer. When a guest connects to the network via the captive portal, the Purple platform authenticates the session. At this point, the user provides demographic data — typically first name, last name, and email address — along with explicit consent for marketing. This consent mechanism is critical. It must align with GDPR requirements, which means the consent checkbox on the portal must be unticked by default and the user must actively opt in. This is not just a legal requirement; it is the mechanism that determines whether the data you capture is actually usable for outbound marketing.

Once the session is authenticated, the native integration triggers an API call to HubSpot. The data is transmitted as a JSON payload over a secure HTTPS connection. But how exactly does this map to the CRM? Let's break it down.

The standard fields map directly and cleanly. First Name maps to the HubSpot property firstname. Last Name maps to lastname. Email Address maps to email. These are native HubSpot contact properties and require no additional configuration. However, the real value of this integration lies in custom property alignment. The WiFi network generates rich behavioural data that has no native home in HubSpot. You need to create custom properties to store it.

I recommend creating the following custom properties in HubSpot before you activate the integration. First, wifi last visit — this should be a Date picker property type. It records the most recent date the contact authenticated via WiFi. Second, wifi venue — a Single-line text property. This is essential for multi-location deployments. Third, wifi session count — a Number property. This tracks how many times the contact has connected across all visits. Fourth, wifi dwell time — another Number property, recording the average session duration in minutes. These four custom properties are the foundation of your segmentation strategy.

Now, let's talk about deduplication. This is a common failure point in WiFi-to-CRM integrations, and it is worth spending time on. HubSpot uses the email address as the primary unique identifier for contact records. When the Purple payload arrives at the HubSpot API endpoint, HubSpot performs a lookup. If a contact with that email address already exists, HubSpot updates the existing record with the new data. If it doesn't, it creates a new contact. This is the correct behaviour, and it means you should never end up with duplicate records for the same person — provided the email address is consistent.

The risk here is dirty data at the source. If your captive portal allows users to enter a malformed email address — or worse, a fake one — you will create orphaned records in HubSpot that can never be matched or emailed. The mitigation is straightforward: enforce strict email format validation on the portal form. Make the email field mandatory and validate the format on submission. This is a configuration option within the Purple portal and should be enabled as a baseline requirement.

Moving on to lifecycle stage automation. This is where the integration moves from data capture to genuine marketing intelligence. The default behaviour for many teams is to set the lifecycle stage of every new WiFi contact to Lead. I would strongly advise against this. It conflates a one-time visitor with a genuinely interested prospect, and it will inflate your lead numbers while degrading the quality of your pipeline.

Instead, implement a tiered, event-driven lifecycle model. On the first WiFi login, set the lifecycle stage to Subscriber. When the wifi session count property reaches two or more within a rolling 30-day window, trigger a workflow that transitions the contact to Marketing Qualified Lead. When the wifi dwell time exceeds 45 minutes across multiple visits, transition the contact to Sales Qualified Lead. Finally, when a loyalty programme tag is applied, transition the contact to Customer.

A major pitfall at this stage is failing to map the legal basis for processing. Always map the marketing consent checkbox from the captive portal to the hs legal basis property in HubSpot. If you skip this, your marketing team won't be able to email these contacts, rendering the integration useless for outbound campaigns.

Let's hit a few common questions quickly.

Does the integration support multi-venue deployments? Yes, absolutely. Pass the venue identifier from Purple into the custom wifi venue property in HubSpot. This allows regional marketing teams to segment lists by location. For a retail chain with 50 stores, this means each store manager can have a list of contacts who visited their specific location.

What happens if the HubSpot API rate limit is hit? The Purple platform queues payloads and retries failed requests. However, for very high-density environments — think a stadium with 50,000 concurrent authentications at kick-off — you should be aware of your HubSpot API tier limits and plan accordingly.

To summarise the key points. Map your standard demographic fields first to establish identity in HubSpot. Then create and map the custom properties — wifi last visit, wifi venue, wifi session count, and wifi dwell time — to enable segmentation. Always rely on the email address as the primary key for deduplication, and enforce email validation on the portal. Do not default all contacts to Lead. Use WiFi session data to trigger event-driven lifecycle stage progressions. And critically, always map marketing consent to hs legal basis before you go live.

For your next step, audit your current captive portal form fields against your HubSpot property configuration. Map every field to a corresponding property. Every data point you collect should have a purpose and a home in the CRM.

Thanks for listening to the Purple Integration Playbook. We'll see you on the next deployment.

Résumé Exécutif

Pour les sites d'entreprise — des vastes chaînes de magasins aux stades à forte capacité — le réseau Guest WiFi est l'une des couches d'acquisition de données les plus sous-utilisées de la pile technologique. Chaque session authentifiée représente un signal d'identité vérifié : un nom, une adresse e-mail et un consentement marketing explicite. Pourtant, la majorité des organisations laissent ces données isolées au sein de leur plateforme de gestion WiFi, entièrement déconnectées du CRM. L'intégration Purple HubSpot comble cette lacune en établissant un pipeline de données en temps réel, basé sur les événements, entre le Captive Portal et HubSpot.

Ce guide couvre l'architecture de déploiement complète : comment mapper les champs du portail Guest WiFi aux propriétés standard et personnalisées de HubSpot, comment configurer la logique de déduplication, comment créer des workflows d'étapes du cycle de vie déclenchés par les événements de session WiFi, et comment segmenter les contacts en listes exploitables. Il est destiné aux administrateurs HubSpot, aux responsables des opérations marketing et aux architectes informatiques qui doivent implémenter cette intégration dans un environnement de production, et non l'évaluer en théorie.

Approfondissement Technique

Architecture et Flux de Données

L'intégration fonctionne sur une architecture basée sur des webhooks. Lorsqu'un utilisateur s'authentifie via le Captive Portal Purple, la plateforme agit comme fournisseur d'identité, validant la session et générant une charge utile JSON structurée contenant les données démographiques et de session de l'utilisateur. Cette charge utile est transmise via un appel API REST HTTPS sécurisé au point de terminaison de l'API Contacts de HubSpot.

Le flux de données suit quatre étapes distinctes : l'authentification au niveau du portail, la génération de la charge utile par la plateforme Purple, la transmission API à HubSpot, et la création ou la mise à jour de l'enregistrement au sein du CRM. Pour les déploiements multi-sites — courants dans les environnements de Commerce de Détail et d' Hôtellerie — l'identifiant du site est intégré dans la charge utile au moment de la génération, garantissant que chaque enregistrement de contact contient le contexte de localisation requis pour la segmentation régionale.

La couche WiFi Analytics au sein de Purple génère les métriques comportementales — nombre de sessions, temps de présence, fréquence de visite — qui sont transmises avec les données démographiques. Ces métriques sont le facteur différenciant entre une simple capture d'e-mail et un contact CRM véritablement enrichi.

Mécanismes de Mappage des Propriétés

Un mappage précis des propriétés est le fondement d'une intégration fiable. Les propriétés de contact natives de HubSpot gèrent les champs démographiques standard, mais les données comportementales spécifiques au WiFi nécessitent la création de propriétés personnalisées avant l'activation de l'intégration.

Le tableau suivant définit la configuration de mappage des propriétés recommandée :

Champ du Portail	Propriété HubSpot	Type de Propriété	Notes
Prénom	`firstname`	Texte sur une seule ligne	Propriété native HubSpot
Nom de Famille	`lastname`	Texte sur une seule ligne	Propriété native HubSpot
Adresse E-mail	`email`	E-mail	Clé de déduplication primaire
Numéro de Téléphone	`phone`	Numéro de téléphone	Propriété native HubSpot
Date de Naissance	`date_of_birth`	Sélecteur de date	Propriété personnalisée requise
Code Postal	`zip`	Texte sur une seule ligne	Propriété native HubSpot
Consentement Marketing	`hs_legal_basis`	Texte sur une seule ligne	Défini sur 'Consentement librement donné'
Horodatage de Visite	`wifi_last_visit`	Sélecteur de date	Propriété personnalisée requise
Nom du Site	`wifi_venue`	Texte sur une seule ligne	Propriété personnalisée requise
Nombre de Sessions	`wifi_session_count`	Nombre	Propriété personnalisée requise
Temps de Présence (min)	`wifi_dwell_time`	Nombre	Propriété personnalisée requise

Les quatre propriétés personnalisées — wifi_last_visit, wifi_venue, wifi_session_count, et wifi_dwell_time — doivent être créées dans HubSpot avant l'activation de l'intégration. Le fait de ne pas pré-créer ces propriétés entraînera la suppression silencieuse des données de la charge utile par l'API HubSpot.

Déduplication et Résolution d'Identité

HubSpot utilise l'adresse e-mail comme identifiant unique principal pour les enregistrements de contacts. Lorsque la charge utile Purple est reçue, HubSpot effectue une recherche parmi les enregistrements existants. Si un contact avec l'adresse e-mail correspondante existe, HubSpot met à jour l'enregistrement avec les nouvelles données de session — en incrémentant wifi_session_count et en mettant à jour wifi_last_visit. Si aucune correspondance n'est trouvée, un nouvel enregistrement de contact est créé.

Ce comportement est déterministe et fiable, à condition que l'adresse e-mail soit cohérente d'une visite à l'autre. Le risque principal est la présence de données erronées à la source. Si le Captive Portal autorise des adresses e-mail mal formées ou fausses, des enregistrements orphelins sont créés dans HubSpot qui ne peuvent pas être mis en correspondance lors des visites ultérieures et ne peuvent pas être contactés par e-mail. La solution consiste à appliquer une validation stricte du format d'e-mail RFC 5322 sur le formulaire du portail, en rendant le champ e-mail obligatoire avec une validation côté serveur. Ceci est une option configurable dans les paramètres du portail Purple et doit être considérée comme une exigence de base non négociable.

Pour les organisations opérant dans les environnements de Santé ou du secteur public où la conformité GDPR est soumise à audit, il convient également de noter que le mécanisme de déduplication signifie qu'un seul enregistrement de contact consolide tout l'historique des visites. Cela simplifie les réponses aux demandes d'accès des personnes concernées (SAR) et les demandes de suppression de données en vertu de l'Article 17 du GDPR.

Guide d'Implémentation

Étape 1 : Pré-configurer les Propriétés Personnalisées de HubSpot

Naviguer vers Paramètres HubSpot > Propriétés > Propriétés des contacts. Créez les quatre propriétés personnalisées listées dans le tableau de mappage ci-dessus. Assurez-vous que les types de données sont correctement définis — wifi_last_visit doit être un sélecteur de date, wifi_session_count et wifi_dwell_time doivent être des types numériques. Des types de données incorrects entraîneront le rejet des valeurs de la charge utile par l'API.

Étape 2 : Auditer et aligner les champs du Captive Portal

Examinez la configuration actuelle du Captive Portal Purple. Assurez-vous que le champ Email est défini comme obligatoire avec la validation de format activée. Pour les déploiements multi-sites, confirmez que l'identifiant de site est configuré pour être transmis dynamiquement en fonction de l'emplacement du point d'accès. Les sites dans des environnements de Transport — tels que les aéroports ou les gares ferroviaires — peuvent avoir plusieurs zones au sein d'un même site, chacune nécessitant un identifiant de site distinct.

Étape 3 : Configurer le mappage des propriétés dans Purple

Dans les paramètres d'intégration HubSpot de la plateforme Purple, mappez chaque champ du portail au nom de propriété interne HubSpot correspondant. Utilisez les noms de propriété internes exacts (par exemple, wifi_session_count, et non WiFi Session Count) pour garantir que la charge utile de l'API est correctement structurée.

Étape 4 : Établir l'automatisation des étapes du cycle de vie

Ne définissez pas par défaut toutes les nouvelles connexions WiFi à l'étape du cycle de vie 'Lead'. Implémentez un modèle hiérarchisé basé sur les événements à l'aide des workflows HubSpot.

La progression recommandée du cycle de vie est la suivante. Lors de la première connexion WiFi, définissez l'étape du cycle de vie sur Abonné — l'étape HubSpot correcte pour un contact qui a fourni ses coordonnées mais n'a pas encore démontré d'intention comportementale. Lorsque wifi_session_count atteint 2 ou plus sur une période glissante de 30 jours, déclenchez un workflow pour faire passer le contact à Lead Qualifié Marketing (MQL). Lorsque wifi_dwell_time dépasse 45 minutes sur plusieurs sessions, passez à Lead Qualifié Commercial (SQL). Lorsqu'une balise de programme de fidélité est appliquée, passez à Client.

Dans HubSpot, construisez chaque transition comme un workflow distinct avec le déclencheur défini sur 'La valeur de la propriété du contact change'. Cela garantit que la transition se déclenche immédiatement lorsque le seuil est franchi, plutôt que d'attendre un processus par lots planifié.

Étape 5 : Mapper la base juridique du traitement

Cette étape est non négociable pour la conformité au GDPR. La case à cocher de consentement marketing sur le Captive Portal doit être mappée à la propriété hs_legal_basis de HubSpot. Lorsqu'un utilisateur donne son consentement, la valeur doit être définie sur Freely given consent from the contact. Sans ce mappage, les contrôles de conformité intégrés de HubSpot bloqueront l'envoi d'e-mails sortants à ces contacts, rendant l'intégration commercialement inutile pour l'automatisation du marketing.

Étape 6 : Construire des listes de segmentation

Avec des données de propriété circulant correctement, créez des listes actives HubSpot pour les principaux cas d'utilisation de la segmentation. Exemples : tous les contacts où wifi_venue = un emplacement spécifique (pour les campagnes géo-ciblées), tous les contacts où wifi_session_count >= 5 (pour les programmes de fidélité), et tous les contacts où wifi_last_visit est dans les 30 derniers jours (pour le réengagement basé sur la récence).

Bonnes pratiques

Appliquer la validation des e-mails à la source. Tout problème de qualité des données dans HubSpot provenant de l'intégration WiFi peut être attribué à une adresse e-mail mal validée. Traitez le formulaire du portail comme la première ligne de défense pour la qualité des données CRM.

Segmenter par site dès le premier jour. Pour tout déploiement couvrant plusieurs emplacements — qu'il s'agisse d'un parc de magasins, d'un groupe hospitalier ou d'un complexe de stades — la propriété wifi_venue est la dimension de segmentation la plus importante. Configurez-la correctement dès le départ. La mise en place rétroactive de la segmentation par site après la création de milliers de contacts sans cette propriété représente un effort de correction considérable.

Respecter l'architecture du consentement. Le principe GDPR de limitation de la finalité signifie que les données collectées via un portail WiFi à des fins d'accès au réseau ne peuvent pas être automatiquement réutilisées pour le marketing direct sans consentement explicite. Le mappage hs_legal_basis n'est pas une technicité — c'est le mécanisme juridique qui autorise le cas d'utilisation marketing.

Surveiller le débit de l'API. Pour les environnements à haute densité tels que les stades ou les centres de conférence, le volume d'authentifications simultanées pendant les périodes de pointe peut solliciter l'API HubSpot. Purple met en file d'attente les charges utiles et réessaie les requêtes échouées, mais il est conseillé de surveiller les volumes d'appels API dans le tableau de bord des développeurs HubSpot lors d'événements majeurs et de s'assurer que le niveau de compte HubSpot prend en charge le débit requis.

Utiliser des mises à jour incrémentielles, pas des écrasements complets. Lorsqu'un visiteur récurrent se connecte, la charge utile ne doit mettre à jour que les propriétés modifiées (wifi_last_visit, wifi_session_count) plutôt que d'écraser tous les champs. Cela évite la perte accidentelle de données si, par exemple, un contact a mis à jour son nom directement dans HubSpot.

Dépannage et atténuation des risques

Problème : Des contacts sont créés mais ne peuvent pas recevoir d'e-mails marketing. Cause première : La propriété hs_legal_basis n'a pas été mappée ou a été mappée avec une chaîne de valeur incorrecte. Résolution : Vérifiez la valeur exacte de la chaîne transmise. HubSpot exige Freely given consent from the contact — toute variation fera échouer silencieusement la vérification de conformité.

Problème : Des enregistrements de contacts en double apparaissent dans HubSpot. Cause première : Plusieurs adresses e-mail sont soumises par le même utilisateur (par exemple, personnelle et professionnelle), ou le champ e-mail n'est pas obligatoire sur le portail. Résolution : Activez la validation obligatoire des e-mails sur le portail. Envisagez de mettre en œuvre un workflow de fusion dans HubSpot pour consolider les enregistrements où le même nom apparaît avec différentes adresses e-mail.

Problème : Les propriétés personnalisées ne sont pas renseignées malgré l'intégration active. Cause première : Les propriétés personnalisées n'ont pas été créées dans HubDétecté avant l'activation de l'intégration, ou les noms de propriété internes dans la configuration de mappage Purple ne correspondent pas exactement aux noms internes des propriétés HubSpot. Résolution : Vérifiez les noms de propriété internes dans les Paramètres HubSpot > Propriétés par rapport à la configuration de mappage dans Purple. Les noms internes sont sensibles à la casse et utilisent des tirets bas, pas des espaces.

Problème : L'étape du cycle de vie ne progresse pas malgré l'atteinte du seuil de nombre de sessions. Cause première : Le déclencheur du workflow HubSpot est défini sur 'Le contact est inscrit' plutôt que sur 'La valeur de la propriété du contact change'. Résolution : Reconstruisez le workflow avec le type de déclencheur correct. 'La valeur de la propriété du contact change' se déclenche chaque fois que la propriété est mise à jour, ce qui est le mécanisme correct pour la progression basée sur un seuil.

Risque : Non-conformité au GDPR en raison de la rétention des données. Atténuation : Mettez en œuvre un workflow HubSpot qui marque les contacts comme inactifs après 24 mois sans activité WiFi (c'est-à-dire, si wifi_last_visit remonte à plus de 24 mois). Déclenchez un e-mail de re-consentement. Si aucune réponse n'est reçue dans les 30 jours, supprimez le contact de toutes les communications marketing. Cela s'aligne sur le principe de limitation de la conservation du GDPR.

ROI et impact commercial

Le cas commercial de l'intégration Purple HubSpot est simple : elle transforme un coût passif d'infrastructure réseau en un pipeline de données actif générant des revenus. Les indicateurs clés de performance pour mesurer le succès du déploiement sont :

KPI	Méthode de mesure	Cible de référence
Nouveaux contacts générés	Rapport de source de contact HubSpot	15–25 % des sessions WiFi mensuelles
Précision de la synchronisation des données	% de contacts avec les 4 propriétés personnalisées renseignées	> 95 %
Taux de délivrabilité des e-mails	Tableau de bord de la santé des e-mails HubSpot	> 90 %
Taux de conversion MQL des contacts WiFi	Rapport de progression des étapes du cycle de vie	> 8 % en 90 jours
Taux d'ouverture des campagnes (contacts provenant du WiFi)	Analyses d'e-mails HubSpot	> 25 % (contre 18 % de moyenne sectorielle)

Dans un déploiement hôtelier, un hôtel de 300 chambres générant 2 000 connexions WiFi uniques par mois peut s'attendre à ajouter environ 400 à 500 nouveaux contacts enrichis à HubSpot chaque mois, en supposant un taux de conversion de 20 à 25 % de la connexion à la complétion du formulaire. Avec un taux de conversion MQL conservateur de 10 %, cela représente 40 à 50 nouveaux leads qualifiés pour le marketing par mois à partir d'une source de données qui générait auparavant zéro valeur CRM.

Pour une chaîne de magasins opérant sur 50 sites, le volume de données agrégées est considérablement plus élevé, et la valeur de segmentation — en particulier la capacité à cibler les contacts par emplacement de magasin spécifique — permet des campagnes promotionnelles hyper-localisées qui surpassent constamment les e-mails de diffusion génériques en termes de taux d'ouverture et de conversion.

Termes clés et définitions

Captive Portal

The web-based authentication page presented to users before they are granted access to a guest WiFi network. It serves as the primary data capture interface where demographic information and marketing consent are collected.

IT teams encounter this as the front-end of the WiFi authentication flow. The fields configured on the captive portal directly determine what data is available for CRM enrichment.

JSON Payload

The structured data packet transmitted from the Purple platform to the HubSpot API, containing the contact's demographic and session data in JavaScript Object Notation format.

Understanding the payload structure is essential for troubleshooting failed data syncs. The HubSpot API will silently reject properties that do not exist or have mismatched data types.

Deduplication

The process by which the CRM identifies and merges or prevents the creation of redundant duplicate contact records. HubSpot performs deduplication automatically using the email address as the primary key.

Critical for maintaining a clean database. Deduplication failures — typically caused by inconsistent or invalid email addresses — result in inflated contact counts and fragmented visit history.

Lifecycle Stage

A native HubSpot contact property that indicates where a contact sits within the marketing and sales funnel. Standard stages include Subscriber, Lead, Marketing Qualified Lead (MQL), Sales Qualified Lead (SQL), and Customer.

WiFi session events should drive automated lifecycle stage progressions. Manually managing these stages at scale is not operationally viable.

Active List

A dynamic contact list in HubSpot that automatically updates in real time based on defined property criteria. Contacts are added or removed as their properties change.

The primary segmentation mechanism for WiFi-sourced contacts. Active Lists ensure that campaign audiences always reflect the most current visit data without manual intervention.

Custom Property

A user-defined field created in HubSpot to store data that is not covered by the platform's native properties. Custom properties must be created before the integration is activated.

Required for all WiFi-specific behavioural data. The four critical custom properties for this integration are wifi_venue, wifi_session_count, wifi_last_visit, and wifi_dwell_time.

hs_legal_basis

A native HubSpot contact property that records the legal basis under which the contact's data is being processed for marketing purposes, in compliance with GDPR.

Must be mapped to the marketing consent checkbox on the captive portal. Without a valid value in this property, HubSpot will block outbound email sends to the contact.

API Rate Limiting

A restriction imposed by the HubSpot API on the number of requests that can be processed within a defined time window. Exceeding the rate limit results in HTTP 429 errors and queued or failed payload transmissions.

A deployment risk in high-density environments such as stadiums or conference centres during peak authentication periods. Purple queues and retries failed payloads, but sustained rate limit breaches can cause significant data sync delays.

Dwell Time

The duration in minutes that a user's device remains connected to the WiFi network during a single session. A proxy metric for engagement depth and purchase intent in retail and hospitality environments.

Stored in the wifi_dwell_time custom property and used as a trigger for SQL lifecycle stage progression. High dwell time correlates with higher conversion probability in venue-based marketing.

Études de cas

A 300-room hotel wants to segment its HubSpot marketing lists to distinguish between first-time guests, repeat leisure visitors, and frequent corporate travellers, and trigger different email sequences for each segment.

Ensure wifi_session_count and wifi_venue are mapped and populating correctly for all new connections. 2. Create three HubSpot Active Lists: 'First-Time Guests' where wifi_session_count = 1; 'Repeat Leisure Visitors' where wifi_session_count >= 2 AND wifi_last_visit is within the last 90 days AND the contact's jobtitle property is blank (indicating a non-corporate profile); 'Corporate Travellers' where wifi_session_count >= 3 AND jobtitle is known or company is populated. 3. Build three separate HubSpot email sequences enrolled from each list. The 'First-Time Guest' sequence focuses on amenity awareness and a return-visit incentive. The 'Repeat Leisure Visitor' sequence promotes the loyalty programme. The 'Corporate Traveller' sequence highlights meeting room facilities and corporate rate enquiries. 4. Set the lifecycle stage to MQL when wifi_session_count reaches 3, triggering the corporate sequence enrolment automatically.

Notes de mise en œuvre : This approach leverages deterministic network data — session count and visit recency — rather than relying on staff to manually categorise guests. The segmentation is self-maintaining because HubSpot Active Lists update in real time as the WiFi properties change. The corporate traveller identification using `jobtitle` and `company` enrichment is a secondary layer that can be enhanced with a data enrichment tool like Clearbit, but the WiFi data alone provides sufficient signal for the initial segmentation.

A retail chain with 50 locations needs to ensure that marketing emails are only sent to customers who explicitly opted in at the specific store they visited, and that each regional marketing manager can access only the contacts from their territory.

Map the Purple 'Venue Name' field to the custom wifi_venue property in HubSpot. Ensure the venue names are standardised (e.g., 'Manchester Arndale', 'Birmingham Bullring') — inconsistent naming will fragment the segmentation. 2. Map the marketing consent checkbox to hs_legal_basis = 'Freely given consent from the contact'. 3. Create HubSpot Active Lists for each store, filtered by wifi_venue = [Store Name] AND hs_legal_basis = 'Freely given consent from the contact'. 4. In HubSpot, use Teams to restrict each regional marketing manager's access to only the lists and contacts associated with their territory. Assign the relevant lists to each team. 5. Build a standard email template for each region, enrolled from the corresponding store list.

Notes de mise en œuvre : The critical dependency here is the standardisation of venue names. If the Purple configuration passes 'Manchester - Arndale' for some connections and 'Manchester Arndale' for others, the Active List filter will miss records. Establish a naming convention before deployment and enforce it in the Purple portal configuration. The HubSpot Teams feature is the correct mechanism for territory-based access control — it avoids the need to create separate HubSpot portals for each region, which would fragment the data and increase licence costs.

Analyse de scénario

Q1. A stadium expects 50,000 attendees for a match day event. The venue operator wants to capture emails via the WiFi portal and trigger a personalised welcome email through HubSpot within five minutes of each guest connecting. What is the primary technical risk and how should it be mitigated?

💡 Astuce :Consider the volume of concurrent connections at kick-off and how the API handles burst traffic.

Afficher l'approche recommandée

The primary risk is hitting the HubSpot API rate limit due to the concentrated spike in concurrent authentications at kick-off. Even with Purple's payload queuing and retry mechanism, a burst of 10,000–15,000 simultaneous connections within a short window can cause significant processing delays, meaning the 'welcome within 5 minutes' SLA is unachievable for the first wave of connections. Mitigation strategies include: (1) upgrading to a HubSpot Enterprise tier with higher API rate limits; (2) accepting that the welcome email SLA is realistic for staggered arrivals but not for the kick-off burst, and adjusting the SLA to 'within 30 minutes'; (3) configuring the HubSpot workflow to send the welcome email as a batch at a fixed time (e.g., 15 minutes after gates open) rather than individually triggered, reducing the workflow execution load.

Q2. The marketing team reports that 8,000 contacts generated from the WiFi network over the past three months cannot receive marketing emails. The contacts exist in HubSpot with valid email addresses and are not marked as unsubscribed. What is the most likely root cause and what is the remediation path?

💡 Astuce :Focus on the GDPR compliance layer within HubSpot, not the email addresses themselves.

Afficher l'approche recommandée

The most likely root cause is that the hs_legal_basis property was not mapped during the integration configuration, or was mapped with an incorrect string value. HubSpot requires the exact string 'Freely given consent from the contact' for GDPR-compliant outbound email. Any variation — including a blank value — causes HubSpot to suppress the contact from email sends. The remediation path is: (1) verify the current hs_legal_basis value on a sample of affected contacts; (2) if blank or incorrect, identify whether the portal consent checkbox was being captured by Purple during the period; (3) if consent was captured but not mapped, update the integration mapping and use a HubSpot bulk update workflow to retroactively set hs_legal_basis for contacts where the consent timestamp is populated; (4) if consent was not captured at the portal, those contacts cannot be emailed and should be suppressed permanently — do not attempt to retroactively assign consent that was not given.

Q3. A venue operator wants to identify 'high-value' visitors — defined as guests who have visited at least four times in the last 60 days and whose average dwell time exceeds 90 minutes — and automatically enrol them in a VIP loyalty programme outreach sequence in HubSpot. How should this be architected?

💡 Astuce :Consider which properties need to exist, how the threshold logic is built in HubSpot, and what triggers the sequence enrolment.

Afficher l'approche recommandée

Confirm that wifi_session_count, wifi_dwell_time, and wifi_last_visit custom properties are correctly mapped and populating. 2. Create a HubSpot Active List with the criteria: wifi_session_count >= 4 AND wifi_dwell_time >= 90 AND wifi_last_visit is within the last 60 days. This list will automatically update as contacts meet or fall out of the criteria. 3. Build a HubSpot workflow triggered by 'Contact added to list' for the above Active List. Set the action to enrol the contact in the VIP loyalty outreach email sequence. 4. Add a suppression condition to the workflow: if the contact's lifecycle stage is already 'Customer' (i.e., already enrolled in the loyalty programme), do not re-enrol. 5. Optionally, trigger an internal CRM notification to the venue's guest relations team when a contact enters the VIP list, enabling a personalised in-venue interaction on the next visit.

Points clés à retenir

✓Purple Guest WiFi acts as a real-time data acquisition layer for HubSpot, converting anonymous network connections into enriched CRM contacts with verified identity and behavioural data.
✓Four custom HubSpot properties must be created before activation: wifi_venue, wifi_session_count, wifi_last_visit, and wifi_dwell_time — these are the foundation of all WiFi-based segmentation.
✓HubSpot uses the email address as the primary deduplication key; enforce strict email format validation on the captive portal to prevent dirty data from entering the CRM.
✓Never default all WiFi connections to 'Lead' — use an event-driven lifecycle model: Subscriber on first login, MQL at 2+ visits in 30 days, SQL at high dwell time.
✓The hs_legal_basis property mapping is non-negotiable; without it, HubSpot will block all outbound email sends to WiFi-sourced contacts regardless of email validity.
✓For multi-venue deployments, standardise venue name values before go-live — inconsistent naming silently fragments Active Lists and breaks geo-targeted campaign segmentation.
✓Monitor HubSpot API rate limits during high-density events; Purple queues and retries payloads, but sustained burst traffic can delay data sync and impact time-sensitive workflow triggers.