Tag Archives: mobile app tracking

The hardest part about doing enterprise shopper journey measurement and analytics is data collection. Putting new hardware in the store is no joke – and yet it’s often necessary to get the measurement you want. Still, often isn’t the same as always. Last week I talked about how you can get surprisingly powerful store measurement by taking data from your existing store WiFi and flowing it into our DM1 platform. Store Wifi gives you broad population coverage (no, shoppers don’t have to connect) but it isn’t very accurate positionally. On the other end of the measurement spectrum is geo-locating your mobile app users. It’s another way – and a good one – to get fascinating measurement about how shoppers navigate your store.

Geo-locating your mobile app users is easy and quite inexpensive. It can be done with no additional hardware in the store. It’s very accurate and, by feeding the data to DM1, you can get powerful and detailed analytics on what your mobile app users are doing in-store. When you add geo-location to your Mobile App (it just takes a few lines of code), it sends you a stream of positional data that tells you exactly where a shopper was throughout their in-store journey. Our DM1 platform ingests that stream, aggregates it, and provides you the store analytics to understand paths, funnels, usage, interactions, and much more.

That’s why, when I speak on geo-location analytics, I steal the line from Lenox Financial and describe mobile app geo-location as the biggest no brainer in the history of earth.

There’s only one real drawback to shopper measurement via mobile app and it’s the obvious one – it’s limited to the population of your mobile app users. For most retailers, that’s a small and totally non-random segment of their population.

Before I discuss the implications of that, here’s what you need to know about getting this kind of app-tracking to work and integrating it with Digital Mortar’s platform.

We’re all mobile phone users and we all know that our phones position us. Most of us could barely navigate our home city without Google or Waze or Apple Maps. I remember being in Venice and wondering how ANYONE ever got around there before GPS. It’s like the old D&D game – a maze of twisty passages, all alike. I imagine people just got lost a lot and that was probably part of the fun.

We also know that the built-in outdoor GPS positioning on the phone is pretty accurate but not super-precise. When you use it for walking you can often see just how dislocated that little blue-dot is from where your actually standing. And it can take some real mental work to figure out exactly where you are and when to turn if – as in places like Venice – you’re not navigating long straight blocks.

Indoor wayfinding has its own set of challenges. Indoor spaces by their very nature are more tightly packed so there’s a higher premium on positional accuracy. But indoor spaces are also more challenging from a measurement standpoint because signals are routinely blocked, distorted or mirrored. And, of course, indoor space are often importantly three dimensional. Outdoor mapping doesn’t have to worry about floors – but in buildings, knowing what floor you’re on is fundamental.

Fortunately, your typical smart phone these days has a whole grab bag of sensors that can be used for better indoor wayfinding. Good indoor wayfinding systems take advantage of the whole array of phone sensors – starting with GPS positioning but adding WiFi, BlueTooth signals, radio signals, magnetic fields, the inertial sensor platform and even barometric pressure.

This works pretty well since most environments these days are signal rich. It’s also very easy to improve the performance of indoor way-finding if you find that there are inside areas where positional accuracy isn’t great. In most cases, dropping a beacon or two will solve the problem.

Typically, indoor wayfinding systems work as code libraries. You put their code into your mobile app and make a few simple function calls. From a developer perspective, this type of integration is simple and straightforward. What’s more, unlike say digital analytics tagging where you need to tie measurement messaging tightly to the functionality, the geo-location libraries (at least when used for measurement) function almost as a stand-alone element of your App. So it’s trivial for developers to integrate the code – and it requires minimal design cycles. Compared to adding good digital analytics tagging to your App, it’s a breeze.

With a 3rd Party library in your App, there’s only two other things you need to do. The first is to fingerprint your location – this is essentially a calibration and mapping step where you translate the signals into site location. It’s not hard, but if you really want a turnkey setup, Digital Mortar can do this for you – it takes less than a day and involves no disruption of the site. It doesn’t even have to be done after hours.

The last step is to provision a feed from the 3rd Party Cloud instance (or your own cloud instance if you’re using a non-turnkey library that just sources the data to your servers) to our DM1 platform. Most providers provide a good, event-level feed as part of their core service. So all you have to do is turn it on. It’s not that much harder in the DIY world.

Keep in mind that most geo-location service providers are thinking about messaging, indoor way-finding and other interactive uses for their service – not analytics. So the analytics you’ll get out of the box is mostly non-existent or even less compelling that what you’d get from a WiFi vendor (and, as I mentioned last week, that aint great).

