HubSpot e Guest WiFi: Arricchimento e Segmentazione dei Lead

Questa guida fornisce a IT manager, amministratori HubSpot e team di marketing operations un playbook pratico per l'integrazione di Purple Guest WiFi con HubSpot. Copre l'intera architettura tecnica — dall'acquisizione dei dati del captive portal e la mappatura delle proprietà, all'automazione delle fasi del ciclo di vita, alla deduplicazione e alla segmentazione delle liste — consentendo agli operatori delle sedi di convertire le connessioni WiFi anonime in contatti CRM arricchiti e utilizzabili.

📖 9 min di lettura📝 2,047 parole🔧 2 esempi❓ 3 domande📚 9 termini chiave

🎧 Ascolta questa guida

Visualizza trascrizione

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.

Riepilogo Esecutivo

Per le sedi aziendali — dalle grandi catene di vendita al dettaglio agli stadi ad alta capacità — la rete guest WiFi è uno degli strati di acquisizione dati più sottoutilizzati nello stack tecnologico. Ogni sessione autenticata rappresenta un segnale di identità verificato: un nome, un indirizzo email e un consenso esplicito al marketing. Eppure la maggior parte delle organizzazioni permette che questi dati rimangano isolati all'interno della propria piattaforma di gestione WiFi, completamente disconnessi dal CRM. L'integrazione Purple HubSpot colma questa lacuna stabilendo una pipeline di dati in tempo reale, basata su eventi, tra il captive portal e HubSpot.

Questa guida copre l'architettura di implementazione completa: come mappare i campi del portale Guest WiFi alle proprietà standard e personalizzate di HubSpot, come configurare la logica di deduplicazione, come costruire workflow di fasi del ciclo di vita attivati da eventi di sessione WiFi e come segmentare i contatti in liste utilizzabili. È scritta per amministratori HubSpot, marketing operations manager e architetti IT che devono implementare questa integrazione in un ambiente di produzione, non valutarla in teoria.

Approfondimento Tecnico

Architettura e Flusso di Dati

L'integrazione opera su un'architettura basata su webhook. Quando un utente si autentica tramite il captive portal Purple, la piattaforma agisce come identity provider, convalidando la sessione e generando un payload JSON strutturato contenente i dati demografici e di sessione dell'utente. Questo payload viene trasmesso tramite una chiamata API REST HTTPS sicura all'endpoint dell'API Contatti di HubSpot.

Il flusso di dati segue quattro fasi distinte: autenticazione a livello di portale, generazione del payload da parte della piattaforma Purple, trasmissione API a HubSpot e creazione o aggiornamento del record all'interno del CRM. Per le implementazioni multi-sede — comuni negli ambienti Retail e Hospitality — l'identificatore della sede è incorporato nel payload al momento della generazione, garantendo che ogni record di contatto contenga il contesto di localizzazione richiesto per la segmentazione regionale.

Lo strato WiFi Analytics all'interno di Purple genera le metriche comportamentali — conteggio sessioni, tempo di permanenza, frequenza delle visite — che vengono passate insieme ai dati demografici. Queste metriche sono il fattore differenziante tra una semplice acquisizione di email e un contatto CRM realmente arricchito.

Meccanismi di Mappatura delle Proprietà

Una mappatura accurata delle proprietà è la base di un'integrazione affidabile. Le proprietà di contatto native di HubSpot gestiscono i campi demografici standard, ma i dati comportamentali specifici del WiFi richiedono la creazione di proprietà personalizzate prima che l'integrazione venga attivata.

La seguente tabella definisce la configurazione di mappatura delle proprietà consigliata:

Campo del Portale	Proprietà HubSpot	Tipo di Proprietà	Note
Nome	`firstname`	Single-line text	Proprietà nativa di HubSpot
Cognome	`lastname`	Single-line text	Proprietà nativa di HubSpot
Indirizzo Email	`email`	Email	Chiave di deduplicazione primaria
Numero di Telefono	`phone`	Phone number	Proprietà nativa di HubSpot
Data di Nascita	`date_of_birth`	Date picker	Proprietà personalizzata richiesta
Codice Postale / ZIP	`zip`	Single-line text	Proprietà nativa di HubSpot
Consenso Marketing	`hs_legal_basis`	Single-line text	Impostato su 'Consenso liberamente dato'
Timestamp Visita	`wifi_last_visit`	Date picker	Proprietà personalizzata richiesta
Nome Sede	`wifi_venue`	Single-line text	Proprietà personalizzata richiesta
Conteggio Sessioni	`wifi_session_count`	Number	Proprietà personalizzata richiesta
Tempo di Permanenza (min)	`wifi_dwell_time`	Number	Proprietà personalizzata richiesta

