HubSpot y Guest WiFi: Enriquecimiento y Segmentación de Leads

Esta guía proporciona a los gerentes de TI, administradores de HubSpot y equipos de operaciones de marketing un manual práctico de integración para conectar Purple Guest WiFi a HubSpot. Cubre la arquitectura técnica completa — desde la captura de datos del Captive Portal y el mapeo de propiedades hasta la automatización de la etapa del ciclo de vida, la deduplicación y la segmentación de listas — permitiendo a los operadores de locales convertir conexiones WiFi anónimas en contactos de CRM enriquecidos y accionables.

📖 9 min de lectura📝 2,047 palabras🔧 2 ejemplos❓ 3 preguntas📚 9 términos clave

🎧 Escuchar esta guía

Ver transcripción

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.

Resumen Ejecutivo

Para los locales empresariales — desde grandes cadenas minoristas hasta estadios de alta capacidad — la red Guest WiFi es una de las capas de adquisición de datos más infrautilizadas en la pila tecnológica. Cada sesión autenticada representa una señal de identidad verificada: un nombre, una dirección de correo electrónico y un consentimiento de marketing explícito. Sin embargo, la mayoría de las organizaciones permiten que estos datos permanezcan aislados dentro de su plataforma de gestión de WiFi, completamente desconectados del CRM. La integración de Purple HubSpot cierra esa brecha al establecer una tubería de datos en tiempo real y basada en eventos entre el Captive Portal y HubSpot.

Esta guía cubre la arquitectura de implementación completa: cómo mapear los campos del portal Guest WiFi a las propiedades estándar y personalizadas de HubSpot, cómo configurar la lógica de deduplicación, cómo construir flujos de trabajo de etapa del ciclo de vida activados por eventos de sesión WiFi, y cómo segmentar contactos en listas accionables. Está escrita para administradores de HubSpot, gerentes de operaciones de marketing y arquitectos de TI que necesitan implementar esta integración en un entorno de producción, no evaluarla en teoría.

Análisis Técnico Detallado

Arquitectura y Flujo de Datos

La integración opera sobre una arquitectura basada en webhooks. Cuando un usuario se autentica a través del Captive Portal de Purple, la plataforma actúa como proveedor de identidad, validando la sesión y generando una carga útil JSON estructurada que contiene los datos demográficos y de sesión del usuario. Esta carga útil se transmite a través de una llamada segura a la API REST HTTPS al endpoint de la API de Contactos de HubSpot.

El flujo de datos sigue cuatro etapas discretas: autenticación en la capa del portal, generación de la carga útil por la plataforma Purple, transmisión de la API a HubSpot y creación o actualización de registros dentro del CRM. Para implementaciones en múltiples locales — comunes en entornos de Retail y Hospitality — el identificador del local se incrusta en la carga útil en el momento de la generación, asegurando que cada registro de contacto lleve el contexto de ubicación requerido para la segmentación regional.

La capa de WiFi Analytics dentro de Purple genera las métricas de comportamiento — recuento de sesiones, tiempo de permanencia, frecuencia de visitas — que se transmiten junto con los datos demográficos. Estas métricas son el factor diferenciador entre una captura básica de correo electrónico y un contacto de CRM genuinamente enriquecido.

Mecánica del Mapeo de Propiedades

Un mapeo de propiedades preciso es la base de una integración fiable. Las propiedades de contacto nativas de HubSpot manejan campos demográficos estándar, pero los datos de comportamiento específicos de WiFi requieren la creación de propiedades personalizadas antes de que se active la integración.

La siguiente tabla define la configuración de mapeo de propiedades recomendada:

Campo del Portal	Propiedad de HubSpot	Tipo de Propiedad	Notas
Nombre	`firstname`	Texto de una sola línea	Propiedad nativa de HubSpot
Apellido	`lastname`	Texto de una sola línea	Propiedad nativa de HubSpot
Dirección de correo electrónico	`email`	Correo electrónico	Clave de deduplicación principal
Número de teléfono	`phone`	Número de teléfono	Propiedad nativa de HubSpot
Fecha de nacimiento	`date_of_birth`	Selector de fecha	Propiedad personalizada requerida
Código postal	`zip`	Texto de una sola línea	Propiedad nativa de HubSpot
Consentimiento de marketing	`hs_legal_basis`	Texto de una sola línea	Establecido como 'Consentimiento libremente otorgado'
Marca de tiempo de visita	`wifi_last_visit`	Selector de fecha	Propiedad personalizada requerida
Nombre del local	`wifi_venue`	Texto de una sola línea	Propiedad personalizada requerida
Recuento de sesiones	`wifi_session_count`	Número	Propiedad personalizada requerida
Tiempo de permanencia (min)	`wifi_dwell_time`	Número	Propiedad personalizada requerida

