Every good omnichannel retailer is trying to understand how their customers are interacting with the brand - whether that be online via an app or website or in a traditional store. The goal being, to make informed decisions on the when, where, and how of customer/retailer communications.
Arguably, the raw data needed to understand that customer behavior is readily available, but it doesn’t reside in one place, and neither is it useful in isolation. As with all well-informed decisions, the data needs to be presented in the context for which it is being used, the more data points, the better.
The same can be said for WiFi analytics where multiple data points are essential to the operation. However, showing a footfall graph or a dot on a map, whilst interesting, is meaningless for a retailer trying to understand individual customer interactions. Footfall data needs context too.
So while an individual API can provide us with the dot on the map, the business magic really begins to happen when we combine the data from multiple APIs. On the Cisco Meraki platform, the 2 APIs that provide these magic ingredients are the CMX API and the EXCAP (Splash page) API.
The first, CMX API provides real-time HTTP POSTs of all WiFi clients heard by the Meraki APs in a network. Crucially this also includes WiFi clients which are not associated to an AP, simply every WiFi device beaconing in range of an AP. A JSON stream contains (amongst other things) the MAC address of the client and the AP(s) which heard it.
So we can see when a WiFi device enters or comes close to our store, but the only unique identifier we have is the MAC address of that device. Wouldn’t it be more useful if we knew who owned it?
This is where Guest WiFi plays its part. It’s obvious to most consumers that over the last 5 years, more public locations have been offering free WiFi to their customers, and retailers are no different. By signing up to use free WiFi, consumers save their costly data plans, and (hopefully) get faster, and more reliable Internet connectivity. But the retailer is not doing that out of kindness.
When a customer signs-up for WiFi inside a retail store, they are often presented with a branded splash page. Meraki APs offer the ability to customise this splash page by making use of the EXCAP(External Captive Portal) API. On connection to the WiFi network, the Meraki AP redirects the users’ browser to a custom web page hosted on the retailers’ servers or in the cloud. The redirection URL is appended with several attributes, including the client device MAC address.
https://my.splash.page/index.php?mac=aa%3Abb%3acc%3add%3aee%3aff&real_ip=10.0.0.1
The custom webpage can then store those attributes, along with any information that the user entered into the webpage form itself (like customer name, loyalty number, email address). Immediately this forms a link between the unique identifier of the device (MAC address), and the unique identifier of the customer (their loyalty number/email). Gaining permission to do this is the responsibility of the retailer, but is almost always part of the Terms and Conditions when signing-up. Everyone reads those, right?
So, armed with this data and good cross-platform identification, it’s entirely possible to gain insights into customer behaviour both in and out of the store. Plausible examples include:
- How much time does John, who spent $500 with us in the last week, typically spend in store and when will he appear at the checkout?
- Jake spent an hour on our website last week looking at a pair of shoes. He’s just walked into a store in downtown San Francisco and his size is in stock.
- Kim is close by to our flagship store in London. Change the shop window TVs to display the accessories that complement the outfit she bought from us 2 weeks ago in New York.
Data is data, working out how it relates to each business and how it is turned into meaningful insight and revenue is the real challenge. However as developers, it’s easy to see how data from the Meraki APIs can be used to start personalising your dot on the map.