A Mobile Analytics Comparative: Insurance Apps – Part 1
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.