Las cuatro propiedades personalizadas — wifi_last_visit, wifi_venue, wifi_session_count y wifi_dwell_time — deben crearse en HubSpot antes de que se active la integración. Si no se pre-crean estas propiedades, los datos de la carga útil serán descartados silenciosamente por la API de HubSpot.

Deduplicación y Resolución de Identidad

HubSpot utiliza la dirección de correo electrónico como identificador único principal para los registros de contacto. Cuando se recibe la carga útil de Purple, HubSpot realiza una búsqueda en los registros existentes. Si existe un contacto con la dirección de correo electrónico coincidente, HubSpot actualiza el registro con los nuevos datos de sesión — incrementando wifi_session_count y actualizando wifi_last_visit. Si no se encuentra ninguna coincidencia, se crea un nuevo registro de contacto.

Este comportamiento es determinista y fiable, siempre que la dirección de correo electrónico sea consistente en todas las visitas. El riesgo principal son los datos sucios en el origen. Si el Captive Portal permite direcciones de correo electrónico mal formadas o falsas, se crean registros huérfanos en HubSpot que no pueden ser emparejados en visitas posteriores y no se les puede enviar correos electrónicos. La mitigación es aplicar una validación estricta del formato de correo electrónico RFC 5322 en el formulario del portal, haciendo que el campo de correo electrónico sea obligatorio con validación del lado del servidor. Esta es una opción configurable dentro de la configuración del portal de Purple y debe tratarse como un requisito básico no negociable.

Para organizaciones que operan en entornos de Healthcare o del sector público donde el cumplimiento del GDPR está sujeto a auditoría, también cabe señalar que el mecanismo de deduplicación significa que un único registro de contacto consolida todo el historial de visitas. Esto simplifica las respuestas a las Solicitudes de Acceso del Interesado (SAR) y las solicitudes de eliminación de datos bajo el Artículo 17 del GDPR.

Guía de Implementación

Paso 1: Preconfigurar Propiedades Personalizadas de HubSpot

Navegar a Configuración de HubSpot > Propiedades > Propiedades de contacto. Cree las cuatro propiedades personalizadas que se enumeran en la tabla de mapeo anterior. Asegúrese de que los tipos de datos estén configurados correctamente: wifi_last_visit debe ser un selector de fecha, y wifi_session_count y wifi_dwell_time deben ser tipos numéricos. Los tipos de datos incorrectos harán que la API rechace los valores de la carga útil.

Paso 2: Auditar y alinear los campos del Captive Portal

Revise la configuración actual del Captive Portal de Purple. Asegúrese de que el campo Correo electrónico esté configurado como obligatorio con la validación de formato habilitada. Para implementaciones en múltiples ubicaciones, confirme que el identificador de ubicación esté configurado para pasarse dinámicamente según la ubicación del punto de acceso. Las ubicaciones en entornos de Transporte —como aeropuertos o estaciones de tren— pueden tener múltiples zonas dentro de una misma ubicación, cada una de las cuales requiere un identificador de ubicación distinto.

Paso 3: Configurar el mapeo de propiedades en Purple

Dentro de la configuración de integración de HubSpot de la plataforma Purple, mapee cada campo del portal al nombre de propiedad interna de HubSpot correspondiente. Utilice los nombres de propiedad internos exactos (por ejemplo, wifi_session_count, no WiFi Session Count) para asegurar que la carga útil de la API esté correctamente estructurada.

Paso 4: Establecer la automatización de la etapa del ciclo de vida

No establezca por defecto todas las nuevas conexiones WiFi a la etapa del ciclo de vida 'Lead'. Implemente un modelo escalonado basado en eventos utilizando los flujos de trabajo de HubSpot.

