--- title: "WiFi marketing data architecture: from packet to profile" description: "A deep-dive into how WiFi marketing platforms transform raw network packets into actionable customer profiles — covering data collection, processing, enrichment, storage, and activation for resellers." keywords: ["wifi marketing data architecture", "wifi data pipeline", "captive portal data flow", "wifi marketing data model"] canonical: "/blog/wifi-marketing-data-architecture" meta_title: "WiFi Marketing Data Architecture: From Packet to Customer Profile" meta_description: "How WiFi marketing platforms turn raw network connections into customer profiles with emails, visit history, and segmentation. The complete data architecture explained." slug: wifi-marketing-data-architecture date: 2026-03-26 author: MyWiFi Networks brand: MyWiFi Networks category: Engineering tags: - wifi marketing data architecture - wifi data pipeline - captive portal data flow - wifi marketing engineering - guest data processing geo_optimized: true geo_date: 2026-03-26 reading_time: 11 min og_image_alt: WiFi marketing data architecture diagram — from network packet to customer profile canonical_url: "https://www.mywifinetworks.com/blog/wifi-marketing-data-architecture" schema_type: BlogPosting target_keyword: "wifi marketing data architecture" featured: false --- # 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](/features/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: ```text 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: | Visit # | Date | Duration | AP/Zone | |---------|------|----------|---------| | 1 | 2026-03-26 | 47 min | Lobby | | 2 | 2026-04-02 | 62 min | Patio | | 3 | 2026-04-09 | 38 min | Lobby | | 4 | 2026-04-18 | 55 min | Lobby | 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](/blog/captive-portal-design-patterns) — 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: ```text 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: | Segment | Criteria | Use Case | |---------|----------|----------| | New visitors | Visit count = 1 | Welcome sequence | | Regulars | Visit count ≥ 4 in 30 days | Loyalty rewards, referral ask | | At-risk | No visit in 30+ days after regular pattern | Win-back campaign | | Lapsed | No visit in 90+ days | Re-engagement offer | | High-engagement | Email open rate > 40% | VIP promotions | | Dormant contacts | No email opens in 60+ days | List hygiene | ### 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](/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](/features/marketing-automation) --- ## The complete data flow Here's the end-to-end pipeline: ```text 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](/features/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](/blog/wifi-marketing-contract-template). --- ## 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: | Metric | Healthy Range | Problem Indicator | |--------|--------------|-------------------| | Opt-in rate | 40–65% | Below 30%: portal friction too high | | Unique contacts/month | Growing or stable | Declining: hardware or portal issue | | Email deliverability | >95% | Below 90%: list hygiene needed | | Duplicate rate | <20% | Above 30%: device matching issue | | Visit frequency (regulars) | Consistent pattern | Sudden drop: venue or portal problem | --- ## 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](/integrations). 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](/register) and watch the data pipeline in action — from first guest login to automated campaign delivery.*