WiFi marketing data architecture: from packet to profile

Key takeaways: A WiFi marketing platform processes three data streams: authentication data (from the captive portal login), presence data (from AP connection/disconnection events), and behavioral data (from marketing campaign interactions). These streams converge into a unified customer profile that includes identity (email, name, phone), device fingerprint (MAC, device type, OS), visit history (timestamps, duration, frequency), and engagement history (emails opened, links clicked, campaigns received). Understanding this architecture helps resellers explain data value to venue operators and troubleshoot when data isn't flowing correctly.

Architecture descriptions are generalized. Specific implementation details vary by platform.

When a guest connects to WiFi and logs in through a captive portal, what happens to their data? Where does it go? How does it get from "someone typed an email address" to "this person has visited 14 times, spends an average of 47 minutes per visit, opens 38% of emails, and hasn't been back in 22 days"?

The answer is a data pipeline that starts at the network layer and ends at a customer profile. Every WiFi marketing platform runs some version of this pipeline. Here's how it works, layer by layer.

---

Layer 1: network events

What the access point sees

When a device connects to a WiFi network, the access point records several pieces of raw data:

• •MAC address — A 48-bit hardware identifier for the device's WiFi radio. Example: A4:83:E7:2F:C1:9B
• •Association timestamp — When the device connected
• •Disassociation timestamp — When the device disconnected
• •Signal strength (RSSI) — How close the device is to the AP, measured in dBm
• •AP identifier — Which specific access point the device connected to
• •SSID — Which network name the device joined
• •Band/channel — 2.4 GHz, 5 GHz, or 6 GHz; specific channel number
• •Vendor OUI — The first 24 bits of the MAC address identify the device manufacturer (Apple, Samsung, etc.)

This is presence data. It tells you a device was here, for how long, on which AP, and roughly how far from the AP it was. It doesn't tell you who the person is.

MAC address randomization caveat

Since iOS 14 and Android 10, devices randomize their MAC address per SSID by default. A single iPhone generates a different random MAC for each WiFi network it joins. This means the MAC address alone is no longer a reliable persistent identifier.

Why this matters: Presence analytics that rely solely on MAC tracking overcount unique visitors (the same person appears as a different device each time their MAC rotates). This is why authenticated captive portals — where the guest provides an email — are becoming essential. The email becomes the persistent identifier that MAC addresses no longer reliably provide.

---

Layer 2: authentication data

What the captive portal captures

When the guest authenticates through the captive portal, the platform captures identity data:

Email login:

• •Email address
• •Name (if form field included)
• •Consent status (opted in/out of marketing)
• •Portal form submission timestamp

Social login (Facebook, Google, etc.):