La progresión recomendada del ciclo de vida es la siguiente. Tras el primer inicio de sesión WiFi, establezca la etapa del ciclo de vida en Suscriptor — la etapa correcta de HubSpot para un contacto que ha proporcionado sus datos pero aún no ha demostrado intención de comportamiento. Cuando wifi_session_count alcance 2 o más dentro de un período de 30 días, active un flujo de trabajo para hacer la transición del contacto a Lead Cualificado de Marketing (MQL). Cuando wifi_dwell_time exceda los 45 minutos en múltiples sesiones, haga la transición a Lead Cualificado de Ventas (SQL). Cuando se aplique una etiqueta de programa de fidelización, haga la transición a Cliente.

En HubSpot, cree cada transición como un flujo de trabajo separado con el disparador configurado en 'Cambios en el valor de la propiedad del contacto'. Esto asegura que la transición se active inmediatamente cuando se cruza el umbral, en lugar de esperar un proceso por lotes programado.

Paso 5: Mapear la base legal para el procesamiento

Este paso es innegociable para el cumplimiento del GDPR. La casilla de verificación de consentimiento de marketing en el Captive Portal debe mapearse a la propiedad hs_legal_basis de HubSpot. Cuando un usuario opta por participar, el valor debe establecerse en Freely given consent from the contact. Sin este mapeo, los controles de cumplimiento integrados de HubSpot bloquearán los envíos de correos electrónicos salientes a estos contactos, haciendo que la integración sea comercialmente inútil para la automatización de marketing.

Paso 6: Crear listas de segmentación

Con los datos de propiedad fluyendo correctamente, cree Listas Activas de HubSpot para los casos de uso de segmentación principales. Los ejemplos incluyen: todos los contactos donde wifi_venue = una ubicación específica (para campañas geo-dirigidas), todos los contactos donde wifi_session_count >= 5 (para programas de fidelización), y todos los contactos donde wifi_last_visit está dentro de los últimos 30 días (para re-engagement basado en la actualidad).

Mejores prácticas

Aplicar la validación de correo electrónico en origen. Cada problema de calidad de datos en HubSpot que se origina en la integración WiFi se puede rastrear hasta una dirección de correo electrónico mal validada. Trate el formulario del portal como la primera línea de defensa para la calidad de los datos del CRM.

Segmentar por ubicación desde el primer día. Para cualquier implementación que abarque múltiples ubicaciones —ya sea una cadena minorista, un consorcio hospitalario o un complejo de estadios— la propiedad wifi_venue es la dimensión de segmentación más importante. Configúrela correctamente desde el principio. Reajustar la segmentación por ubicación después de que se hayan creado miles de contactos sin la propiedad es un esfuerzo de remediación significativo.

Respetar la arquitectura de consentimiento. El principio GDPR de limitación de la finalidad significa que los datos recopilados a través de un portal WiFi con el propósito de acceso a la red no pueden ser reutilizados automáticamente para marketing directo sin consentimiento explícito. El mapeo hs_legal_basis no es una tecnicidad, es el mecanismo legal que autoriza el caso de uso de marketing.

Monitorizar el rendimiento de la API. Para entornos de alta densidad como estadios o centros de conferencias, el volumen de autenticación concurrente durante los períodos pico puede sobrecargar la API de HubSpot. Purple pone en cola las cargas útiles y reintenta las solicitudes fallidas, pero es aconsejable monitorizar los volúmenes de llamadas a la API en el panel de desarrolladores de HubSpot durante eventos importantes y asegurarse de que el nivel de cuenta de HubSpot admita el rendimiento requerido.

Utilizar actualizaciones incrementales, no sobrescrituras completas. Cuando un visitante recurrente se conecta, la carga útil debe actualizar solo las propiedades modificadas (wifi_last_visit, wifi_session_count) en lugar de sobrescribir todos los campos. Esto evita la pérdida accidental de datos si, por ejemplo, un contacto ha actualizado su nombre directamente en HubSpot.

Solución de problemas y mitigación de riesgos

Problema: Se están creando contactos pero no pueden recibir correos electrónicos de marketing. Causa raíz: La propiedad hs_legal_basis no se mapeó o se mapeó con una cadena de valor incorrecta. Resolución: Verifique el valor de cadena exacto que se está pasando. HubSpot requiere Freely given consent from the contact — cualquier variación hará que la verificación de cumplimiento falle silenciosamente.

