HubSpot und Guest WiFi: Lead-Anreicherung und Segmentierung

Dieser Leitfaden bietet IT-Managern, HubSpot-Administratoren und Marketing-Operations-Teams ein praktisches Integrations-Playbook zur Verbindung von Purple Guest WiFi mit HubSpot. Er deckt die gesamte technische Architektur ab – von der Datenerfassung über das Captive Portal und die Property-Zuordnung bis hin zur Automatisierung von Lebenszyklusphasen, Deduplizierung und Listensegmentierung – und ermöglicht es Betreibern von Veranstaltungsorten, anonyme WiFi-Verbindungen in angereicherte, verwertbare CRM-Kontakte umzuwandeln.

📖 9 Min. Lesezeit📝 2,047 Wörter🔧 2 Beispiele❓ 3 Fragen📚 9 Schlüsselbegriffe

🎧 Diesen Leitfaden anhören

Transkript anzeigen

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.

Zusammenfassung für Führungskräfte

Für Unternehmen – von weitläufigen Einzelhandelsketten bis hin zu Stadien mit hoher Kapazität – ist das Guest WiFi-Netzwerk eine der am wenigsten genutzten Datenerfassungsebenen im Technologie-Stack. Jede authentifizierte Sitzung stellt ein verifiziertes Identitätssignal dar: einen Namen, eine E-Mail-Adresse und eine explizite Marketing-Einwilligung. Dennoch lassen die meisten Organisationen diese Daten in ihrer WiFi-Management-Plattform isoliert und vollständig vom CRM getrennt. Die Purple HubSpot-Integration schließt diese Lücke, indem sie eine Echtzeit-, ereignisgesteuerte Datenpipeline zwischen dem Captive Portal und HubSpot herstellt.

Dieser Leitfaden behandelt die vollständige Bereitstellungsarchitektur: wie Guest WiFi -Portalfelder HubSpot-Standard- und benutzerdefinierten Eigenschaften zugeordnet werden, wie die Deduplizierungslogik konfiguriert wird, wie Workflows für Lebenszyklusphasen erstellt werden, die durch WiFi-Sitzungsereignisse ausgelöst werden, und wie Kontakte in verwertbare Listen segmentiert werden. Er richtet sich an HubSpot-Administratoren, Marketing Operations Manager und IT-Architekten, die diese Integration in einer Produktionsumgebung implementieren müssen, anstatt sie theoretisch zu bewerten.

Technischer Deep-Dive

Architektur und Datenfluss

Die Integration basiert auf einer Webhook-gesteuerten Architektur. Wenn sich ein Benutzer über das Purple Captive Portal authentifiziert, fungiert die Plattform als Identitätsanbieter, validiert die Sitzung und generiert eine strukturierte JSON-Nutzlast, die die demografischen und Sitzungsdaten des Benutzers enthält. Diese Nutzlast wird über einen sicheren HTTPS REST API-Aufruf an den HubSpot Contacts API-Endpunkt übertragen.

Der Datenfluss durchläuft vier diskrete Phasen: Authentifizierung auf der Portalebene, Nutzlastgenerierung durch die Purple-Plattform, API-Übertragung an HubSpot und Datensatz-Erstellung oder -Aktualisierung innerhalb des CRM. Bei Multi-Venue-Implementierungen – üblich in Einzelhandel - und Gastgewerbe -Umgebungen – wird der Veranstaltungsort-Identifikator zum Zeitpunkt der Generierung in die Nutzlast eingebettet, um sicherzustellen, dass jeder Kontaktdatensatz den für die regionale Segmentierung erforderlichen Standortkontext enthält.

Die WiFi Analytics -Ebene innerhalb von Purple generiert die Verhaltensmetriken – Sitzungsanzahl, Verweildauer, Besuchsfrequenz –, die zusammen mit den demografischen Daten übermittelt werden. Diese Metriken sind der entscheidende Faktor zwischen einer einfachen E-Mail-Erfassung und einem wirklich angereicherten CRM-Kontakt.

Mechanik der Eigenschaftszuordnung

