HubSpot e Guest WiFi: Enriquecimento e Segmentação de Leads

Este guia fornece a gestores de TI, administradores de HubSpot e equipas de operações de marketing um manual prático de integração para conectar o Purple Guest WiFi ao HubSpot. Abrange a arquitetura técnica completa — desde a captura de dados do captive portal e mapeamento de propriedades até à automação de fases do ciclo de vida, deduplicação e segmentação de listas — permitindo que os operadores de espaços convertam conexões WiFi anónimas em contactos de CRM enriquecidos e acionáveis.

📖 9 min de leitura📝 2,047 palavras🔧 2 exemplos❓ 3 perguntas📚 9 termos-chave

🎧 Ouça este Guia

Ver Transcrição

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.

Resumo Executivo

Para espaços empresariais — desde grandes cadeias de retalho a estádios de alta capacidade — a rede Guest WiFi é uma das camadas de aquisição de dados mais subutilizadas na pilha tecnológica. Cada sessão autenticada representa um sinal de identidade verificado: um nome, um endereço de e-mail e consentimento explícito de marketing. No entanto, a maioria das organizações permite que estes dados permaneçam isolados na sua plataforma de gestão de WiFi, totalmente desconectados do CRM. A integração Purple HubSpot fecha essa lacuna ao estabelecer um pipeline de dados em tempo real, impulsionado por eventos, entre o captive portal e o HubSpot.

Este guia abrange a arquitetura de implementação completa: como mapear campos do portal Guest WiFi para propriedades padrão e personalizadas do HubSpot, como configurar a lógica de deduplicação, como construir fluxos de trabalho de fases do ciclo de vida acionados por eventos de sessão WiFi e como segmentar contactos em listas acionáveis. É escrito para administradores de HubSpot, gestores de operações de marketing e arquitetos de TI que precisam de implementar esta integração num ambiente de produção, e não avaliá-la em teoria.

Análise Técnica Detalhada

Arquitetura e Fluxo de Dados

A integração opera numa arquitetura impulsionada por webhooks. Quando um utilizador se autentica através do captive portal Purple, a plataforma atua como o provedor de identidade, validando a sessão e gerando um payload JSON estruturado contendo os dados demográficos e de sessão do utilizador. Este payload é transmitido através de uma chamada segura HTTPS REST API para o endpoint da API de Contactos do HubSpot.

O fluxo de dados segue quatro fases distintas: autenticação na camada do portal, geração do payload pela plataforma Purple, transmissão da API para o HubSpot e criação ou atualização de registos dentro do CRM. Para implementações em múltiplos espaços — comuns em ambientes de Retalho e Hotelaria — o identificador do espaço é incorporado no payload no momento da geração, garantindo que cada registo de contacto contém o contexto de localização necessário para a segmentação regional.

A camada de WiFi Analytics dentro do Purple gera as métricas comportamentais — contagem de sessões, tempo de permanência, frequência de visitas — que são passadas juntamente com os dados demográficos. Estas métricas são o fator diferenciador entre uma simples captura de e-mail e um contacto de CRM genuinamente enriquecido.

Mecânica de Mapeamento de Propriedades

O mapeamento preciso de propriedades é a base de uma integração fiável. As propriedades de contacto nativas do HubSpot lidam com campos demográficos padrão, mas os dados comportamentais específicos do WiFi exigem a criação de propriedades personalizadas antes da ativação da integração.

A tabela seguinte define a configuração de mapeamento de propriedades recomendada:

Campo do Portal	Propriedade do HubSpot	Tipo de Propriedade	Notas
Nome Próprio	`firstname`	Texto de linha única	Propriedade nativa do HubSpot
Apelido	`lastname`	Texto de linha única	Propriedade nativa do HubSpot
Endereço de E-mail	`email`	E-mail	Chave de deduplicação primária
Número de Telefone	`phone`	Número de telefone	Propriedade nativa do HubSpot
Data de Nascimento	`date_of_birth`	Seletor de data	Propriedade personalizada necessária
Código Postal	`zip`	Texto de linha única	Propriedade nativa do HubSpot
Consentimento de Marketing	`hs_legal_basis`	Texto de linha única	Definir como 'Consentimento livremente dado'
Carimbo de Data/Hora da Visita	`wifi_last_visit`	Seletor de data	Propriedade personalizada necessária
Nome do Espaço	`wifi_venue`	Texto de linha única	Propriedade personalizada necessária
Contagem de Sessões	`wifi_session_count`	Número	Propriedade personalizada necessária
Tempo de Permanência (mins)	`wifi_dwell_time`	Número	Propriedade personalizada necessária