Problema: Aparecen registros de contactos duplicados en HubSpot. Causa raíz: El mismo usuario está enviando múltiples direcciones de correo electrónico (por ejemplo, personal y corporativo), o el campo de correo electrónico no es obligatorio en el portal. Resolución: Habilite la validación obligatoria de correo electrónico en el portal. Considere implementar un flujo de trabajo de fusión en HubSpot para consolidar registros donde el mismo nombre aparece con diferentes direcciones de correo electrónico.

Problema: Las propiedades personalizadas no se están rellenando a pesar de que la integración está activa. Causa raíz: Las propiedades personalizadas no se crearon en HubDetectado antes de que la integración se activara, o los nombres de propiedad internos en la configuración de mapeo de Purple no coinciden exactamente con los nombres internos de las propiedades de HubSpot. Resolución: Compare los nombres de propiedad internos en HubSpot Settings > Properties con la configuración de mapeo en Purple. Los nombres internos distinguen entre mayúsculas y minúsculas y usan guiones bajos, no espacios.

Problema: La etapa del ciclo de vida no avanza a pesar de haberse alcanzado el umbral de recuento de sesiones. Causa Raíz: El disparador del flujo de trabajo de HubSpot está configurado como 'Contact is enrolled' en lugar de 'Contact property value changes'. Resolución: Reconstruya el flujo de trabajo con el tipo de disparador correcto. 'Contact property value changes' se activa cada vez que la propiedad se actualiza, lo cual es el mecanismo correcto para la progresión basada en umbrales.

Riesgo: Incumplimiento del GDPR debido a la retención de datos. Mitigación: Implemente un flujo de trabajo de HubSpot que marque los contactos como inactivos después de 24 meses sin actividad WiFi (es decir, wifi_last_visit es de hace más de 24 meses). Active un correo electrónico de re-consentimiento. Si no se recibe respuesta en 30 días, suprima el contacto de todas las comunicaciones de marketing. Esto se alinea con el principio de limitación del almacenamiento del GDPR.

ROI e Impacto Empresarial

El caso comercial para la integración de Purple HubSpot es sencillo: convierte un coste pasivo de infraestructura de red en un flujo de datos activo que genera ingresos. Los indicadores clave de rendimiento para medir el éxito de la implementación son:

KPI	Método de Medición	Objetivo de Referencia
Contactos nuevos generados	Informe de fuente de contactos de HubSpot	15–25% de las sesiones WiFi mensuales
Precisión de la sincronización de datos	% de contactos con las 4 propiedades personalizadas rellenadas	> 95%
Tasa de entregabilidad de correo electrónico	Panel de salud de correo electrónico de HubSpot	> 90%
Tasa de conversión de MQL de contactos WiFi	Informe de progresión de la etapa del ciclo de vida	> 8% en 90 días
Tasa de apertura de campaña (contactos de origen WiFi)	Análisis de correo electrónico de HubSpot	> 25% (frente al 18% de la media del sector)

En una implementación en hostelería, un hotel de 300 habitaciones que genera 2.000 conexiones WiFi únicas al mes puede esperar añadir aproximadamente 400-500 contactos nuevos enriquecidos a HubSpot mensualmente, asumiendo una tasa de conversión del 20-25% desde la conexión hasta la finalización del formulario. Con una tasa de conversión de MQL conservadora del 10%, esto representa 40-50 nuevos leads cualificados de marketing al mes de una fuente de datos que anteriormente generaba cero valor CRM.

Para una cadena minorista que opera en 50 ubicaciones, el volumen de datos agregado es sustancialmente mayor, y el valor de la segmentación —particularmente la capacidad de dirigir contactos por ubicación de tienda específica— permite campañas promocionales hiperlocalizadas que superan consistentemente a los correos electrónicos genéricos masivos tanto en tasa de apertura como en conversión.

Términos clave y definiciones

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.

Casos de éxito

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.

Notas de implementación: 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.

Notas de implementación: 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.

Análisis de escenarios

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?

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

Mostrar enfoque recomendado

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?

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

Mostrar enfoque recomendado

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?

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

Mostrar enfoque recomendado

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.

Conclusiones clave

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