Eine genaue Eigenschaftszuordnung ist die Grundlage einer zuverlässigen Integration. Die nativen Kontakteigenschaften von HubSpot verwalten standardmäßige demografische Felder, aber WiFi-spezifische Verhaltensdaten erfordern die Erstellung benutzerdefinierter Eigenschaften, bevor die Integration aktiviert wird.

Die folgende Tabelle definiert die empfohlene Konfiguration der Eigenschaftszuordnung:

Portalfeld	HubSpot-Eigenschaft	Eigenschaftstyp	Hinweise
Vorname	`firstname`	Einzeiliger Text	Native HubSpot-Eigenschaft
Nachname	`lastname`	Einzeiliger Text	Native HubSpot-Eigenschaft
E-Mail-Adresse	`email`	E-Mail	Primärer Deduplizierungsschlüssel
Telefonnummer	`phone`	Telefonnummer	Native HubSpot-Eigenschaft
Geburtsdatum	`date_of_birth`	Datumsauswahl	Benutzerdefinierte Eigenschaft erforderlich
Postleitzahl	`zip`	Einzeiliger Text	Native HubSpot-Eigenschaft
Marketing-Einwilligung	`hs_legal_basis`	Einzeiliger Text	Auf 'Freiwillig gegebene Einwilligung' setzen
Besuchszeitstempel	`wifi_last_visit`	Datumsauswahl	Benutzerdefinierte Eigenschaft erforderlich
Name des Veranstaltungsortes	`wifi_venue`	Einzeiliger Text	Benutzerdefinierte Eigenschaft erforderlich
Sitzungsanzahl	`wifi_session_count`	Zahl	Benutzerdefinierte Eigenschaft erforderlich
Verweildauer (Min.)	`wifi_dwell_time`	Zahl	Benutzerdefinierte Eigenschaft erforderlich

Die vier benutzerdefinierten Eigenschaften – wifi_last_visit, wifi_venue, wifi_session_count und wifi_dwell_time – müssen in HubSpot erstellt werden, bevor die Integration aktiviert wird. Werden diese Eigenschaften nicht vorab erstellt, werden die Nutzlastdaten von der HubSpot API stillschweigend verworfen.

Deduplizierung und Identitätsauflösung

HubSpot verwendet die E-Mail-Adresse als primären eindeutigen Bezeichner für Kontaktdatensätze. Wenn die Purple-Nutzlast empfangen wird, führt HubSpot einen Abgleich mit bestehenden Datensätzen durch. Wenn ein Kontakt mit der übereinstimmenden E-Mail-Adresse existiert, aktualisiert HubSpot den Datensatz mit den neuen Sitzungsdaten – erhöht wifi_session_count und aktualisiert wifi_last_visit. Wird keine Übereinstimmung gefunden, wird ein neuer Kontaktdatensatz erstellt.

Dieses Verhalten ist deterministisch und zuverlässig, vorausgesetzt, die E-Mail-Adresse ist über alle Besuche hinweg konsistent. Das Hauptrisiko sind fehlerhafte Daten an der Quelle. Wenn das Captive Portal fehlerhafte oder gefälschte E-Mail-Adressen zulässt, werden verwaiste Datensätze in HubSpot erstellt, die bei späteren Besuchen nicht abgeglichen und nicht per E-Mail kontaktiert werden können. Die Abhilfe besteht darin, eine strikte RFC 5322 E-Mail-Formatvalidierung im Portalformular zu erzwingen, wobei das E-Mail-Feld mit serverseitiger Validierung obligatorisch gemacht wird. Dies ist eine konfigurierbare Option innerhalb der Purple-Portaleinstellungen und sollte als nicht verhandelbare Grundvoraussetzung behandelt werden.

Für Organisationen, die im Gesundheitswesen oder im öffentlichen Sektor tätig sind, wo die GDPR-Konformität einer Prüfung unterliegt, ist auch zu beachten, dass der Deduplizierungsmechanismus bedeutet, dass ein einziger Kontaktdatensatz die gesamte Besuchshistorie konsolidiert. Dies vereinfacht die Beantwortung von Auskunftsersuchen (SAR) und Datenlöschungsanfragen gemäß GDPR Artikel 17.

Implementierungsleitfaden

Schritt 1: Benutzerdefinierte HubSpot-Eigenschaften vorkonfigurieren

Navigieren zu HubSpot Einstellungen > Eigenschaften > Kontakteigenschaften. Erstellen Sie die vier benutzerdefinierten Eigenschaften, die in der obigen Zuordnungstabelle aufgeführt sind. Stellen Sie sicher, dass die Datentypen korrekt eingestellt sind – wifi_last_visit muss ein Datumsauswahlfeld sein, wifi_session_count und wifi_dwell_time müssen Zahlentypen sein. Falsche Datentypen führen dazu, dass die API die Payload-Werte ablehnt.

Schritt 2: Captive Portal-Felder prüfen und anpassen

Überprüfen Sie die aktuelle Purple Captive Portal-Konfiguration. Stellen Sie sicher, dass das E-Mail-Feld als Pflichtfeld mit aktivierter Formatvalidierung festgelegt ist. Bei Bereitstellungen an mehreren Standorten stellen Sie sicher, dass der Standort-Identifikator so konfiguriert ist, dass er dynamisch basierend auf dem Standort des Zugangspunkts übergeben wird. Standorte in Transport -Umgebungen – wie Flughäfen oder Bahnhöfe – können mehrere Zonen innerhalb eines einzigen Standorts haben, die jeweils einen eindeutigen Standort-Identifikator erfordern.

Schritt 3: Eigenschaftszuordnung in Purple konfigurieren

Innerhalb der HubSpot-Integrationsseinstellungen der Purple-Plattform ordnen Sie jedes Portal-Feld dem entsprechenden internen HubSpot-Eigenschaftsnamen zu. Verwenden Sie die exakten internen Eigenschaftsnamen (z. B. wifi_session_count, nicht WiFi Session Count), um sicherzustellen, dass die API-Payload korrekt strukturiert ist.

Schritt 4: Automatisierung der Lifecycle-Phasen einrichten

Legen Sie nicht alle neuen WiFi-Verbindungen standardmäßig auf die Lifecycle-Phase 'Lead' fest. Implementieren Sie ein ereignisgesteuertes, gestaffeltes Modell mithilfe von HubSpot-Workflows.

Der empfohlene Lifecycle-Verlauf ist wie folgt. Beim ersten WiFi-Login setzen Sie die Lifecycle-Phase auf Subscriber – die korrekte HubSpot-Phase für einen Kontakt, der seine Daten angegeben, aber noch keine Verhaltensabsicht gezeigt hat. Wenn wifi_session_count innerhalb eines rollierenden 30-Tage-Fensters 2 oder mehr erreicht, lösen Sie einen Workflow aus, um den Kontakt zu Marketing Qualified Lead (MQL) zu überführen. Wenn wifi_dwell_time über mehrere Sitzungen hinweg 45 Minuten überschreitet, überführen Sie ihn zu Sales Qualified Lead (SQL). Wenn ein Treueprogramm-Tag angewendet wird, überführen Sie ihn zu Customer.

Erstellen Sie in HubSpot jeden Übergang als separaten Workflow, wobei der Auslöser auf 'Kontakt-Eigenschaftswert ändert sich' eingestellt ist. Dies stellt sicher, dass der Übergang sofort ausgelöst wird, wenn der Schwellenwert überschritten wird, anstatt auf einen geplanten Batch-Prozess zu warten.

Schritt 5: Rechtsgrundlage für die Verarbeitung zuordnen

Dieser Schritt ist für die GDPR-Konformität nicht verhandelbar. Das Kontrollkästchen für die Marketing-Einwilligung auf dem Captive Portal muss der HubSpot-Eigenschaft hs_legal_basis zugeordnet werden. Wenn ein Benutzer zustimmt, sollte der Wert auf Freely given consent from the contact gesetzt werden. Ohne diese Zuordnung blockieren die integrierten Compliance-Kontrollen von HubSpot den Versand von ausgehenden E-Mails an diese Kontakte, wodurch die Integration für die Marketing-Automatisierung kommerziell nutzlos wird.

Schritt 6: Segmentierungslisten erstellen