As quatro propriedades personalizadas — wifi_last_visit, wifi_venue, wifi_session_count e wifi_dwell_time — devem ser criadas no HubSpot antes da ativação da integração. A falha na pré-criação destas propriedades resultará no descarte silencioso dos dados do payload pela API do HubSpot.

Deduplicação e Resolução de Identidade

O HubSpot utiliza o endereço de e-mail como o identificador único primário para os registos de contacto. Quando o payload Purple é recebido, o HubSpot realiza uma pesquisa em relação aos registos existentes. Se existir um contacto com o endereço de e-mail correspondente, o HubSpot atualiza o registo com os novos dados da sessão — incrementando wifi_session_count e atualizando wifi_last_visit. Se não for encontrada nenhuma correspondência, um novo registo de contacto é criado.

Este comportamento é determinístico e fiável, desde que o endereço de e-mail seja consistente entre as visitas. O risco principal são dados sujos na origem. Se o captive portal permitir endereços de e-mail malformados ou falsos, serão criados registos órfãos no HubSpot que não podem ser correspondidos em visitas subsequentes e não podem ser contactados por e-mail. A mitigação é impor uma validação rigorosa do formato de e-mail RFC 5322 no formulário do portal, tornando o campo de e-mail obrigatório com validação do lado do servidor. Esta é uma opção configurável nas definições do portal Purple e deve ser tratada como um requisito básico não negociável.

Para organizações que operam em ambientes de Saúde ou do setor público onde a conformidade com o GDPR está sujeita a auditoria, também é importante notar que o mecanismo de deduplicação significa que um único registo de contacto consolida todo o histórico de visitas. Isto simplifica as respostas a Pedidos de Acesso do Titular dos Dados (SAR) e os pedidos de eliminação de dados ao abrigo do Artigo 17 do GDPR.

Guia de Implementação

Passo 1: Pré-Configurar Propriedades Personalizadas do HubSpot

Navegar para Definições do HubSpot > Propriedades > Propriedades de Contacto. Crie as quatro propriedades personalizadas listadas na tabela de mapeamento acima. Certifique-se de que os tipos de dados estão corretamente definidos — wifi_last_visit deve ser um seletor de data, wifi_session_count e wifi_dwell_time devem ser tipos de Número. Tipos de dados incorretos farão com que a API rejeite os valores do payload.

Passo 2: Auditar e Alinhar Campos do Captive Portal

Reveja a configuração atual do Captive Portal Purple. Certifique-se de que o campo Email está definido como obrigatório com validação de formato ativada. Para implementações em vários locais, confirme que o identificador do local está configurado para ser passado dinamicamente com base na localização do ponto de acesso. Locais em ambientes de Transporte — como aeroportos ou estações ferroviárias — podem ter várias zonas dentro de um único local, cada uma exigindo um identificador de local distinto.

Passo 3: Configurar o Mapeamento de Propriedades no Purple

Nas definições de integração do HubSpot da plataforma Purple, mapeie cada campo do portal para o nome da propriedade interna correspondente do HubSpot. Utilize os nomes exatos das propriedades internas (por exemplo, wifi_session_count, não WiFi Session Count) para garantir que o payload da API esteja corretamente estruturado.

Passo 4: Estabelecer Automação de Fases do Ciclo de Vida

Não defina todas as novas ligações WiFi para a fase do ciclo de vida 'Lead' por predefinição. Implemente um modelo hierárquico baseado em eventos utilizando os workflows do HubSpot.

