For years, venue WiFi platforms used MAC addresses as the anchor for guest identity. When a guest connected, their device MAC was logged. On the next visit, the same MAC appeared — the system recognised the device as a returning guest, updated visit counts, and fed analytics dashboards with return rate data.
That model stopped working in 2020.
What changed
Apple introduced MAC address randomisation in iOS 14. Android followed with Android 10. Both operating systems now assign a randomised MAC address to each WiFi network by default — meaning the same device presents a different identifier every time it connects to a given SSID, or across SSIDs.
The practical result: a guest who visited your venue 10 times in the past year looks like 10 different first-time visitors in your analytics. Return rate figures collapse. Loyalty patterns become invisible. Any segmentation that relies on device continuity — “guests who visited more than three times” — becomes unreliable.
This is not a niche technical issue. Every iPhone running iOS 14 or later and every Android device running Android 10 or later behaves this way by default. That is the majority of smartphones connecting to your guest WiFi today.
Why it matters beyond analytics
The impact goes further than reporting accuracy.
Marketing retargeting loses precision when returning guests can’t be distinguished from new ones. Campaigns that should target loyal visitors end up reaching everyone.
Loyalty and CRM can’t automatically recognise a known guest on arrival if device identity is randomised. The guest has to identify themselves manually — friction that most don’t bother with.
Network access policies that relied on MAC-based session continuity — allowing a known device to reconnect without re-authentication — break silently. Guests get prompted to log in again on every visit.
The fix: anchor to user identity, not device identity
The only durable solution is to anchor guest recognition to an authenticated user identity rather than a device identifier.
When a guest registers through a captive portal, Guest Connect, or any other Wiacom onboarding channel, their identity is tied to a verified contact — email, phone number, or social login. On subsequent visits, Wiacom recognises the returning user through their authenticated identity, regardless of what MAC address their device presents.
This is what Wiacom Connect does. It maintains a tokenised guest identity that persists across visits and across locations — completely independent of MAC address. Return visit detection, loyalty segmentation, and welcome-back portal flows all work correctly, even as every major mobile OS randomises device identifiers by default.
What venues should do now
If your WiFi analytics platform still relies primarily on MAC addresses for return visitor detection, the data you’re seeing is likely significantly undercounting return visits. The platform isn’t broken — the underlying device identifier it depended on has become unreliable.
The practical steps:
- Audit your analytics methodology — ask your WiFi platform vendor how return visitors are detected. If the answer is MAC address, the numbers are wrong.
- Move to identity-based recognition — platforms that require authenticated registration and use user identity (not device identity) as the anchor produce accurate return rate data regardless of MAC randomisation.
- Ensure your onboarding flow captures identity — a click-through portal with no registration captures nothing useful. Email, phone, or social login creates the persistent identity needed for accurate analytics.
Guest WiFi analytics are only as good as the identity layer underneath them. MAC randomisation didn’t kill guest WiFi intelligence — it just ended the era when you could get away without a proper identity layer.
Wiacom Connect identifies returning guests across locations using tokenised user identity — not MAC addresses. It works correctly on all modern iOS and Android devices.