Wenn die Eigenschaftsdaten korrekt fließen, erstellen Sie HubSpot Active Lists für die primären Segmentierungsanwendungsfälle. Beispiele hierfür sind: alle Kontakte, bei denen wifi_venue = ein bestimmter Standort (für geo-zielgerichtete Kampagnen), alle Kontakte, bei denen wifi_session_count >= 5 (für die Ansprache von Treueprogrammen) und alle Kontakte, bei denen wifi_last_visit innerhalb der letzten 30 Tage liegt (für die Re-Engagement basierend auf Aktualität).

Best Practices

Erzwingen Sie die E-Mail-Validierung an der Quelle. Jedes Datenqualitätsproblem in HubSpot, das aus der WiFi-Integration stammt, lässt sich auf eine schlecht validierte E-Mail-Adresse zurückführen. Behandeln Sie das Portalformular als erste Verteidigungslinie für die CRM-Datenqualität.

Segmentieren Sie von Tag eins an nach Standort. Für jede Bereitstellung, die mehrere Standorte umfasst – sei es ein Einzelhandelsgeschäft, ein Krankenhausverbund oder ein Stadionkomplex – ist die Eigenschaft wifi_venue die wichtigste Segmentierungsdimension. Konfigurieren Sie sie von Anfang an korrekt. Die nachträgliche Anpassung der Standortsegmentierung, nachdem Tausende von Kontakten ohne diese Eigenschaft erstellt wurden, ist ein erheblicher Korrekturaufwand.

Respektieren Sie die Einwilligungsarchitektur. Das GDPR-Prinzip der Zweckbindung bedeutet, dass Daten, die über ein WiFi-Portal zum Zweck des Netzwerkzugangs gesammelt wurden, nicht ohne ausdrückliche Zustimmung automatisch für Direktmarketing umgenutzt werden dürfen. Die hs_legal_basis-Zuordnung ist keine technische Formalität – sie ist der rechtliche Mechanismus, der den Marketing-Anwendungsfall autorisiert.

Überwachen Sie den API-Durchsatz. In Umgebungen mit hoher Dichte, wie Stadien oder Konferenzzentren, kann das gleichzeitige Authentifizierungsvolumen während Spitzenzeiten die HubSpot API belasten. Purple reiht Payloads ein und wiederholt fehlgeschlagene Anfragen, es ist jedoch ratsam, die API-Aufrufvolumen im HubSpot-Entwickler-Dashboard während Großveranstaltungen zu überwachen und sicherzustellen, dass die HubSpot-Kontoebene den erforderlichen Durchsatz unterstützt.

Verwenden Sie inkrementelle Updates, keine vollständigen Überschreibungen. Wenn ein wiederkehrender Besucher sich verbindet, sollte die Payload nur die geänderten Eigenschaften (wifi_last_visit, wifi_session_count) aktualisieren, anstatt alle Felder zu überschreiben. Dies verhindert versehentlichen Datenverlust, wenn beispielsweise ein Kontakt seinen Namen direkt in HubSpot aktualisiert hat.

Fehlerbehebung & Risikominderung

Problem: Kontakte werden erstellt, können aber keine Marketing-E-Mails erhalten. Grundursache: Die Eigenschaft hs_legal_basis wurde nicht zugeordnet oder mit einem falschen Wert-String zugeordnet. Lösung: Überprüfen Sie den exakten übergebenen String-Wert. HubSpot erfordert Freely given consent from the contact – jede Abweichung führt stillschweigend zum Fehlschlagen der Compliance-Prüfung.

Problem: Doppelte Kontaktdatensätze erscheinen in HubSpot. Grundursache: Mehrere E-Mail-Adressen werden vom selben Benutzer übermittelt (z. B. privat und geschäftlich), oder das E-Mail-Feld ist auf dem Portal nicht obligatorisch. Lösung: Aktivieren Sie die obligatorische E-Mail-Validierung auf dem Portal. Erwägen Sie die Implementierung eines Zusammenführungs-Workflows in HubSpot, um Datensätze zu konsolidieren, bei denen derselbe Name mit unterschiedlichen E-Mail-Adressen erscheint.