A progressão recomendada do ciclo de vida é a seguinte. Após o primeiro login WiFi, defina a fase do ciclo de vida para Subscritor — a fase correta do HubSpot para um contacto que forneceu os seus dados, mas ainda não demonstrou intenção comportamental. Quando wifi_session_count atingir 2 ou mais dentro de uma janela contínua de 30 dias, acione um workflow para fazer a transição do contacto para Lead Qualificado de Marketing (MQL). Quando wifi_dwell_time exceder 45 minutos em várias sessões, faça a transição para Lead Qualificado de Vendas (SQL). Quando uma etiqueta de programa de fidelidade for aplicada, faça a transição para Cliente.

No HubSpot, construa cada transição como um workflow separado com o gatilho definido para 'Alterações no valor da propriedade do contacto'. Isto garante que a transição é acionada imediatamente quando o limite é atingido, em vez de esperar por um processo em lote agendado.

Passo 5: Mapear a Base Legal para Processamento

Este passo é inegociável para a conformidade com o GDPR. A caixa de seleção de consentimento de marketing no Captive Portal deve ser mapeada para a propriedade hs_legal_basis do HubSpot. Quando um utilizador opta por participar, o valor deve ser definido como Freely given consent from the contact. Sem este mapeamento, os controlos de conformidade incorporados do HubSpot bloquearão o envio de e-mails de saída para estes contactos, tornando a integração comercialmente inútil para a automação de marketing.

Passo 6: Criar Listas de Segmentação

Com os dados das propriedades a fluir corretamente, crie Listas Ativas do HubSpot para os principais casos de uso de segmentação. Exemplos incluem: todos os contactos onde wifi_venue = uma localização específica (para campanhas geo-segmentadas), todos os contactos onde wifi_session_count >= 5 (para divulgação de programas de fidelidade) e todos os contactos onde wifi_last_visit está nos últimos 30 dias (para reengajamento baseado na recência).

Melhores Práticas

Impor Validação de E-mail na Origem. Cada problema de qualidade de dados no HubSpot que se origina da integração WiFi pode ser rastreado até um endereço de e-mail mal validado. Trate o formulário do portal como a primeira linha de defesa para a qualidade dos dados do CRM.

Segmentar por Local desde o Primeiro Dia. Para qualquer implementação que abranja vários locais — seja uma propriedade de retalho, um hospital ou um complexo de estádios — a propriedade wifi_venue é a dimensão de segmentação mais importante. Configure-a corretamente desde o início. Reajustar a segmentação por local depois de milhares de contactos terem sido criados sem a propriedade é um esforço de remediação significativo.

Respeitar a Arquitetura de Consentimento. O princípio do GDPR de limitação da finalidade significa que os dados recolhidos através de um portal WiFi para fins de acesso à rede não podem ser automaticamente reutilizados para marketing direto sem consentimento explícito. O mapeamento hs_legal_basis não é uma tecnicalidade — é o mecanismo legal que autoriza o caso de uso de marketing.

Monitorizar o Débito da API. Para ambientes de alta densidade, como estádios ou centros de conferências, o volume de autenticações simultâneas durante os períodos de pico pode sobrecarregar a API do HubSpot. O Purple enfileira os payloads e tenta novamente os pedidos falhados, mas é aconselhável monitorizar os volumes de chamadas da API no painel de controlo do desenvolvedor do HubSpot durante grandes eventos e garantir que o nível da conta do HubSpot suporta o débito necessário.

Utilizar Atualizações Incrementais, Não Sobrescritas Completas. Quando um visitante que regressa se conecta, o payload deve atualizar apenas as propriedades alteradas (wifi_last_visit, wifi_session_count) em vez de sobrescrever todos os campos. Isto evita a perda acidental de dados se, por exemplo, um contacto tiver atualizado o seu nome diretamente no HubSpot.

Resolução de Problemas e Mitigação de Riscos

Problema: Os contactos estão a ser criados, mas não conseguem receber e-mails de marketing. Causa Raiz: A propriedade hs_legal_basis não foi mapeada ou foi mapeada com uma string de valor incorreta. Resolução: Verifique o valor exato da string que está a ser passada. O HubSpot exige Freely given consent from the contact — qualquer variação falhará silenciosamente a verificação de conformidade.

