# Mobile Analytics — Part 1: The step by step guide.

- Link: https://phiture.com/mobilegrowthstack/mobile-analytics-part-1-the-step-by-step-guide-62f13ff2ebd3/
- Published: 2019-09-12T12:55:54+01:00
- Author: Kevin Bravo

⌊Mobile Analytics — Part 1- The step by step guide⌉⌊Mobile Analytics — Part 1- The
step by step guide⌉

_You’ll need to be prepared for this Journey._

I’ve had a lot of fun working on mobile apps for the past 4 years, from marketing
to data analysis, through to actual app development in SWIFT.

Working for startups to big brands, I learned how the company size changes many 
things about the way you handle each part of the [Triforce spectrum (marketing, tech & data).](https://mobilegrowthstack.com/the-mobile-triforce-marketing-tech-and-data-c889f68c6f73)
However, one thing I found common within every single company I had the opportunity
to work with is **tracking;** how having a structured, clean and thorough tracking
plan (i.e. taxonomy) makes all the difference.

A tracking plan can help tech teams to understand what is wrong in the product, 
data analysts to understand clusters and patterns between users, and marketing teams(
in Growth, UA and CRM teams) to **drive greater impact on acquisition, retention,
and monetization downstream metrics.**

So, what is the secret? What makes a good taxonomy document and how can you leverage
it to define hypotheses and run data-driven experiments that are successful?

I’ve been on both sides: as a marketer using the tracking plan, and as a developer
actually integrating the events in the code. I created a decent method that I have
applied for many different clients, and thanks to my great colleagues at Phiture,
especially **Alex Gorius**, we made it awesome — here it is.

### **1) Starting out: What are your goals?**

When launching a new app, you should spend time defining what you are trying to 
achieve.

Quoting [Simon Sinek](https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action?language=en)
here, you should first ask yourself “why?”

This question will help you understand what your analysis goals are.

**Here is an example:** let’s say you’re a dating app.

Why do you exist? To help people meet.

Helping people meet is your endgame. As this is your endgame, your goal is to get
people to date -> so first discuss in the app -> match -> swipe.

Here, you’ll want to look at how much time people spend swiping, how many matches
they have, and how many conversations they start.

Tracking these events will help every team:

 * **Marketing**: What is the ratio between match and conversation started? Should
   you focus more on getting users to swipe or to continue started conversations?
 * **Data**: Too many left swipes may indicate a problem in the matching algorithm.
 * **Tech**: Too many “**no replies”** may indicate a problem filtering active users(
   instead of showing old accounts) and will impact retention.

Sure, tracking real-life dates is not possible. But you may be able to proxy it 
with user surveys and logging an event when a user shares a phone number (detecting
10 digits in messages).

### **2) Tooling: How to achieve your goals**

Selecting the adapted tracking tooling is one thing. Being able to build a good 
tech stack is something else. If you want to hear my take on [how to build a good tech stack and how it can be leveraged by your teams, click here](https://mobilegrowthstack.com/the-mobile-triforce-marketing-tech-and-data-c889f68c6f73).

Each tool has its strengths and weaknesses, but I often advise going for [Amplitude](https://amplitude.com/)
or [Mixpanel](https://mixpanel.com/) for Analytics tracking and [Braze](https://braze.com/),
[Leanplum](http://leanplum.com/) or [Clevertap](https://clevertap.com/) for CRM.
This is just my personal take, from years of experience with the tools.

Depending on your vertical & goals, you may want to go for a different solution.
I advise going for a tool demo and trying to understand** how the** **tool’s clients
are currently leveraging the data in your vertical**. For example, E-commerce is
completely different from a casual game and may require different features (such
as needing to look at Revenue within the Analytics tool or needing UA Data piped
directly from your Mobile Measurement Partner to your dashboards).

**Should I use a CDP (Customer Data Platform) / Multiplexer? (e.g.: **[**SnowPlow**](https://snowplowanalytics.com/)**/**
[**Segment**](https://segment.com/)** / **[**mParticle**](https://www.mparticle.com/)**)**

CDPs are platforms that create a persistent, unified customer database that is accessible
to other systems. Data can be pulled from multiple sources, cleaned then structured
around a single customer profile. This structured data is then made available to
other marketing systems.

CDPs are great, but they’re not for everyone.

For a CDP to make sense, you need to have multiple data sources that you want to
gather in the same location and want to cross-reference to build relevant dashboards.
For example, if you’re trying to pipe Intercom data to a warehouse, while also receiving
analytics events from web & mobile products for further SQL analysis, then you may
want to consider a CDP.

CDP also makes it easier to integrate new tools to your tech stack by providing “
lightweight” installation and server-side integration.

### **3) Taxonomy: The magic spreadsheet**

⌊Phiture taxonomy guide⌉⌊Phiture taxonomy guide⌉

_Our taxonomy template, the only document developers, analysts, and marketers agree
on!_

Many analytics tools recommend a template document to track events. It’s often a
good start and will need some adjustments based on your app. Above is a screenshot
of Phiture’s version that we recommend to our clients.

#### **_Get a copy of the taxonomy spreadsheet _**󠀁[**_here_**](https://phiture.com/taxonomy-spreadsheet/?utm_source=medium&utm_medium=mobile-analytics&utm_campaign=taxonomy)󠁿**_._**

Our Taxonomy document is split into the following tabs:

 * **Events, Event properties & Screens**: Basically all the actions the user can
   take, and the screens the user can see in the app.
 * **User Attributes**: All user-level data that is updated through the lifecycle.
   This includes anything from email address to subscription status to user acquisition
   source.
 * **Deeplinks (optional)**: This is our preference at Phiture. We like to keep 
   all the deep links schemes in the same document as the taxonomy, but some companies
   may want to keep schemes in a tool like [Confluence](https://www.atlassian.com/software/confluence).
 * **Integration Sprints (optional)**: Being able to provide new data points you
   want to track with details around the trigger, the use cases, etc. is a great
   approach to cross-team collaboration. In doing so, marketers can request specific
   data points and developers can define a product sprint they’ll include these 
   in. In order to work, integration sprints need real involvement from the different
   stakeholders.

In summary, **this taxonomy document will help you maintain a good overview of everything
you’re currently tracking and the state of each data point,** **type of event, etc.**

It’s **critical** **to keep this document up to date** as it will serve not only
as a reference for your integration team/developers to update the product but also
as a tool for your marketing & data analysis team to understand what events they
need to look at every stage. It will also help teams be aware of different discrepancies
that happened in the past which may skew some reports they want to create.

When I’m talking about **data points**, this includes **every action the user is
going to take that is going to be tracked and any information you may want to save
about the user.**

You can split the data points into the following:

 * **App Screens (= events)**: The action of seeing a specific screen within your
   app (e.g. seeing the first screen of the onboarding flow). This is mostly used
   to track funnels (e.g. purchase funnel, content creation or onboarding)

⌊Freeletics onboarding can be tracked with App Screens to detect drop-offs⌉⌊Freeletics
onboarding can be tracked with App Screens to detect drop-offs⌉

_E.g.: Freeletics onboarding can be tracked with App Screens to detect drop-offs._

 * **People updates/user attributes**: For example, if your user changed their rank
   and unlocked the premium version. User attributes are for anything that relates
   to a permanent change/update to your user data.

⌊A user-level view with different attributes (Amplitude)⌉⌊A user-level view with
different attributes (Amplitude)⌉

_A user-level view with different attributes ([Amplitude](https://amplitude.com/))_

 * **Actions / Events**: All the actions the user can take within your app (e.g.
   order a cab, like a post, etc.). This will allow you to measure feature(s) adoption,
   complex funnels, etc.

⌊An event flow example for a streaming app (Amplitude) ⌉⌊An event flow example for
a streaming app (Amplitude) ⌉

_An event flow example for a streaming app ([Amplitude](http://amplitude.com/))_

Our version of the tracking plan is somewhat inspired by [Mixpanel](https://mixpanel.com/)’
s & [Amplitude](https://amplitude.com/)’s templates, though we added a couple of
columns that we find useful:

 * **Example:** A sample example of a data point
 * **State iOS / State Android + Update Date**: Allows you to understand what platforms
   are supported by a data point and when it was last tested (or integrated) so 
   you know how far you can look back for analysis purposes
 * **Server-side event: **Allows you to understand if the event is triggered by 
   the product or the server. This is helpful for two reasons: We won’t track server-
   side events as an activity by the user and some types of CRM campaigns can’t 
   be triggered by a server-side event (in-apps mostly).
 * **Tools supported**: You won’t be tracking every data point for every tool you
   use. This helps you understand which data points are available in each of your
   tools (CRM, Analytics, Attribution Provider).
 * **Old Naming & Discrepancies**: When looking back at data, often you might find
   yourself looking at an event that has been obsolete for 3 months. Having a single
   source of truth helps to clarify what events you should look at for each action
   the user is taking and saving previous event naming conventions and any discrepancies(
   can be related to a new update, tool crash, etc.) is a good way to make sure 
   you’re aware of every issue that could impact your analysis.

### **Naming Convention 101**

⌊The main approach recommended by Segment ⌉⌊The main approach recommended by Segment⌉

_The main approach recommended by [Segment](https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/)_

Before thinking about crafting a tracking plan, you should define your **naming 
convention**, which is **the way you’ll write each event in the plan, as well as
in the code.**

Having a clear, consistent naming convention will make your taxonomy document **
the single source of truth **on how each event is named and appears in your different
tools.

I won’t write on this as[ Segment already did with this post on their blog](https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/).
It’s the best material on the topic. It highlights best practices and gives you 
a good process to define your own naming convention.

### **Analytics vs CRM: Understand what to track**

The first thing you may want to define is what to track: should you be exhaustive
in the way you approach data tracking, or should you limit it to the main funnels&
actions you’re interested in looking at?

**Tracking costs money. **Most of the analytics tools have a cap on the number of
data points you can send to them. Also, when looking at advanced CRM tools such 
as Leanplum, Braze, and Clevertap, they also charge based on the number of data 
points you’re tracking.

This is why you need to be careful about each data point you decide to track and
make sure you’re not tracking useless data.

Here I give our approach to define what you should track within your product. I 
advise adjusting the approach based on your needs, however, this will give you a
good high-level strategy.

**You should ask yourself all these questions for both new and already integrated
data points.**

**If, after asking these questions, you don’t find at least one use case for each
data point, you should not consider integrating the data.**

### **🥇6 good reasons to track a new data point🥇**

 1. Is this data point is valuable on the company level? (Company KPI’s)
 2. What analysis are you trying to achieve by tracking this specific data point? (
    Funnel analysis/testing feature adoption etc.)
 3. Is there a specific campaign that you can trigger based on this data point? (e.
    g. you may want to show an in-app in the profile page to prompt the user to add
    their email or you may want to send a win-back campaign for users who start the
    purchase funnel but never finish buying the subscription).
 4. Is there a specific segmentation that is not possible without this data point? (
    e.g. you may want to educate users on a specific feature in the app if they have
    never used it before)
 5. Do you need a specific conversion event to evaluate the success of a campaign? (
    e.g. from users receiving an email, how many actually purchased a premium account)
 6. Does this data point enable copy personalization for relevant CRM campaigns? (e.
    g. most ordered type of food for a delivery app)

### **Understanding event properties**

⌊Event properties add contextual information about an action ⌉⌊Event properties 
add contextual information about an action ⌉

_Event properties add contextual information about an action_

When tracking events (actions), you can also track data within specific events (
event properties). An event property is a variable attached to an event that will
give you additional information regarding a specific action the user is taking.

For example, if the user triggers the event **Play Song, **you won’t get much information
with this alone. You may also want to look at statistics based on the most played
genre for example.

For this, we can add the following event properties:

 * **artist**: song’s artist
 * **duration**: how long the user listened to the song
 * **name**: song’s name
 * **category: **style (country, folk, hip hop, etc.)

In some contexts, you may want to add advanced event properties such as:

 * **fullListen**: Did the user play the full song? Duration won’t be enough as 
   each song has a different length.
 * **mode**: If your app has a background mode, you may want to know if the user
   listened to a song with it, or if they remained in the UI.

Again, these examples may be valuable in specific cases. **Don’t consider them necessary
until you can define why**.

### **Understanding User attributes**

⌊User attributes give an opportunity to segment users easily ⌉⌊User attributes give
an opportunity to segment users easily ⌉

_User attributes give an opportunity to segment users easily_

There are also variables that can be attached to a user (e.g. gender, city, accountType,
etc.). The difference between event properties and user attributes is that you can
access user attributes anytime, but **the value available will be the latest one**.,
whereas** the value of an event property can change each time the user takes an 
action.**

Be careful with sensitive data. Date of birth, name and first name are rarely useful
in data analysis but may be valuable for CRM experiments with copy personalization,
so you may consider tracking these data points only in your CRM tool.

After you think about basic user attributes, you can also consider some more advanced
data points:

 * **numberOfSongsPlayed:** How many songs has the user played since their first
   install? This can help you build data summary emails.
 * **accountType:** Is your user a premium user?
 * **numberOfAlbumsCreated**: How many albums has the user created?

User attributes are often more useful to do segmentation in analytics tools, instead
of focusing on event-level data. Attributes can also help to build advanced cohorts.

### **A/B Test Variables: Should they be included in the Taxonomy?**

If you’re planning on running multiple A/B tests on the product side, you may want
to define variables in the taxonomy. This will make it easier for every team to 
know what aspects of the app they can tweak without any app update.

A/B test variables are set up on the product side, and can usually be changed for
a specific segment of users from a server app. This can be achieved within a custom
setup or by using a tool such as [Apptimize](https://apptimize.com/) or [Firebase](https://firebase.com/).
Also, some CRM tools like [Leanplum](http://leanplum.com/) allow you to do it.

Even if the biggest use cases will be games where you can combine CRM efforts with
game economy tweaks, onboarding adjustments or purchase funnel optimization, it 
still makes sense for apps where you may consider tweaking prices for some segments
of users, changing the onboarding messaging or even making new features available
for a specific segment (with a CRM approach, educating users on it).

If you decide to integrate variables in your taxonomy, there should be an extra 
tab that will include the variable, the app version where it’s available, the default
value and the different features/aspects of the app involved.

### **Understanding & helping your developers**

Once the tracking plan is drafted, you will need to discuss it with your engineers
to understand what is feasible and what is not, based on the app structure.

In your mind everything will look “fairly easy”, but I’ve been on the tech side,
and some data points are hard to track. It’s important to get developers involved
in the process to make sure you spot issues early.

### **How can you help your developers with tests?**

It’s laborious work, but once a new app version is released, you may want to test
the different new data points that have been integrated in the app.

If you’re working in the CRM team, there are some things you may consider testing
for new data points:

 * When is each event triggered?
 * Is it a server-side event?
 * Are event properties correctly populated? (with actual values and not default
   values)
 * Is there any new user with a specific user attribute that has an empty value?(
   e.g. even after location is prompted, you may have some users that have a null
   location).

### **Something I wish I had known when I first implemented tracking**

Your developers will probably have a specific approach to data tracking. It makes
total sense to listen to them.

From my experience, I’ll just highlight the fact that **you’ll change more than 
once the tools you’re using to track and send events to the Analytics, Attribution
Providers (also called Mobile Measurement Partners — MMP) & CRM tools.**

That’s why I highly recommend using a **generic class that handles all the tracking
for you**. This means that you won’t tag each event for a specific SDK, but actually
track it once with your generic class, and let the class distribute the events.

Here is a basic snippet of what it would look like in SWIFT (iOS).

import Amplitude_iOS

import Mixpanel

import FirebaseAnalytics

class AnalyticsHelper {       

static func log(event name: String, properties: [String: Any] = [:]) {

 // Amplitude:       

    Amplitude.instance().logEvent(name, withEventProperties: properties) 

            

 // Mixpanel:       

    MixpanelInstance.track(name, properties: properties)

 //Firebase:       

   Analytics.logEvent(name, parameters: properties)   

}    

[…]

}

This is just one of the functions available in my AnalyticsHelper class.

Let’s say I want to track when a user adds a note to my productivity app:

AnalyticsHelper.log(event:”Add Note”, properties:

[“type”: “personal”, “group”:”My Daily Routine”]

In one single line, I’m actually sending the data to Amplitude, Mixpanel, and Firebase.
🤯

My Analytics Helper also includes other functions to **track screens, user attributes**(
unique or incremental), **identify users **(emails, name, date of birth, etc.), **
set up Unique IDs for signed-in users **(consistent in all tracking tools), **update
subscription status** (push & email / on device level or app level), and so on.

**Every single data point I’m tracking from the product goes through this class,
making it way easier for me to update the tools I send data to or the way I track
any data point.**

### **Conclusion**

Building a good taxonomy document will help your Marketing, Tech & Data teams align
on what is currently tracked and what you should integrate in upcoming sprints.

A first step in leveraging data to drive impact is to actually have a good setup,
and I hope that with this guide you’ll be empowered to drive impact on your core
metrics.

In the second part of this series, I will focus on what happens once you have a 
good taxonomy in place, where everything is tracked correctly and you can run all
the analysis you want. What should you look at? What experiments are worth running?
And how do you define where to focus?

_I want to thank Andy Carvell, Alex Gorius, Tessa Miskell and Martijn Janssen for
their insights 🙂_

Cheers.⚔️🧙‍♂️

![](https://miro.medium.com/max/120/0*ByhJErmVv4IP6rxj)

#### Thanks to Andy Carvell.