Tag: Mobile Analytics

Analytics Strategy, Industry Analysis

A Mobile Analytics Comparative: Insurance Apps – Part 2

Posted on by Eric Peterson

Mobile analytics “Events” are the actions that users take when using your mobile apps. These events can be anything from opening the app, to swiping through screens, taking a photo of a fender-bender, or submitting a new claim. Events are the lifeblood of any mobile application and tracking them is essential to any mobile analytics platform.

In Part 1 of this comparative, I looked at the total number of SDK’s within the top 5 insurance apps (based on US Advertising spend) and posted some observations about what I found. Here in Part 2, I will take a closer look at how mobile analytics events are tracked and the specific events tracked by each of these apps.

 

Out-of-the-box Events for mobile apps. While every analytics tool handles in-app event tracking differently, vendors seem to take one of two approaches when tracking events on mobile apps. The first, which is common among analytics vendors used by our group of insurance apps, is to provide basic default events and offer the ability to track custom events as well. The second method is to track all events by default and allow users to identify which ones are most valuable to them. Both scenarios have distinct advantages, but neither will suffice unless you take the time to understand what goals you’re trying to accomplish with your mobile app and what type of engagement you wish to encourage users to take.

Adobe Analytics

Adobe Analytics’ mobile SDK offers a number of capabilities out-of-the-box and their Lifecycle metrics provide valuable context data to help analysts see what’s going on within their apps. Adobe Analytics collects: launches, crashes, upgrades, and session information by default. Additionally, Lifecycle metrics provide data on engaged users, days since first/last use, hour of day, day of week, and device, carrier, and operating system info as well. Adobe Analytics also offers a number of default dimensions within its mobile SDK that enable analysts to capture location data, lifetime value, and campaign details. To see a full list of Adobe Analytics’ default mobile metrics and dimensions, click here. Adobe also offers the ability to track custom events, which can be configured as variables that will reveal in the traditional Adobe Analytics interface. Also, for Adobe users, the mobile SDK supports other Marketing Cloud solutions like Target, Audience Manager and Visitor ID, making it a great choice for those looking for a single solution.

Google Analytics (Firebase)

Google Analytics and their mobile specific platform, Firebase, offer a number of default metrics as well. First Opens, Sessions Starts, and user Engagement are all provided out-of-the-box. These events, along with in app purchases, app updates/removes, mobile notification info, and dynamic link data are all offered as defaults. To view Google Analytics (Firebase’s) full list of default mobile events, click here. Google also offers the ability to track custom events as well. With Google Firebase, product owners and developers can build and manage apps and configure tracking that can share data to Google Analytics. This enables the opportunity to contain your data in a single location so that your mobile data is viewable along with your traditional web analytics data.   

 

Auto Event Tracking. There are a few vendors on the app analytics marketplace that take the approach of auto-tracking events and enabling users to identify keys events and label them for analysis within their analytics interfaces.

Mixpanel is one of these solutions and offers Autotrack as a service to capture clicks on links, buttons, and forms as well as other in-app actions. They built a point-and-click editor, which allows product owners to configure tracking by navigating web pages and mobile apps as they would normally. The editor provides valuable contextual data like how many times a button has been viewed and clicked in the past few days, which helps hone in on the most valuable assets. But what’s very cool is that once events are identified in Autotrack, reports will contain historic data on these events back to the time of first implementation of Autotrack. Event data can also be augmented with context data called “properties” that adds additional detail to key events.

Heap Analytics is another solution that automatically captures user actions with its base code. Similar to Mixpanel, Heap Analytics captures clicks, taps, gestures, and form fills through its default tracking. Their Event Visualizer allows Analysts or product owners to configure tracking by navigating apps and interacting with the interface to record, name, and define events. This solution also works retroactively and enables analysis of events within the Heap Analytics interface. Both of these solutions take much of the pain of traditional tagging and configuration away from Analysts and product owners allowing them to get into data analysis and insights quickly.

As with most things in digital analytics, there are multiple ways to get the job done and multiple tools to choose from to accomplish the task of tracking events. I didn’t even mention other popular mobile analytics platforms Flurry and Localytics here mainly for brevity sake, so perhaps I need to another blog post to call out the differences between vendors. Which tool you decide on has a lot to do with ease of use, if you want to see your web and mobile data in a common interface, and the level of complexity you’re willing to endure to get robust mobile tracking.

 

What the Insurance Apps are tracking

All of the insurance apps that we evaluated in this comparative are using either Adobe Analytics, Google Analytics, or both on their apps. No instances of Mixpanel nor Heap Analytics (nor Flurry, nor Localytics for that matter) and their auto tracking features were detected, indicating that each of these companies elected to go the more traditional route for app analytics tracking. That said, there were some similarities and differences in the way that each company was tracking events within their apps.

Opens