Le quattro proprietà personalizzate — wifi_last_visit, wifi_venue, wifi_session_count e wifi_dwell_time — devono essere create in HubSpot prima che l'integrazione venga attivata. La mancata pre-creazione di queste proprietà comporterà lo scarto silenzioso dei dati del payload da parte dell'API di HubSpot.

Deduplicazione e Risoluzione dell'Identità

HubSpot utilizza l'indirizzo email come identificatore univoco primario per i record di contatto. Quando il payload Purple viene ricevuto, HubSpot esegue una ricerca rispetto ai record esistenti. Se esiste un contatto con l'indirizzo email corrispondente, HubSpot aggiorna il record con i nuovi dati di sessione — incrementando wifi_session_count e aggiornando wifi_last_visit. Se non viene trovata alcuna corrispondenza, viene creato un nuovo record di contatto.

Questo comportamento è deterministico e affidabile, a condizione che l'indirizzo email sia coerente tra le visite. Il rischio principale è la presenza di dati sporchi alla fonte. Se il captive portal consente indirizzi email malformati o falsi, vengono creati record orfani in HubSpot che non possono essere abbinati nelle visite successive e non possono essere utilizzati per l'invio di email. La mitigazione consiste nell'applicare una rigorosa convalida del formato email RFC 5322 sul modulo del portale, rendendo il campo email obbligatorio con convalida lato server. Questa è un'opzione configurabile all'interno delle impostazioni del portale Purple e dovrebbe essere trattata come un requisito di base non negoziabile.

Per le organizzazioni che operano in ambienti Healthcare o del settore pubblico dove la conformità al GDPR è soggetta a audit, è anche opportuno notare che il meccanismo di deduplicazione significa che un singolo record di contatto consolida tutta la cronologia delle visite. Ciò semplifica le risposte alle Richieste di Accesso del Soggetto (SAR) e le richieste di cancellazione dei dati ai sensi dell'Articolo 17 del GDPR.

Guida all'Implementazione

Fase 1: Pre-configurare le Proprietà Personalizzate di HubSpot

Naviga alle Impostazioni di HubSpot > Proprietà > Proprietà dei Contatti. Crea le quattro proprietà personalizzate elencate nella tabella di mappatura sopra. Assicurati che i tipi di dati siano impostati correttamente — wifi_last_visit deve essere un selettore di data, wifi_session_count e wifi_dwell_time devono essere tipi numerici. Tipi di dati errati causeranno il rifiuto dei valori del payload da parte dell'API.

Fase 2: Verifica e Allineamento dei Campi del Captive Portal

Esamina la configurazione attuale del Captive Portal Purple. Assicurati che il campo Email sia impostato come obbligatorio con la convalida del formato abilitata. Per implementazioni multi-sede, conferma che l'identificatore della sede sia configurato per essere passato dinamicamente in base alla posizione del punto di accesso. Le sedi in ambienti Trasporto — come aeroporti o stazioni ferroviarie — possono avere più zone all'interno di una singola sede, ognuna delle quali richiede un identificatore di sede distinto.

Fase 3: Configura la Mappatura delle Proprietà in Purple

All'interno delle impostazioni di integrazione di HubSpot della piattaforma Purple, mappa ogni campo del portale al nome della proprietà interna di HubSpot corrispondente. Utilizza i nomi esatti delle proprietà interne (ad esempio, wifi_session_count, non WiFi Session Count) per garantire che il payload dell'API sia strutturato correttamente.

Fase 4: Stabilisci l'Automazione delle Fasi del Ciclo di Vita

Non impostare tutte le nuove connessioni WiFi alla fase del ciclo di vita 'Lead' per impostazione predefinita. Implementa un modello a livelli basato su eventi utilizzando i workflow di HubSpot.