• •Email address (from the social provider's OAuth response)
• •Name
• •Profile photo URL
• •Gender (if returned by the provider)
• •Age range (if returned by the provider)
• •Social profile ID

SMS login:

• •Phone number (verified via SMS code)
• •Device type (inferred)

WhatsApp login:

• •Phone number (verified via WhatsApp OTP)
• •WhatsApp profile name

The authentication-to-device link

When the guest submits the portal form or completes social login, the platform links the identity data to the device's network session:

Authentication Event:
  email: "jane@example.com"
  name: "Jane Smith"
  consent: true
  timestamp: 2026-03-26T14:32:07Z

Device Session:
  mac: "A4:83:E7:2F:C1:9B"
  ssid: "Cafe_Guest"
  ap_id: "AP-LOBBY-01"
  association_time: 2026-03-26T14:30:45Z

Linked Profile:
  contact_id: "c_8f3a2b1d"
  email: "jane@example.com"
  name: "Jane Smith"
  device_mac: "A4:83:E7:2F:C1:9B"
  first_seen: 2026-03-26T14:30:45Z
  last_seen: [updates on disconnection]
  visit_count: 1

This link is the foundation of the customer profile. Every subsequent connection from the same email (even with a different MAC due to randomization) merges into the same profile.

---

Layer 3: profile enrichment

Visit history accumulation

Each time the guest returns and connects to WiFi, the platform appends a visit record:

• •Visit date and time
• •Duration (association to disassociation)
• •Which AP(s) the device connected to (for multi-AP venues, this indicates zone/area)
• •New vs. returning flag

Over time, this accumulates into a visit history:

From this data, the platform calculates:

• •Average visit duration: 50.5 minutes
• •Visit frequency: Every 7.6 days
• •Preferred zone: Lobby (3 of 4 visits)
• •Trend: Consistent weekly visitor
• •Last visit: 2026-04-18 (X days ago)

Device fingerprinting

The User-Agent string captured during portal authentication reveals:

• •Device type (iPhone, Samsung Galaxy, Pixel, laptop, tablet)
• •Operating system and version (iOS 18.2, Android 15, Windows 11)
• •Browser (Safari, Chrome, Samsung Internet)

This data enables device-type segmentation. A venue with 80% iOS users has a different demographic profile than one with 80% Android users. Device data also helps with portal design optimization — a venue with predominantly older Android devices should avoid heavy JavaScript portals.

Behavioral data from campaigns

When the platform sends an email or SMS to the captured contact, engagement data flows back:

• •Email opened (yes/no, timestamp)
• •Link clicked (which link, timestamp)
• •Unsubscribed (yes/no)
• •SMS delivered (yes/no)
• •SMS replied (content, timestamp)

This data enriches the profile with engagement metrics:

Contact Profile:
  email: "jane@example.com"
  emails_sent: 12
  emails_opened: 5  (41.6% open rate)
  links_clicked: 3  (25% CTR)
  last_email_opened: 2026-04-15
  sms_sent: 2
  sms_delivered: 2
  unsubscribed: false

---

Layer 4: segmentation and activation

Automated segments

The platform automatically creates segments based on profile data:

Activation channels

Once a contact is segmented, the platform activates them through:

• •Email campaigns — Built-in email builder or integration with Mailchimp, ActiveCampaign, HubSpot via integrations
• •SMS/MMS — Through Twilio integration
• •Facebook Custom Audiences — Sync email lists to Meta for retargeting ads
• •Webhooks — Push data to any external system via JSON webhooks
• •Zapier — Connect to 1,000+ apps
• •Marketing automation triggers — Time-based and event-based sequences through automation engine

---

The complete data flow

Here's the end-to-end pipeline:

1. DEVICE CONNECTS
   AP records: MAC, timestamp, RSSI, channel

2. PORTAL REDIRECT
   Controller redirects to captive portal

3. GUEST AUTHENTICATES
   Portal captures: email, name, consent
   Platform links: identity → device session

4. PROFILE CREATED/UPDATED
   New contact → create profile
   Returning contact → update visit history

5. DATA ENRICHMENT
   Visit history accumulates
   Device fingerprint attached
   Campaign engagement tracked

6. SEGMENTATION
   Rules engine evaluates segments
   Contact moves between segments dynamically

7. ACTIVATION
   Automation triggers fire based on segment membership
   Campaigns send through email/SMS/webhook

8. FEEDBACK LOOP
   Campaign engagement data feeds back to profile
   Engagement metrics update segments
   Cycle repeats

Each step adds data to the profile. Over 6–12 months, a venue with 1,000 monthly WiFi logins builds a customer database with:

• •4,000–6,000 unique contacts (accounting for return visits)
• •Detailed visit history per contact
• •Device and demographic signals
• •Email engagement metrics
• •Automated segmentation labels

That database is an asset. It has real, quantifiable value — and it's what resellers are actually selling when they pitch "WiFi marketing."

---

Data storage and privacy

Where the data lives

MyWiFi stores all data on AWS infrastructure with:

• •SSL/TLS encryption in transit
• •Encryption at rest for stored data
• •Data centers in AWS regions (primary: US-East)
• •CloudFront CDN for portal delivery

Privacy compliance

The data architecture must comply with:

• •GDPR (EU) — Consent-based collection, right to erasure, data portability
• •CCPA/CPRA (California) — Right to know, delete, and opt-out of data sale
• •LGPD (Brazil) — Similar to GDPR, applies to Brazilian data subjects
• •POPIA (South Africa) — Consent and purpose limitation

The captive portal handles consent collection at the point of data entry. Opt-out links are included in every email. Data deletion requests are processed through the platform's compliance tools.

For resellers, this is important: you're the data processor (or sub-processor), and your venue client is the data controller. The platform provides the technical compliance tools, but the venue must have its own privacy policy that covers WiFi data collection. Include this in your service contracts.

---

What resellers should know

Explaining data value to venue operators

Most venue operators don't think about data architecture. They think about customer lists. Frame the conversation:

"Right now, you have a list of people who've ordered online or signed up for your newsletter. That's maybe 500 people. With WiFi data capture, you'll have a list of everyone who physically visits your location — 2,000, 5,000, 10,000 people over a year. And for each person, you'll know how often they visit, how long they stay, and which emails they open. That's not a mailing list. That's a customer intelligence database."

Data quality indicators

Track these metrics to assess deployment health:

---

FAQ

How does the platform handle duplicate contacts (same person, different devices)? The email address is the primary deduplication key. If the same email authenticates from an iPhone on Tuesday and a laptop on Saturday, both sessions link to the same contact profile. MAC addresses alone don't drive deduplication because of randomization.

What happens if a guest uses a fake email? Fake emails (like asdf@gmail.com) are captured but fail on first send (hard bounce). The platform marks these contacts as invalid and excludes them from future campaigns. Real-time email validation on the portal form catches many fakes before submission.

How long is guest data retained? Configurable by the account administrator. Default retention is indefinite until the guest requests deletion or the account admin purges inactive contacts. GDPR-covered deployments should set retention policies aligned with the venue's privacy policy.

Can I export the raw data? Yes. MyWiFi supports CSV, PDF, and JSON webhook exports. Enterprise and MSP plans include API access for custom data extraction and integration.

What data is NOT captured by WiFi marketing? WiFi marketing does not capture: browsing history (which websites the guest visits after authentication), app usage, message content, file transfers, or any traffic content. The platform captures identity data (from the portal), network metadata (connection events), and campaign engagement data. It does not perform deep packet inspection.

---

Resellers wanting to understand the data architecture in practice can start a free trial and watch the data pipeline in action — from first guest login to automated campaign delivery.