Tracking Opens is arguably the most basic of events that can (and should) be tracked within your mobile apps. Each of the insurance apps I evaluated contained Open event tracking, which is not surprising since it’s offered by default from their vendors. Yet, what companies do with their Open event data is where things get interesting. For this evaluation, I did not look at how any of these firms are using data, so I won’t pass judgement on their utilization of this basic yet informative data point. Instead, I offer some concepts for thinking about how to analyse your data. Opens are the basis for determining active users, which is a highly regarded KPI in the mobile world. Use Open rates, plus other events to determine which users are active within your mobile apps. Also, by using contextual data such as time of day and location, you can learn a great deal about when and where your users are opening their apps. Are they primarily at home? On the highway? In cities? Understanding this data can help to tailor content for users when they need it most. By analyzing Open Event data and the contextual values that are associated with this event, you can learn a lot about how your customers are using your app.  

Authentication

The ability to recognize a user and authenticate based on device or customer ID is a unique advantage in the mobile world. Within our insurance app sample, we found that Progressive was actively tracking logged in users, yet Geico, State Farm and Allstate were, too, with Adobe’s native Marketing Cloud ID. Each of these firms is tapping into one of the great advantages of mobile in its ability to authenticate individual users. The practical applications of authentication include the ability to customize content for known users, target them with offers and promotions, and even to use geolocation to push messages within apps. A recent article about mobile analytics in the auto industry cited an eMarketer study that revealed, “…one of Audi’s retailers recently ran a two-month campaign targeted to mobile-first audiences. The dealership was able to link 40% of total car sales to the targeted mobile audience.” This linkage is unheard of in the web world, but it’s entirely possible in mobile.

Navigation Flows

Navigation flows provide the ability to see how users are navigating your apps to determine usability, utility, and effectiveness. While our short insurance app comparative didn’t dive deep into any of the apps, we did find tracking within the Geico app that indicated navigational elements such as previous page name, page name, and section of their app. Presumably, these metrics are used to help to determine how users are traversing apps which provides a great deal of insight into usability. Navigation flows in these apps are valuable because even in my short script, I attempted to start a new auto insurance quote and was handed off to a responsive website for each of the five insurance providers evaluated. By defining your desired navigational paths and simply knowing how many users encounter your desired flow and how many drop off versus completing an action, like the quote online, provides key insight into the way the app is built and utilized. Knowing abandon rates for key functions might influence some providers to develop more native features and capabilities if they can be justified through navigational flows and analysis.   

 

What are you tracking?

Throughout this comparative we learned that companies are using relatively similar event tracking, which is for the most part standard offerings from their vendors. However, we expect as apps become more critical in business operations and more users are relying on apps to complete their transactions, that the level of customized tracking will undoubtedly improve. But as with all things in analytics, tracking events and dimensions that support your business goals is the top priority and this is where you should start and/or focus if you’re responsible for tracking your company’s mobile apps.  

If this is your role, it’s important to keep in mind that tracking apps can be a messy process. If your developers and product managers are building apps with the desire of creating immersive experiences, then it’s easy to try and track everything and lose sight of the key goals. Tagging complex or immersive apps can be a technical challenge, which is why you should take the opportunity to identify clear KPIs (such as get a quote), and also ensure that your UX and design teams are outlining the critical paths within your apps so everyone is on the same page about what you’re trying to accomplish and how you expect users to get there. This approach will ultimately lead to readily available insights (whether you were right or wrong), because you set the metrics by which you will measure success ahead of time. This pragmatic approach to mobile measurement is often overlooked yet essential for measuring what’s critically important and determining if your applications are successful. Continue reading →

0
Analysis

A Mobile Analytics Comparative: Insurance Apps – Part 1

Posted on by Eric Peterson

Throughout this mobile analytics comparative, I was looking for a few specific things to determine data collected by a group of high-profile apps and how their respective analytics tools were architected to facilitate analysis. Part 1 of this blog series focuses on the SDKs installed within each app and Part 2 will dive into the specific events and variables requested by each apps’ analytics tool.

My comparative focuses on insurance companies in the US, because they undoubtedly spend more money battling it out on advertising than any other industry around. I can testify that it’s working because my TV-watching-kids walk around the house humming insurance jingles (and craftily changing the words) on a daily basis.

According to Statista, the Top 5 Big Spenders on advertising include: Geico, State Farm, Progressive, Liberty Mutual, and Allstate (in that order). I was curious to know how these ad spending giants track their mobile apps. So after downloading each app, I ran my iOS device through my computer using manual HTTP proxy settings and observed calls using Charles to determine what data was being collected and passed through each application. Since I don’t have accounts at each of these insurance providers, my assessment involved three steps: 1) launching the app, 2) agreeing to their user acceptance rules, and 3) swiping my way to the auto quote section. Each app eventually made a hand-off to their responsive websites to complete the quote, which is where my simulated scripts ended.