Problem: Benutzerdefinierte Eigenschaften werden trotz aktiver Integration nicht ausgefüllt. Grundursache: Die benutzerdefinierten Eigenschaften wurden in Hub nicht erstelltSpot, bevor die Integration aktiviert wurde, oder die internen Eigenschaftsnamen in der Purple Mapping-Konfiguration stimmen nicht exakt mit den internen Eigenschaftsnamen von HubSpot überein. Lösung: Gleichen Sie die internen Eigenschaftsnamen in den HubSpot-Einstellungen > Eigenschaften mit der Mapping-Konfiguration in Purple ab. Interne Namen sind groß- und kleinschreibungsempfindlich und verwenden Unterstriche, keine Leerzeichen.

Problem: Der Lifecycle-Status schreitet trotz Erreichen des Schwellenwerts für die Sitzungsanzahl nicht voran. Ursache: Der HubSpot-Workflow-Trigger ist auf 'Kontakt wird registriert' statt auf 'Eigenschaftswert des Kontakts ändert sich' eingestellt. Lösung: Erstellen Sie den Workflow mit dem korrekten Trigger-Typ neu. 'Eigenschaftswert des Kontakts ändert sich' wird jedes Mal ausgelöst, wenn die Eigenschaft aktualisiert wird, was der korrekte Mechanismus für eine schwellenwertbasierte Progression ist.

Risiko: Nichteinhaltung der GDPR aufgrund von Datenaufbewahrung. Abhilfe: Implementieren Sie einen HubSpot-Workflow, der Kontakte nach 24 Monaten ohne WiFi-Aktivität (d.h. wifi_last_visit ist älter als 24 Monate) als inaktiv kennzeichnet. Lösen Sie eine E-Mail zur erneuten Einwilligung aus. Wenn innerhalb von 30 Tagen keine Antwort eingeht, schließen Sie den Kontakt von allen Marketingkommunikationen aus. Dies entspricht dem GDPR-Grundsatz der Speicherbegrenzung.

ROI & Geschäftsauswirkungen

Der geschäftliche Nutzen der Purple HubSpot-Integration ist eindeutig: Sie wandelt passive Netzwerkinfrastrukturkosten in eine aktive, umsatzfördernde Datenpipeline um. Die wichtigsten Leistungsindikatoren zur Messung des Bereitstellungserfolgs sind:

KPI	Messmethode	Benchmark-Ziel
Neu generierte Kontakte	HubSpot-Kontaktquellenbericht	15–25% der monatlichen WiFi-Sitzungen
Datensynchronisationsgenauigkeit	% der Kontakte mit allen 4 benutzerdefinierten Eigenschaften	> 95%
E-Mail-Zustellbarkeitsrate	HubSpot E-Mail-Gesundheits-Dashboard	> 90%
MQL-Konversionsrate von WiFi-Kontakten	Bericht zur Lifecycle-Status-Progression	> 8% innerhalb von 90 Tagen
Kampagnen-Öffnungsrate (WiFi-generierte Kontakte)	HubSpot E-Mail-Analysen	> 25% (vs. 18% Branchendurchschnitt)

In einer Hotelimplementierung kann ein Hotel mit 300 Zimmern, das monatlich 2.000 einzigartige WiFi-Verbindungen generiert, erwarten, monatlich etwa 400–500 neue, angereicherte Kontakte zu HubSpot hinzuzufügen, vorausgesetzt, eine Konversionsrate von 20–25% von der Verbindung zur Formularausfüllung. Bei einer konservativen MQL-Konversionsrate von 10% entspricht dies 40–50 neuen marketingqualifizierten Leads pro Monat aus einer Datenquelle, die zuvor keinen CRM-Wert generierte.

Für eine Einzelhandelskette mit 50 Standorten ist das aggregierte Datenvolumen erheblich höher, und der Segmentierungswert – insbesondere die Möglichkeit, Kontakte nach spezifischem Filialstandort anzusprechen – ermöglicht hyperlokale Werbekampagnen, die generische Broadcast-E-Mails sowohl bei der Öffnungsrate als auch bei der Konversion durchweg übertreffen.

Schlüsselbegriffe & Definitionen

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.

Fallstudien

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.

Implementierungshinweise: 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.

Implementierungshinweise: 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.

Szenarioanalyse

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?

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

Empfohlenen Ansatz anzeigen

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?

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

Empfohlenen Ansatz anzeigen

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?

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

Empfohlenen Ansatz anzeigen

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.

Wichtigste Erkenntnisse

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