WiFi Passager : Comment les Opérateurs de Transport Utilisent les Données WiFi pour Comprendre les Trajets

Passenger WiFi: How Transport Operators Use WiFi Data to Understand Journeys A Purple Intelligence Briefing — approximately 10 minutes --- INTRODUCTION AND CONTEXT — 1 MINUTE Welcome to the Purple Intelligence Briefing. I'm your host, and today we're getting into something that most transport operators are sitting on without fully realising its value: passenger WiFi data. If you run IT or operations for a train operator, a bus network, or a ferry service, you almost certainly have a WiFi infrastructure already deployed. Passengers expect it. But here's the thing — that same infrastructure, when paired with the right analytics layer, becomes one of the most powerful operational intelligence tools you have access to. We're talking about understanding peak demand before it hits, mapping how passengers actually move through your network, and making service planning decisions based on real behaviour rather than ticket sales alone. Over the next ten minutes, I want to walk you through the technical architecture, the real-world use cases, the compliance considerations you cannot afford to ignore, and the practical steps to get from where you are now to a position where your WiFi is genuinely working as a business intelligence asset. Let's get into it. --- TECHNICAL DEEP-DIVE — 5 MINUTES So let's start with the fundamentals. What is passenger WiFi analytics, and how does it actually work? At its core, every time a passenger connects to your WiFi network — whether that's on a train, at a station, or on a ferry — their device generates a series of data signals. The access point logs a connection event. It records a timestamp, a session duration, signal strength, the volume of data consumed, and critically, a device identifier. In most modern deployments running IEEE 802.11ax — that's WiFi 6 — you're also capturing roaming handoffs between access points, which tells you something incredibly useful: movement. Now, here's where it gets interesting. You don't need to know who that passenger is to derive enormous operational value from that data. Anonymous, aggregated WiFi signals tell you how many devices are present in a given zone at a given time. That's footfall. They tell you how long devices remain in that zone. That's dwell time. And when you track a device as it moves between access points — from the station concourse, to the platform, to the train carriage — you get journey pattern data. Origin, route, and destination, all inferred from WiFi handoffs. The architecture to support this has four layers. First, the access point layer — your physical hardware deployed across stations, platforms, and rolling stock. For a train operator, this typically means a mix of fixed infrastructure at stations running 802.11ax, and onboard systems using cellular backhaul, often LTE or 5G, to maintain connectivity between stations. Second, the data collection layer — a centralised controller or cloud-managed platform that aggregates raw session logs from every access point. Third, the analytics engine — this is where raw logs are transformed into meaningful metrics. Dwell time distributions, peak connection windows, zone-to-zone transition rates. Platforms like Purple's WiFi Analytics layer sit here, applying machine learning models to identify patterns and anomalies. And fourth, the operations dashboard — the front end where your network planners, station managers, and commercial teams actually consume the insights. Let me give you a concrete example of what this looks like in practice. A major UK rail operator deployed WiFi analytics across a network of twelve intercity stations. Within the first quarter, they had clear visibility of connection peaks — not just by hour of day, but by platform and by service. They could see that Platform 7 at their busiest terminus was generating connection spikes forty minutes before the 07:52 departure, but that dwell time dropped sharply when that service ran late. That correlation between service performance and passenger behaviour — quantified through WiFi data — gave the operations team something they'd never had before: a real-time proxy for passenger experience that didn't rely on post-journey surveys. Now, let's talk about train station WiFi specifically, because stations present a different challenge to onboard deployments. A station is a multi-zone environment. You have the main concourse, retail areas, waiting rooms, platforms, and car parks. Each zone has different dwell time profiles and different commercial implications. A passenger spending twelve minutes in the retail zone before boarding is a very different profile to one who arrives two minutes before departure and goes straight to the platform. WiFi analytics lets you segment those behaviours and act on them — whether that's adjusting retail staffing, repositioning signage, or triggering targeted push notifications through a captive portal. On the compliance side, and I want to spend a moment here because this is where I see operators make expensive mistakes: all of this data collection must operate within a GDPR-compliant framework. Under the UK GDPR and the Data Protection Act 2018, any processing of personal data — and a device MAC address, even a randomised one, can constitute personal data in context — requires a lawful basis. For most transport operators, that lawful basis is legitimate interests, supported by a transparent privacy notice presented at the point of WiFi login. The captive portal is not just a branding opportunity; it is your consent and disclosure mechanism. Get it right. Purple's platform includes configurable consent flows that are specifically designed to meet ICO guidance, which removes a significant compliance burden from your internal team. One more technical point worth flagging: MAC address randomisation. Since iOS 14 and Android 10, most modern devices randomise their MAC address per network, which limits your ability to track returning devices across sessions. This does not kill WiFi analytics — aggregate footfall and dwell time remain fully valid — but it does affect repeat visitor identification. The workaround is authenticated WiFi: when a passenger logs in with an email address or social profile through a captive portal, you create a persistent, consented identifier that survives MAC randomisation. That's where the data gets genuinely rich. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — 2 MINUTES Right, let's talk about how to actually deploy this. Whether you're starting from scratch or retrofitting analytics onto an existing WiFi infrastructure, there are three things I'd recommend you prioritise. First, audit your existing access point coverage before you do anything else. WiFi analytics is only as good as the coverage it's built on. If you have dead zones on platforms or in station concourses, you'll have gaps in your data that will undermine the accuracy of your footfall and dwell time metrics. A proper RF survey — ideally using a tool like Ekahau — should precede any analytics deployment. Second, standardise your data schema early. One of the most common problems I see in multi-site deployments is that different access point vendors export session data in different formats. If you're running a mix of Cisco Meraki at your major stations and a different vendor on rolling stock, you need an integration layer that normalises those logs before they hit your analytics engine. Purple's platform handles this through a vendor-agnostic API layer, but if you're building something bespoke, this is where projects typically stall. Third, define your KPIs before you go live. This sounds obvious, but I've seen operators deploy a full analytics stack and then spend six months arguing about what to measure. Agree upfront: are you optimising for throughput per passenger? Dwell time in commercial zones? Connection success rate as a proxy for service quality? Each of those drives different dashboard configurations and different alerting thresholds. The pitfalls to avoid: don't over-index on raw connection counts. A high connection count on a platform during a disruption event looks like engagement — it's actually passengers frantically checking for service updates. Context matters. Build your analytics to distinguish between normal dwell patterns and disruption-driven spikes. And don't neglect your network security posture. Passenger-facing WiFi is a high-risk attack surface. Ensure your deployment enforces WPA3 where device compatibility allows, implements client isolation to prevent lateral movement between passenger devices, and uses DNS filtering to block malicious domains. Purple's platform includes DNS security controls as standard — there's a good technical breakdown of that in the Purple blog if you want to go deeper on the security architecture. --- RAPID-FIRE Q AND A — 1 MINUTE A few questions I get asked regularly on this topic. "Can we use WiFi data to count passengers without a ticketing integration?" Yes, with caveats. WiFi device counts correlate strongly with passenger volumes, but the ratio varies by route and demographic. Calibrate against manual counts or ticket gate data before relying on it for capacity planning. "Does onboard WiFi analytics work in tunnels?" The analytics engine continues to process data from onboard access points even when cellular backhaul drops. Data is buffered locally and synced when connectivity resumes. You won't have real-time dashboards in a tunnel, but you won't lose the session data either. "What's the minimum viable deployment for a small ferry operator?" A cloud-managed access point at the boarding gate, one or two access points in the passenger lounge, and a SaaS analytics platform. You can be generating dwell time and footfall data within a week of deployment for under five thousand pounds in hardware. --- SUMMARY AND NEXT STEPS — 1 MINUTE To wrap up: passenger WiFi is not just a connectivity amenity. It is an operational intelligence asset that, when deployed correctly, gives transport operators real-time visibility into passenger behaviour, peak demand patterns, and service performance proxies that no other data source can match at that cost point. The technology is mature. IEEE 802.11ax hardware is widely available. The compliance frameworks are well-established. The analytics platforms — including Purple's — are purpose-built for this use case. The barrier to entry is lower than most operators assume. If you're evaluating this for your network, the practical next step is a coverage audit followed by a proof-of-concept deployment at one or two high-traffic stations. Define three to five KPIs, run for ninety days, and let the data make the case internally. Purple's transport team works with operators across rail, bus, and ferry to scope exactly this kind of deployment. You can find more at purple.ai/industries/transport, or reach out directly for a technical briefing. Thanks for listening. Until next time. --- END OF SCRIPT