La progressione del ciclo di vita raccomandata è la seguente. Al primo login WiFi, imposta la fase del ciclo di vita su Subscriber — la fase corretta di HubSpot per un contatto che ha fornito i propri dettagli ma non ha ancora dimostrato intenti comportamentali. Quando wifi_session_count raggiunge 2 o più entro un periodo di 30 giorni, attiva un workflow per far passare il contatto a Marketing Qualified Lead (MQL). Quando wifi_dwell_time supera i 45 minuti su più sessioni, passa a Sales Qualified Lead (SQL). Quando viene applicato un tag di programma fedeltà, passa a Customer.

In HubSpot, crea ogni transizione come un workflow separato con il trigger impostato su 'Contact property value changes'. Ciò garantisce che la transizione si attivi immediatamente quando la soglia viene superata, piuttosto che attendere un processo batch programmato.

Fase 5: Mappa la Base Giuridica per il Trattamento

Questo passaggio è non negoziabile per la conformità al GDPR. La casella di controllo del consenso marketing sul Captive Portal deve essere mappata alla proprietà hs_legal_basis di HubSpot. Quando un utente acconsente, il valore deve essere impostato su Freely given consent from the contact. Senza questa mappatura, i controlli di conformità integrati di HubSpot bloccheranno l'invio di email in uscita a questi contatti, rendendo l'integrazione commercialmente inutile per l'automazione del marketing.

Fase 6: Crea Elenchi di Segmentazione

Con i dati delle proprietà che fluiscono correttamente, crea elenchi attivi di HubSpot per i principali casi d'uso di segmentazione. Gli esempi includono: tutti i contatti in cui wifi_venue = una posizione specifica (per campagne geo-mirate), tutti i contatti in cui wifi_session_count >= 5 (per attività di sensibilizzazione del programma fedeltà) e tutti i contatti in cui wifi_last_visit rientra negli ultimi 30 giorni (per il re-engagement basato sulla recenza).

Best Practice

Applica la Convalida dell'Email alla Fonte. Ogni problema di qualità dei dati in HubSpot che ha origine dall'integrazione WiFi può essere ricondotto a un indirizzo email scarsamente convalidato. Tratta il modulo del portale come la prima linea di difesa per la qualità dei dati del CRM.

Segmenta per Sede dal Primo Giorno. Per qualsiasi implementazione che copra più sedi — che si tratti di una proprietà commerciale, di un'azienda ospedaliera o di un complesso sportivo — la proprietà wifi_venue è la dimensione di segmentazione più importante. Configurala correttamente fin dall'inizio. Il ripristino della segmentazione per sede dopo che migliaia di contatti sono stati creati senza la proprietà è un notevole sforzo di rimedio.

Rispetta l'Architettura del Consenso. Il principio GDPR di limitazione della finalità significa che i dati raccolti tramite un portale WiFi allo scopo di accesso alla rete non possono essere automaticamente riutilizzati per il marketing diretto senza esplicito consenso. La mappatura hs_legal_basis non è una tecnicalità — è il meccanismo legale che autorizza il caso d'uso del marketing.

Monitora il Throughput dell'API. Per ambienti ad alta densità come stadi o centri congressi, il volume di autenticazioni concorrenti durante i periodi di punta può mettere sotto stress l'API di HubSpot. Purple mette in coda i payload e ritenta le richieste fallite, ma è consigliabile monitorare i volumi di chiamate API nella dashboard sviluppatori di HubSpot durante gli eventi principali e assicurarsi che il livello dell'account HubSpot supporti il throughput richiesto.

Usa Aggiornamenti Incrementali, Non Sovrascritture Complete. Quando un visitatore di ritorno si connette, il payload dovrebbe aggiornare solo le proprietà modificate (wifi_last_visit, wifi_session_count) piuttosto che sovrascrivere tutti i campi. Ciò previene la perdita accidentale di dati se, ad esempio, un contatto ha aggiornato il proprio nome direttamente in HubSpot.

Risoluzione dei Problemi e Mitigazione del Rischio

Problema: I contatti vengono creati ma non possono ricevere email di marketing. Causa Radice: La proprietà hs_legal_basis non è stata mappata o è stata mappata con una stringa di valore errata. Risoluzione: Verifica il valore esatto della stringa che viene passata. HubSpot richiede Freely given consent from the contact — qualsiasi variazione farà fallire silenziosamente il controllo di conformità.