That’s what DM1 is for. Because there is no better source of data for our platform. The beauty of fully-configured mobile app services is that the positional accuracy is terrific. The event stream can be generated at a pre-determined frequency – so we’re not dependent on the somewhat random ping rates that come with other forms of electronic tracking. That means we can capture a full, accurate, and very detailed customer journey.

Even better, the nature of mobile apps is that they can provide a true omni-channel join. So you can take DM1’s CRM-based feed and integrate with your customer digital behavior to create a full journey customer database. Our CRM feed includes the customer id you pass us (usually a hashed identifier), basic visit information (visit time, length, and flags for purchase and interaction), and the time spent in each area of the store. Adding that to your customer record is powerful. And yes, it’s just for your mobile app users. But often, those are your very best customers.

Plus, there are important applications where the biases inherent in a mobile app sample aren’t particularly damaging. If, for example, you want to know how long customers are queuing at cash-wrap it’s perfectly possible to use mobile app data. When they are standing in line, they are there for the same amount of time as everyone else. And how mobile app users shop the store and take advantage of omni-channel experiences is, let’s just say, quite interesting and valuable.

That being said, it’s like any other case where you’re working with a non-random sample. You can’t assume that all your shoppers behave the way your mobile population does – and if you try to make those kinds of extrapolations, you’re going to get it wrong.

That’s why, though a mobile app feed might be the primary customer source you feed into DM1, it’s more likely that you’ll combine a mobile app feed with a full customer feed from iViu, WiFi or camera.

In DM1, we keep each feed as a separate segment. With a little bit of a code tweak to your mobile app, we can also integrate your mobile app data directly with the iViu feed so there’s no double counting. But most times, you’ll work with them as separate populations.

Either way, you get the full power of DM1’s analytics on the mobile app shopper data. Pathing, funnels, store layout, segmentation, etc. etc.:

Finally, this is also one of the best ways to collect and integrate Associate tracking. DM1 provides full Associate measurement functionality allowing you to understand when and where you’re under or over staffed in the store. Adding geo-location to your associate devices is just as easy as it is on the shopper side – and this is something you can do even if you’re not heavily invested in customer-facing mobile apps.

So if you’re suitably excited, the next question ought to be – where do you get this and how much does it cost?

There are tons of options for adding geo-location measurement to your app. The easiest and most fully-baked come from providers like IndoorAtlas and Radar. Hey, even my old digital analytics friends at Adobe and Google do this. The most full-service systems include the code libraries, platforms for fingerprinting, and robust cloud feeds. They make going from App setup to DM1 analytics a walk in the park. There are plenty of DIY alternatives as well – many open-sourced and free.

The full-service platform vendors typically charge you per location based on broad square footage ranges. It’s quite inexpensive – though the out-of-the-box pricing models tend to work better for single, very large locations than for large numbers of mid-sized stores. Most of these companies seem to engage in enterprise pricing – meaning that the price you pay is largely a function of whatever you can negotiate. And if you’d prefer, we can provide developer support integrating an open-source solution into your App. It probably won’t be quite as robust, but if your primary goal is measurement it will more than get the job done.

From the standpoint of integrating with DM1, it’s pretty much out of the box. If we don’t support the feed already, we’ll create the integration as part of getting you setup – no charge. It’s not too hard because the data streams are pretty much identical – identifier, timestamp, x, y coordinates. There really isn’t much else to it.

The measurement costs are trivial compared to what you spend on App development and small compared to what you spend on digital analytics app measurement and analysis. The data is extremely robust and – in a field plagued by bad data – quite accurate. The omni-channel join possibilities are like adding hot fudge sauce to an already delicious sundae. Paired with DM1, you can measure and optimize exactly how this critical and growing customer segment uses the store. You can study how digital and store behaviors interact. And you have an excellent data source for overall store navigation and store usage that you can pair with other data sources or use as is.

Okay…it may not be the biggest no-brainer in the history of earth. But adding geo-location and DM1 analytics to your mobile app is definitely the biggest no-brainer in shopper measurement.

People have struggled with this (big) data provider model but Factual feels like it’s found a real (and valuable) niche. Would love to see more of this grow since external data is a huge miss in most big data systems.

Targeted VoC is a powerful (and totally neglected) tool for personalization. Facebook’s experience is entirely relevant to ANY content producer. I don’t know if I can take credit for this, but I suggested this to folks at Facebook a couple of years back!

An interesting discussion of the problems in identifying “likely” voters and the benefits of behavioral data integration. Food for thought in the enterprise world as well where the equivalent is often possible but rarely done.