Designing B2B Captive Portals: Collecting Registered Name and Company Data

Welcome to the Purple Intelligence Briefing. I'm a Senior Technical Content Strategist here at Purple, and today we're getting into a topic that comes up in almost every B2B venue deployment I work on: how to design a captive portal that collects registered name and company data properly. This isn't a consumer WiFi question. When you're running WiFi at a conference centre, a hotel with meeting facilities, a co-working space, or a business airport lounge, your visitors aren't just guests. They're professionals. They have job titles, company affiliations, and procurement authority. The data you collect at the point of WiFi registration is some of the most commercially valuable first-party data you can gather. But most venues either collect too little, collect it wrong, or collect it in a way that creates GDPR liability. We're going to fix all three of those problems today. Let me set the scene. A captive portal is the web page that intercepts a visitor's connection attempt before granting network access. The device connects to your WiFi SSID, attempts an HTTP request, and your network controller redirects that request to your portal. The visitor sees your branded login page, completes the registration form, and is then granted access. That's the basic flow. What has changed is what you do with the data afterwards, and the regulatory environment you're operating in. The B2B context changes the design requirements significantly compared to a consumer deployment. In a consumer setting, you're typically asking for a name and email address. You're building a marketing list. In a B2B setting, you want registered name and company data because that combination unlocks account-level intelligence. When you know that forty-seven people from a single financial services firm connected to your conference centre WiFi over three days, that's not just a footfall statistic. That's a sales signal. That's event ROI data. That's the kind of intelligence that justifies your venue's commercial partnerships. So let's talk about the technical architecture. A B2B captive portal deployment has four core components. First, the access point layer: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet. The access point intercepts the initial connection and redirects to the portal. Second, the portal controller, which serves the registration page, validates form submissions, and communicates with your RADIUS server to authorise the device's MAC address. Third, the identity store, where registered names, company data, and consent records are stored, and which syncs in real time to your CRM. And fourth, the analytics layer, where session data, dwell time, and repeat visit patterns are aggregated and made actionable. Purple operates as a cloud overlay across all of these hardware platforms. You don't rip and replace your existing infrastructure. You deploy Purple on top of whatever access points you already have. Across 80,000 live venues and 440 million logins in 2024, that's a significant dataset to draw on for benchmarking your own deployment. Now, the form design question. What fields should you include? The instinct is to ask for everything: name, company, job title, department, phone number, LinkedIn profile. Resist that instinct. Every additional field reduces your completion rate. Moving from two fields to five fields drops form completion by roughly 20 percent. In a venue context, that means one in five business visitors abandons the connection attempt entirely. The minimum viable B2B field set is: full name, company name, and business email address. Full name identifies the individual. Company name enables account aggregation. Business email provides a verified contact point and, critically, the domain suffix gives you the company identity even if the visitor types their company name inconsistently. Someone might register as Deloitte, Deloitte UK, or Deloitte LLP, but their email domain will always be deloitte.com. Build your data normalisation logic around the email domain, not the free-text company name field. Job title is a valuable optional field. It segments your visitor data by seniority and function. But make it optional. A visitor who skips the job title field is still a registered visitor with a name and company. A visitor who abandons the form entirely gives you nothing. Now let's talk about GDPR, because you cannot design a B2B captive portal without a solid compliance architecture. Under the UK GDPR and the EU General Data Protection Regulation, collecting name and company data from WiFi visitors requires a lawful basis for processing. For a B2B captive portal, you have two realistic options: consent under Article 6(1)(a), or legitimate interests under Article 6(1)(f). Consent is the cleaner option from a compliance standpoint. The visitor actively ticks a box, you record the timestamp and the version of your privacy notice they saw, and you have a defensible audit trail. The challenge with consent is that it must be freely given. That means WiFi access cannot be conditional on marketing consent. You need to separate the consent for network access from the consent for marketing communications. Two checkboxes: one mandatory for the terms of service, one optional for marketing. Never bundle them. Legitimate interests is a more nuanced basis. It can apply to the processing of basic session data for network security and management purposes. But for building a marketing database from visitor registrations, legitimate interests is harder to defend, particularly for B2B data where the individuals are identifiable professionals. My recommendation: use consent, design the form properly, and you'll have a clean compliance posture. One more technical point before we move to implementation. MAC address randomisation. Since iOS 14 and Android 10, mobile devices randomise their MAC address on a per-network basis by default. This means the MAC address your access point sees when a visitor connects today may be different from the MAC address you saw last month, even if it's the same device and the same person. For B2B registered name and company data collection, this is less of a problem, because your identity anchor is the registered email address, not the MAC address. The email address is stable. Build your identity resolution logic around email, and MAC randomisation becomes a secondary concern. Now let me walk you through two real-world implementation scenarios that illustrate how this works in practice. The first is a conference centre in the financial district. They run 200 events per year, with an average of 300 attendees per event. Before deploying a properly designed B2B captive portal, their WiFi registration data was a mess: inconsistent company names, personal email addresses, no job title data, and no consent records. They couldn't answer basic questions like which companies send us the most delegates, or what's the average seniority of our attendees. After deploying a structured B2B portal with full name, company name, business email, and optional job title fields, combined with email domain normalisation on the back end, they built a clean account-level database within six months. They could now show exhibitors that 34 percent of their attendees came from FTSE 100 companies. That data point directly supported a 40 percent increase in their sponsorship rates. The WiFi registration form became a revenue-generating asset. The second scenario is a hotel group with 45 properties, each with meeting and conference facilities. Their challenge was consistency: each property had a slightly different portal configuration, different field sets, and data stored in different systems. A guest who attended a conference at the Manchester property and then stayed at the London property was treated as two separate, unrelated visitors. By standardising on a single B2B portal template deployed across all 45 properties, with centralised data storage and email-based identity resolution, they built a unified visitor database. Within twelve months, they identified 8,200 business visitors who had used multiple properties. That cohort became the foundation of a targeted account-based marketing programme. The cost of deploying the standardised portal was recovered within the first quarter through incremental conference bookings from that identified cohort. Now let me give you the implementation pitfalls to avoid. These are the mistakes I see most often. Pitfall one: free-text company name without normalisation. If you accept free-text input for company name and don't normalise it on the back end, your database will contain hundreds of variations of the same company. Use the email domain as your primary company identifier. Pitfall two: bundling WiFi access consent with marketing consent. This is a GDPR violation. The Information Commissioner's Office is explicit: consent for marketing must be separate from consent for the service itself. If a visitor has to consent to marketing emails to get WiFi access, that consent is not freely given and is therefore invalid. Pitfall three: no session timeout or bandwidth policy on the B2B SSID. Set a per-device bandwidth cap and a session timeout. Four hours is a reasonable default for a conference environment. Pitfall four: storing consent records in the same system as session logs. Consent records need a longer retention period than session logs. Session logs can be purged after 30 days. Consent records should be retained for the duration of the relationship plus two years. Use a platform like Purple that applies different retention rules to different data types automatically. Now for the rapid-fire questions I get asked most often. Should we use LinkedIn login instead of a registration form for B2B venues? LinkedIn OAuth gives you name, company, job title, and industry sector without asking the visitor to type anything. The data quality is higher than free-text input. The trade-off is lower conversion: not every business visitor has a LinkedIn account. My recommendation is to offer LinkedIn as an option alongside a standard form, not as the only method. How do we handle visitors who use personal email addresses instead of business email? You can require a business email domain by validating against a list of known consumer domains and rejecting them. Or you can accept any email address and flag personal domains for manual review. For high-value B2B venues, I'd recommend the first approach with a clear error message explaining why a business email is required. Can we integrate the captive portal data directly with Salesforce or HubSpot? Yes. Purple's platform provides native integrations with major CRM platforms. The registered name and company data flows directly into your CRM as a new contact or updates an existing record, with the WiFi visit logged as an activity. To summarise the key points from today's briefing. Design your B2B captive portal around three mandatory fields: full name, company name, and business email. Add job title as an optional field. Keep the form short. Every additional mandatory field costs you completion rate. Use the email domain as your canonical company identifier. Normalise free-text company names on the back end. Build your account-level intelligence on email domain, not on what visitors type in the company name field. Separate your consent checkboxes. One mandatory checkbox for terms of service and network access. One optional checkbox for marketing communications. Never bundle them. Log every consent event with a timestamp and privacy notice version. Address MAC randomisation by anchoring your identity resolution to email address, not MAC address. The email is stable across sessions and devices. And finally, choose a platform that handles the compliance architecture for you. Purple is ISO 27001 certified, GDPR and CCPA compliant, and Cyber Essentials certified. The consent logging, data retention rules, and data subject access request response tools are built in. Your next step is to audit your current portal configuration against the field set and compliance checklist I've outlined today. If you're running a B2B venue and you're not collecting registered name and company data in a structured, compliant way, you're leaving commercial intelligence on the table. For more technical guides and implementation resources, visit purple.ai. Thank you for listening to the Purple Intelligence Briefing.