Analytics Planning for Engineers

There’s a difference between what people say and what people do. Regarding mobile applications, the former can be measured with app store feedback or customer support calls. But how do we measure what people are actually doing? “Add analytics!” you might say. Simple, right? If it were, this story wouldn’t exist.

One of our mobile apps began tracking data through Google Analytics around 2013. We then switched over to Firebase analytics when it became available and began tracking everything on our Android and iOS apps. We started with logging every screen view, then with some buttons, then our developers thought “Oh yeah this would be cool to see usage of”, we would log that too. Years of unchecked growth and independent decisions led us to a mess of a dashboard. Product Owners would ask “Hey how many people use the books feature?” And when we’d pull up events we would notice “Oh hey there’s an event called ‘Books’.. But wait there’s another called ‘books’, and a third one called ‘book_viewed’. Uh… we’ll get back to you.” Disparate data led to guesses, which led to assumptions, ultimately turning into divisive conversations on what new features to work on and which existing features to enhance. An unorganized dashboard, coupled with regular agile sprint work led to a forgotten and underutilized capability.

Without much context, these event names titles are often misleading or difficult to decipher. Are they even still in use?

So how do we turn this around? By logging analytics with a purpose. Before we go that route, forget about historical data. “But I’ve got 8 years of logs here!” If it means nothing now and there’s no time to sift through it and manually match records then there won’t suddenly be time. This is a sunk cost. We are taking advantage of the fact that analytics logging is an evolution. It can be changed over time to better suit our needs.

Have a Plan

The first step in solving any problem is acknowledging there is a problem to solve. Don’t log events just because you can. Think about what interactions the business cares about and how to measure them.

For example, if there are eight different ways of updating the price of a vehicle either by manual input, sliders, or recommended values, you might want to know if people are using the recommended values or ignoring them. The next step is determining how to log that information. This part is important! Write down the problems you’re trying to solve and questions you need answers to. This will fuel efficient and relevant user analytics logging. For more information on this subject, Mixpanel offers a quick and dirty tracking plan template. Amplitude’s blog provides a thorough guide to Data Taxonomy.

Using Excel for the finest analytics planning. Use what works for your team and helps you stay organized.

Carrying on with the vehicle price example, how do we best capture usage? We can easily log a usage event on each button, text field, and slider, but what good does that do? What if some of these fields are only available to specific customers? A more organized strategy would be to log events based on an action that isn’t necessarily related to any UI field. “Price Updated”, for example. Anytime we look up the event “Price Updated”, we should be able to find all of the related information. Which field was used to update it, were certain features enabled, were recommended values used or ignored, etc. The latter information is all contained in event parameters.

Once a plan is in place, you’ll begin to notice that every analytics event boils down to two things: An event name, and it’s parameters. Providers have various means of doing this, for example in GA4, Google Analytics deprecated Category, Action, and Label; these are specific event parameters. Screen views? That’s another event where the name could be the screen being viewed.

Close Coordination between Platforms

The next step is having close coordination between platforms to ensure consistent logging. Many stakeholders will first ask “How many people are updating the price?” before they ask “How many do this on mobile?” and even sooner before they ask “How many do this on Android?”. To achieve this, treat everything as case sensitive where alternate spellings would be considered a unique entry. This issue is easy to come across between projects spanning iOS, Android, and Web. To help mitigate this issue on the mobile platforms, the Provision app team recently implemented a shared analytics codebase by using Kotlin Multiplatform for Mobile (KMM). We write our code in a KMM project, then compile it down to a native library for use in our native iOS and Android applications. No more “Hey did you use capital ‘B’ for books or a lowercase ‘b’?” By implementing all strings and by defining the event object in shared code, we eliminated much of the ambiguity from our platform implementation. The only step not handled by our shared codebase is the trigger: ensuring that Android and iOS are triggering the analytics event by the same exact action. This should be very clearly and explicitly defined in grooming sessions.

View Your Data

Lastly, we needed a way to view our logs. Firebase is nice, but didn’t give us the level of granularity and customization we wanted. Google’s Data Studio helped us out with that. All Firebase data is logged in BigQuery and that can be easily imported into Data Studio. Once we have planned out our analytics, we setup a new section or page in Data Studio to start capturing that data. As soon as people start using it, we already have a defined dashboard on how to view it.

Data Studio allows enables custom dashboards to find detailed answers. All of this was logged from one event and various parameters.

This KMM Analytics library is a framework, forcing specific definitions on what can be logged while depending on the app implementation to define how (i.e. Firebase, Amplitude, Mixpanel, etc). It offers up an extremely simple setup that allows for analytics services to be added or changed with very little effort. This is a great way to enter the KMM space as well. Compiling for iOS is not perfect today and this library doesn’t require or ask for any complex functions or threading. What’s more, KMM can also be compiled for Javascript projects. So if your team has ever asked “What’s the stats or usage on the entire product, and not just one platform?”, then having the same analytics framework compiled and shared on all platforms is a great way to answer it.

DISCLOSURE STATEMENT: Opinions are those of the individual author. Unless noted otherwise in this post, Cox Automotive is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners.