Event-Driven Marketing Automation Triggered by WiFi Presence

Welcome to the Purple Technical Briefing Series. I'm your host, and today we're covering a topic that sits at the intersection of network infrastructure and revenue generation: WiFi presence automation — specifically, how to architect event-driven marketing systems where a guest's physical presence, detected through your WiFi network, becomes the trigger for personalised, real-time marketing campaigns. If you're a marketing technologist, a network architect, or a venue operations director, this briefing is for you. We'll move through the core architecture, the latency considerations that separate a good implementation from a frustrating one, the deduplication problem that every team underestimates, and the privacy frameworks you cannot afford to ignore. Let's get into it. --- SECTION ONE: WHY PRESENCE IS THE MOST VALUABLE MARKETING SIGNAL YOU'RE ALREADY COLLECTING Let me start with a question. Your venue — whether it's a hotel, a retail chain, a stadium, or a conference centre — already has WiFi infrastructure. You're already generating presence events every time a device associates with an access point. The question isn't whether you have the data. The question is whether you're doing anything useful with it. Traditional digital marketing operates on intent signals: someone searches for a product, clicks an ad, opens an email. Those are valuable, but they're all happening outside your venue. WiFi presence automation operates on a fundamentally different and arguably more powerful signal: physical proximity. The guest is already there. They've already made the decision to visit. Your job is to make that visit more valuable — for them and for you. The architectural challenge is converting a raw network event — a device association, a probe request, a DHCP lease — into a contextually relevant, personalised marketing action within a timeframe that's still useful. In a retail environment, that window might be two to five minutes. In a hotel, you have the entire stay. The architecture has to be designed around those constraints from day one. --- SECTION TWO: THE FOUR-LAYER ARCHITECTURE Let me walk you through the reference architecture we recommend for enterprise WiFi presence automation. It has four distinct layers, and getting the boundaries between them right is critical. Layer one is the Network Layer. This is your physical infrastructure: access points, controllers, and the RADIUS server that handles authentication. The key design decision here is what events you're surfacing from the network. You have three options. First, probe requests — passive signals from devices scanning for known networks. Second, association events — the moment a device successfully connects to your SSID. Third, authenticated session events — where you have a confirmed user identity tied to a device, typically via a captive portal login or 802.1X authentication. My strong recommendation is to build your automation on authenticated session events, not probe requests. Here's why. Since iOS 14 and Android 10, both Apple and Google have implemented MAC address randomisation by default. A device scanning for networks will present a randomised MAC address that changes per network and, in some implementations, per session. If you're building a presence detection system on probe-based MAC tracking, you're building on sand. Association events tied to a captive portal login give you a persistent, consent-linked identifier that survives MAC randomisation. Layer two is the Presence Engine. This is where raw network events are transformed into meaningful presence signals. Purple's platform handles this through the Event Stream Engine, which performs four critical functions. Probe detection and filtering — separating genuine dwell from drive-by signals. Association event processing — capturing the moment of authenticated connection. Dwell time calculation — determining how long a device has been present before a trigger fires. And deduplication — preventing the same device from triggering the same campaign multiple times within a suppression window. The deduplication component deserves particular attention. In a busy retail environment, a single device might associate, disassociate, and reassociate with your network multiple times in an hour as the guest moves between areas of the store. Without a robust deduplication engine, you'll fire the same welcome message three times in forty minutes. That's not personalisation — that's harassment. The suppression window needs to be configurable per campaign type, per venue type, and per user segment. Layer three is the Automation Layer. This is where business logic lives. In Purple's implementation, this is LogicFlow — a visual workflow engine that lets marketing and operations teams define trigger conditions, branching logic, and action sequences without writing code. The key architectural principle here is that the automation layer should be decoupled from the network layer. Changes to your campaign logic should not require changes to your network configuration, and vice versa. This separation of concerns is what allows marketing teams to iterate on campaigns without involving IT for every change. Layer four is the Delivery Layer. This is where the triggered action actually reaches the guest: an email, an SMS, a push notification, a webhook to your CRM, or an update to your loyalty platform. The critical design consideration here is that the delivery layer must respect the consent and preference data captured at the captive portal. If a guest opted into SMS but not email, your automation must honour that. This isn't just good practice — under GDPR and PECR, it's a legal requirement. --- SECTION THREE: LATENCY — WHAT'S ACCEPTABLE AND WHAT ISN'T Let me give you the numbers, because this is where a lot of implementations go wrong. End-to-end latency in a WiFi presence automation system is the time from a device associating with your network to the guest receiving the triggered communication. In a well-architected system on modern infrastructure, this should be achievable in under ten seconds for most venue types. But acceptable latency varies significantly by context. In a transport hub — an airport or a rail terminal — you might have a guest who connects to WiFi for three minutes while waiting for a gate change. Your trigger needs to fire within sixty to ninety seconds of connection, or the moment has passed. In a hotel, where the guest will be on-property for twelve to forty-eight hours, a ten-second or even thirty-second latency is entirely acceptable. The latency budget breaks down across three components. Network-to-platform latency: the time for the association event to travel from the access point controller to the Purple platform. In a cloud-connected deployment with a well-configured controller, this should be under one second. Platform processing latency: the time for the Event Stream Engine to classify the event, check deduplication, evaluate automation conditions, and dispatch the action. In Purple's architecture, this is typically under two seconds. Delivery channel latency: the time for the downstream channel — email provider, SMS gateway, push notification service — to deliver the message. This is the component you have least control over, and it's where most of the variance lives. SMS via a Tier 1 gateway is typically under five seconds. Email delivery can range from two seconds to two minutes depending on the recipient's mail server. The practical implication: if you need sub-ten-second end-to-end delivery, SMS or push notifications are your only reliable options. Email is not a real-time channel, and you should not architect your presence automation as if it were. --- SECTION FOUR: THE DEDUPLICATION PROBLEM IN DEPTH I want to spend a few minutes on deduplication because it's the component that most commonly causes production issues in presence automation deployments. The core problem is this: a single physical visit can generate dozens of network events. A guest walks into your hotel, connects to WiFi in the lobby, walks to their room, the device briefly loses signal and reconnects, they go to the restaurant and the device roams to a different access point. From the network's perspective, that's potentially four or five association events. From the guest's perspective, it's one visit. Your deduplication engine needs to operate at two levels. Device-level deduplication collapses multiple association events from the same device within a session window into a single presence event. A session window of fifteen to thirty minutes is appropriate for most venue types — if a device disassociates and reassociates within that window, it's treated as a continuation of the same session, not a new visit. Campaign-level deduplication prevents the same campaign from firing for the same guest within a suppression window. This window should be configurable per campaign. A welcome message should have a suppression window equal to the length of a typical stay — seven days for a hotel, twenty-four hours for a retail store. A time-sensitive offer might have a suppression window of just four hours. A loyalty points reminder might suppress for thirty days. The third deduplication consideration is cross-device deduplication. If a guest has previously connected to your network on their laptop and their phone, and both devices are present simultaneously, you should fire the campaign once, not twice. This requires a profile-linking capability — typically implemented via the email address or loyalty ID captured at the captive portal — that associates multiple devices with a single guest profile. --- SECTION FIVE: PRIVACY FRAMEWORKS — THE NON-NEGOTIABLES Let me be direct about the regulatory landscape, because I've seen implementations that were technically excellent but legally problematic. Under GDPR and the UK GDPR, processing a guest's location data — which is what WiFi presence detection effectively constitutes — requires a lawful basis. The two most commonly applicable bases are consent and legitimate interest. Consent is the cleaner option: the guest explicitly agrees to presence-based marketing at the captive portal. Legitimate interest requires a documented balancing test demonstrating that your interest in sending the communication does not override the guest's privacy rights. For most marketing use cases, consent is the safer and more defensible basis. PECR — the Privacy and Electronic Communications Regulations — adds an additional layer for electronic marketing. Sending a marketing SMS or email triggered by WiFi presence requires prior consent from the recipient, regardless of your GDPR lawful basis. This consent must be specific, informed, and freely given. A pre-ticked checkbox on a captive portal does not constitute valid PECR consent. On the technical side, MAC address randomisation has effectively ended the era of passive, consent-free device tracking. Any architecture that relies on tracking randomised MAC addresses without user consent is both technically unreliable and legally questionable. The correct approach is to use the authenticated session identifier — the email address or loyalty ID — as your primary tracking key, with the MAC address used only as a session-level correlation handle. PCI DSS compliance requires that your guest WiFi network be completely isolated from any network segment that processes payment card data. This means VLAN separation at minimum, with firewall rules preventing any traffic flow between the guest network and the payment network. Your presence automation platform should sit on or connect to the guest network segment, never the payment network. --- SECTION SIX: IMPLEMENTATION RECOMMENDATIONS AND COMMON PITFALLS Let me give you the five recommendations I give every client before they go live with a presence automation deployment. First: start with your data model, not your campaigns. Before you configure a single automation rule, define your guest identity model. What is the primary identifier? How do you handle multiple devices per guest? How do you link WiFi identity to your CRM or loyalty platform? Getting this wrong at the start creates technical debt that's expensive to unwind. Second: instrument your deduplication before you go live. Run the system in observation mode — logging events without firing campaigns — for at least two weeks before launch. This gives you real data on your association event frequency, your typical session patterns, and your re-visit rates. Use this data to calibrate your suppression windows. Third: design your consent flow before your campaign flow. The captive portal is not just a network access mechanism — it's your consent capture point. Every data processing activity you intend to perform must be disclosed and consented to at this point. Work with your legal team to ensure the consent language is specific enough to be valid under PECR. Fourth: test your latency under load. A presence automation system that performs well with ten concurrent connections may degrade significantly with a thousand. Load test your event processing pipeline at two to three times your expected peak concurrent device count before going live at a major event or peak trading period. Fifth: build suppression management into your operations workflow. Marketing teams will want to run multiple campaigns simultaneously. Without a clear suppression hierarchy — which campaign takes priority when multiple triggers fire simultaneously — you'll end up with guests receiving three messages in five minutes. Define the hierarchy before campaigns go live, not after the first complaint. --- RAPID-FIRE Q&A Question: Can I use WiFi presence automation without a captive portal? Answer: Technically yes, using probe-based detection, but practically no for any compliant marketing use case. Without a captive portal, you have no consent capture mechanism and no persistent guest identifier. You're tracking randomised MACs with no legal basis. Don't do it. Question: What's the minimum access point density for reliable presence detection? Answer: For dwell time accuracy within five metres, you need overlapping coverage from at least three access points. For zone-level presence — knowing a guest is in the store, not which aisle — one AP per zone is sufficient. Design your AP density to match your use case. Question: How do I integrate Purple's event stream with my existing CRM? Answer: Purple supports webhook-based event dispatch and native integrations via Zapier and direct API. For enterprise CRM platforms like Salesforce or HubSpot, the recommended approach is a webhook to a middleware layer that handles data transformation and CRM API calls. This keeps the integration loosely coupled and easier to maintain. --- SUMMARY AND NEXT STEPS WiFi presence automation is one of the highest-ROI applications of your existing network infrastructure. The technology is mature, the regulatory framework is clear, and the implementation patterns are well-established. The difference between a successful deployment and a problematic one comes down to three things: a robust identity model that survives MAC randomisation, a deduplication engine calibrated to your specific venue and visit patterns, and a consent architecture that satisfies both GDPR and PECR requirements. If you're evaluating Purple for this use case, the two components to focus on are the Event Stream Engine for presence signal processing and LogicFlow for automation logic. Both are designed to operate at enterprise scale with the configurability you need to serve multiple venue types and campaign types from a single platform. For your next steps: review your current captive portal consent language against PECR requirements, audit your existing WiFi infrastructure for AP density adequacy, and define your guest identity model before touching any automation configuration. Thank you for listening to the Purple Technical Briefing Series. Full documentation, architecture guides, and integration references are available at purple.ai.