title
 

New World for Mobile App Analytics 3: Implementation

, Posted by Phil Craig in Phil Craig, Web Analytics

In part 3 of his four-part New World for Mobile App Analytics series, Phil describes the implementation process, including data layer naming conventions, guides to send to the app developer and an example of GTM tag setup.

Last week I talked about getting on board with the right tool for app analytics, this week we learn to sail the ship, err, use the tool.

Set sail for the New World!

This is where we start to see the big difference in web and app analytics. We have so much freedom for tag management for the web that dealing with apps feels like your anchor has been dropped without anyone telling you.

Basically, all you can do is get to the point where you understand if your app is native, which tool you are going to use and then point the developer in the right direction.

Google’s developer guides are the place to direct them to…

A basic understanding of the IDE (Integrated Development Environment) for both Android and iOS will help you brief the chaps.

As I’ve said, it’s a whole new ball game if you are only used to web implementations.

Disclaimer: you will end up with a hundred tabs open when you start reading these.

Create your data layer naming convention

This is the part where you earn your stripes.

There is no real difference between app and web data layers.

For apps, it is more in line with the dataLayer.push events. As you know, you have your event name and your variable name and value, e.g. event name of “openScreen,” variable name of “screenName” and a variable value of “home page” or whatever page has opened. So, every event in the app will rely on some form of dataLayer event.

Unlike the web, we can’t just set an “all page” trigger and sit back and relax. Working with the KPIs for the app and tracking requirements from the stakeholder, you will need to make a data layer naming convention and guide to send to your app developers.

A few examples of what might need to be tracked and how I would structure a guide:

When to pass value Event name Variable name Value
On every screen open screenOpen screenName The name of the screen
On video play videoPlay videoName The name of the video
videoType “Long” or “Short”
On video pause videoPause videoName The name of the video
videoType “Long” or “Short”
On video complete videoComplete videoName The name of the video
videoType “Long” or “Short”

The main one to be concerned with is the “screenOpen” event, which is like our “all page” trigger effectively. If you’ve ever had to work with single page web applications, this thought process is very similar. Every time a new screen opens, this data layer push needs to occur or we won’t get any screen level data.

There is no real difference between this and any other data layer document you may have done for a website.

Set up GTM

As part of the implementation process you will have to send the correct GTM container details to your developer. It’s a very similar process to the web version during initial setup.

There is a slightly different process in terms of downloading files instead of using a JavaScript snippet, so I would educate your developer where to find the file and make sure they have access to the containers they need.

From our perspective, the setting up of tags is basically no different. Depending on whether or not you are using Firebase or legacy GTM, it doesn’t make too much difference. The interface is the same regardless of web or app implementation, apart from a few differences in tag types.

Let’s create a screen view tag that is sending data to Google Analytics, just as a quick example, to give you a feel for it:

1. Log in to the correct GTM container

2. Go to variables and create a new ‘user-defined variable’

3. This is where Firebase and legacy GTM differ slightly. With legacy GTM you will configure your variable as a ‘Data Layer Variable’ but with Firebase you will configure it as an ‘Event Parameter’

4. This is where your data layer events and variable come in. Add ‘screenName’ to the ‘data layer variable name’ field if using legacy and use the ‘custom parameter’ and ‘event parameter key’ if you are using Firebase. Be sure to use the same formatting you sent the developers, or it won’t work. You’d be surprised how often a simple error can cause huge errors

Variable configuration Leagcy

Legacy

Firebase

5. Go to triggers and create a custom trigger. That’s the default. You will then need to define this trigger to only work on screenOpen events. Like so:

6. Go to the tag section and create a new tag. Choose Universal Analytics, from tag type:

7. Get your tracking ID from your GA account. If you have not set this up already, you’ll have to go to GA’s admin and do this.

8. Select ‘App View’ (legacy) or ‘Screen View’ (Firebase) as the track type

9. Now we use the data layer variable and trigger we set up. Go to the ‘More Settings’ section and create a new ‘Fields to Set’ field and name it like so:

This will set the screenname that has been assigned every time the tag has fired.

10. Now select the trigger you created earlier. Save and you’re ready to go! You have landed in the New World of mobile app analytics!

Next week, I will describe the debugging and testing process, as well as summarising our findings.