Problema: Estão a aparecer registos de contactos duplicados no HubSpot. Causa Raiz: Vários endereços de e-mail estão a ser submetidos pelo mesmo utilizador (por exemplo, pessoal e corporativo), ou o campo de e-mail não é obrigatório no portal. Resolução: Ative a validação obrigatória de e-mail no portal. Considere implementar um workflow de fusão no HubSpot para consolidar registos onde o mesmo nome aparece com diferentes endereços de e-mail.

Problema: As propriedades personalizadas não estão a ser preenchidas, apesar da integração estar ativa. Causa Raiz: As propriedades personalizadas não foram criadas no HubPonto antes da integração ser ativada, ou os nomes de propriedade internos na configuração de mapeamento Purple não correspondem exatamente aos nomes de propriedade internos do HubSpot. Resolução: Compare os nomes de propriedade internos em HubSpot Settings > Properties com a configuração de mapeamento em Purple. Os nomes internos diferenciam maiúsculas de minúsculas e usam sublinhados, não espaços.

Problema: O estágio do ciclo de vida não está a progredir, apesar de o limite de contagem de sessões ter sido atingido. Causa Raiz: O gatilho do fluxo de trabalho do HubSpot está definido como 'Contact is enrolled' em vez de 'Contact property value changes'. Resolução: Reconstrua o fluxo de trabalho com o tipo de gatilho correto. 'Contact property value changes' é acionado sempre que a propriedade é atualizada, que é o mecanismo correto para a progressão baseada em limites.

Risco: Não conformidade com o GDPR devido à retenção de dados. Mitigação: Implemente um fluxo de trabalho do HubSpot que sinaliza os contactos como inativos após 24 meses sem atividade WiFi (ou seja, wifi_last_visit é superior a 24 meses). Acione um e-mail de re-consentimento. Se nenhuma resposta for recebida dentro de 30 dias, suprima o contacto de todas as comunicações de marketing. Isso alinha-se com o princípio do GDPR de limitação de armazenamento.

ROI e Impacto nos Negócios

O caso comercial para a integração Purple HubSpot é direto: converte um custo passivo de infraestrutura de rede num pipeline de dados ativo que gera receita. Os principais indicadores de desempenho para medir o sucesso da implementação são:

KPI	Método de Medição	Meta de Referência
Contactos novos gerados	Relatório de fonte de contacto do HubSpot	15–25% das sessões WiFi mensais
Precisão da sincronização de dados	% de contactos com todas as 4 propriedades personalizadas preenchidas	> 95%
Taxa de entrega de e-mails	Painel de saúde de e-mails do HubSpot	> 90%
Taxa de conversão MQL de contactos WiFi	Relatório de progressão do estágio do ciclo de vida	> 8% em 90 dias
Taxa de abertura de campanha (contactos de origem WiFi)	Análise de e-mail do HubSpot	> 25% (vs. 18% média da indústria)

Numa implementação de hotelaria, um hotel de 300 quartos que gera 2.000 ligações WiFi únicas por mês pode esperar adicionar aproximadamente 400–500 contactos novos e enriquecidos ao HubSpot mensalmente, assumindo uma taxa de conversão de 20–25% da ligação para a conclusão do formulário. Com uma taxa de conversão MQL conservadora de 10%, isso representa 40–50 novos leads qualificados de marketing por mês a partir de uma fonte de dados que anteriormente gerava zero valor de CRM.

Para uma cadeia de retalho que opera em 50 localizações, o volume de dados agregado é substancialmente maior, e o valor da segmentação — particularmente a capacidade de direcionar contactos por localização específica da loja — permite campanhas promocionais hiperlocalizadas que superam consistentemente os e-mails de difusão genéricos tanto na taxa de abertura quanto na conversão.

Termos-Chave e Definições

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.

Estudos de Caso

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 Implementação: 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 Implementação: 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álise de Cenários

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?

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

Mostrar Abordagem Recomendada

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?

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

Mostrar Abordagem Recomendada

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?

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

Mostrar Abordagem Recomendada

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.

Principais Conclusões

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