Problema: Appaiono record di contatti duplicati in HubSpot. Causa Radice: Vengono inviati più indirizzi email dallo stesso utente (ad esempio, personale e aziendale), oppure il campo email non è obbligatorio sul portale. Risoluzione: Abilita la convalida obbligatoria dell'email sul portale. Considera l'implementazione di un workflow di unione in HubSpot per consolidare i record in cui lo stesso nome appare con indirizzi email diversi.

Problema: Le proprietà personalizzate non vengono popolate nonostante l'integrazione sia attiva. Causa Radice: Le proprietà personalizzate non sono state create in HubPunto prima che l'integrazione fosse attivata, o i nomi delle proprietà interne nella configurazione di mappatura Purple non corrispondono esattamente ai nomi interni delle proprietà di HubSpot. Risoluzione: Confrontare i nomi delle proprietà interne in Impostazioni HubSpot > Proprietà con la configurazione di mappatura in Purple. I nomi interni sono sensibili alle maiuscole e minuscole e utilizzano trattini bassi, non spazi.

Problema: La fase del ciclo di vita non progredisce nonostante la soglia di conteggio delle sessioni sia stata raggiunta. Causa principale: Il trigger del workflow di HubSpot è impostato su 'Il contatto è iscritto' anziché 'Il valore della proprietà del contatto cambia'. Risoluzione: Ricostruire il workflow con il tipo di trigger corretto. 'Il valore della proprietà del contatto cambia' si attiva ogni volta che la proprietà viene aggiornata, il che è il meccanismo corretto per la progressione basata su soglia.

Rischio: Non conformità GDPR a causa della conservazione dei dati. Mitigazione: Implementare un workflow di HubSpot che contrassegna i contatti come inattivi dopo 24 mesi di nessuna attività WiFi (ovvero, wifi_last_visit risale a più di 24 mesi fa). Attivare un'e-mail di ri-consenso. Se non viene ricevuta alcuna risposta entro 30 giorni, sopprimere il contatto da tutte le comunicazioni di marketing. Ciò si allinea al principio GDPR di limitazione della conservazione.

ROI e Impatto Commerciale

Il caso commerciale per l'integrazione Purple HubSpot è semplice: converte un costo passivo dell'infrastruttura di rete in una pipeline di dati attiva che genera entrate. Gli indicatori chiave di performance per misurare il successo dell'implementazione sono:

KPI	Metodo di Misurazione	Obiettivo di Riferimento
Nuovi contatti generati	Report sulla fonte dei contatti di HubSpot	15–25% delle sessioni WiFi mensili
Accuratezza sincronizzazione dati	% di contatti con tutte e 4 le proprietà personalizzate popolate	> 95%
Tasso di consegna e-mail	Dashboard di salute delle e-mail di HubSpot	> 90%
Tasso di conversione MQL da contatti WiFi	Report di progressione della fase del ciclo di vita	> 8% entro 90 giorni
Tasso di apertura campagna (contatti provenienti da WiFi)	Analisi e-mail di HubSpot	> 25% (vs. 18% media del settore)

In un'implementazione nel settore dell'ospitalità, un hotel di 300 camere che genera 2.000 connessioni WiFi uniche al mese può aspettarsi di aggiungere circa 400–500 nuovi contatti arricchiti a HubSpot mensilmente, assumendo un tasso di conversione del 20–25% dalla connessione al completamento del modulo. Con un tasso di conversione MQL conservativo del 10%, ciò rappresenta 40–50 nuovi lead qualificati per il marketing al mese da una fonte di dati che in precedenza generava zero valore CRM.

Per una catena di vendita al dettaglio che opera in 50 sedi, il volume di dati aggregati è sostanzialmente più elevato, e il valore della segmentazione — in particolare la capacità di indirizzare i contatti per specifica sede del negozio — consente campagne promozionali iper-localizzate che superano costantemente le e-mail di massa generiche sia in termini di tasso di apertura che di conversione.

Termini chiave e definizioni

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.

Casi di studio

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.

Note di implementazione: 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.

Note di implementazione: 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.

Analisi degli scenari

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?

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

Mostra l'approccio consigliato

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?

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

Mostra l'approccio consigliato

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?

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

Mostra l'approccio consigliato

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.

Punti chiave

✓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.