My findings revealed a good deal about each of these organizations just by digging into their apps from the outside. I should mention that none of the companies in this comparative knew they were being evaluated and I have not validated my observed data requests against any of their internal analytics solutions to determine if data is actually populating in their analytics solutions as designed. If you’re reading this and happen to work at one of these firms, I welcome your feedback and please let me know if I’ve missed the mark on anything critical.

Here’s a few of the notable things I uncovered during this study:

Every app evaluated is using one or more analytics tracking tools. Not surprisingly, we found that all of the insurance companies in our evaluation have analytics tracking tools installed on their mobile apps. Either Adobe Analytics and Google Analytics was present in each of these apps, mirroring the industry dominance that these companies have in the web analytics world. Adobe Analytics was present in three out of five iOS applications and in four out of five Android applications. Google Analytics was present in in just two of the iOS apps, but Google Play Analytics and Firebase Analytics (or both) were present in all but one of the Android apps. See the matrix below for more details.   

The average number of SDKs installed within each app is 19. To determine the total number of SDKs installed within each app, I used a free tool offered by SafeDK called the App X-Ray which allows you to scan any Android app to determine the SDKs installed within that app. This clever little tool revealed a whole lot about each app and how 3rd party services are embedded within each one to deliver different services and solutions. If you’re not familiar with the world of SDKs, these “Software Developer Kits” are used to deploy tools and services within apps such as analytics, advertising, payment solutions, location-based services, crash reporting, attribution, and more. According to SafeDK, as of the 2nd Quarter in 2017, the average app has 17.8 SDKs installed. This fits extraordinarily well into our small sample of insurance apps that have on average 18.6 SDKs embedded. I found instances of crash reporting, location, messaging, voice of customer, advertising, payment, and numerous tools installed within the insurance app sample I evaluated. According to SafeDK: analytics, advertising, and social are the three most commonly used SDKs within apps (with payment as a close 4th).

 

 

For app developers, SDKs are essential. Whether it’s adding a tool in the rush to market for a new app, or accessing a library that wouldn’t be available otherwise, SDKs are critical to app development. SDKs provide add-on services and functions that save time and money and there are hundreds available. But just because they exist doesn’t mean you have to use them. I’ll let my bias shine and state that you’d be silly not to use analytics SDKs, but during my assessment, I found that four out of five Android insurance apps had SDKs installed, but not in use. For Allstate, they had a total of 31 SDKs installed in their Android app and a whopping 14 were not actually being used. This presents a whole host of considerations about waste, app bloat, and app size that are considerations for mobile developers and product owners.

 

Messaging and Location SDKs were prevalent. Within my small sample of insurance apps, I found that three out of five used messaging services to (presumably) deliver in-app messaging to customers. Additionally, all but one of the providers used a dedicated location services SDK within their apps, which again makes a lot of sense for the insurance app, where you might find a customer in need of roadside assistance at any given time. Both of these categories are up-and-coming in the world of mobile apps and can tie nicely into your integrated marketing efforts if executed correctly.  

 

Very little user experience testing is going on within these apps. Whereas messaging and location SDKs were apparent, few of the insurance apps we evaluated offered any testing tools within their apps. For testing here we’re talking about analytics testing similar to the Adobe Target or Optimizely tests that you’d find on a website. Not QA testing. Yet, as with websites, testing often reflects a higher level of maturity among companies using analytics. For this group, Geico was the only company to employ Adobe Target for testing and optimization of its app. One of the things that we do know about mobile is that apps are constantly going through new releases and updates, so there could be new features and functions rolled out with each new release. However, this is no substitute for actual user testing with A/B or multivariate combinations of creative to get your install base using your app and coming back for more.

 

Tag management tools are still being shoehorned into mobile apps. Each of the five insurance apps we evaluated included calls to Tag Management Solutions which are increasingly common (and indispensable) in traditional web analytics. Yet, as we all know, mobile is an entirely different beast than the web and data collection requires a different methodology. The event-based tracking method of mobile, coupled with conditional execution and in some cases batch uploading create challenges for web-designed Tag Management Solutions. Lee Isensee of #MeasureSlack riffed on this topic a while ago, but his premise still holds true in that for native apps (which most of my examples are) and a large portion of hybrid apps, Tag Management technology simply doesn’t work well. While I’m not chastising any of these insurance providers for embedding TMS within their apps (mainly because I’m not entirely sure how they’re using them without looking from the inside), I caution you to carefully consider how you utilize TMS within your native apps.

 

Behavioral, Context, and Navigational data collection varies widely across these apps. So far, I’ve spent a lot of time writing about the SDKs installed within each app, but this still tells us very little about what actual data is collected by each of these applications. Since this post is already getting long in the tooth, I will save the nitty gritty details for Part 2, but I can tell you that there are a lot of variances when it comes to behavioral, context, and navigational data collected within each app analytics solution.

Tune into the next post for more details, but in the meantime, write me a comment below or shoot me an email at john@analyticsdemystified.com if you have thoughts, questions or ideas about app analytics.

 

0