Trigger Groups in Google Tag Manager. What’s new in this?

Trigger Group is the new update in Google Tag Manager which is present in trigger type and can be added to tags. This interesting feature allows a tag to match multiple trigger conditions by establishing a grouping among those triggers. This won’t fire the tag until every trigger in the group has fired at least once.

This is a unique feature which you will not find in any other tag manager except Google Tag Manager .

Image result for unique animated quotes

So, let’s get this started….

How to create a Trigger Group?

Fire up the Google Tag Manager, the Trigger Group is present within the trigger workflow. To do so, select Triggers from GTM interface, then New and then Choose a trigger type to begin setup option.

Trigger Configuration interface

You will find Trigger Group in the bottom of “Choose trigger type” option.

“Choose trigger type” option

Click on the Trigger Group and you will see the configuration screen.

Trigger Configuration interface

Here you can add multiple triggers based on your business objective.

Note that each and every trigger that you’re adding to Trigger Groups must fire as many times as it appears in the Trigger Group.

Also you can add a single trigger multiple times, but it should fire as many times as it is added to the group for the Trigger Group to work.

Examples of Trigger Groups

Example 1: PDF downloaded and Emailed us

We have setup this trigger for users who have downloaded the PDF from the site and then emailed us. This will fire up as soon as both the conditions are met.

Image result for examples

Example 2: User engagement check

This tag will enable you to find out the user engagement on your website. The combination of scroll depth and time spent triggers can help you do so.

For example this trigger will fire as soon as the user has scrolled 75% of the page and watched 90 seconds of the YouTube video.

Example 3: Wait for the All Pages trigger to fire first

In this Trigger Group, we have All Pages trigger along with the Event trigger. It signifies that the Event trigger will hold no importance until the All Pages trigger has fired.

Example where this cannot work

This trigger will not work in case of multiple pages. You cannot put multiple triggers on different pages, they have to be present on a single page.

Perhaps this idea will be extended further so that we can actually query the history of Data Layer on any given page. And, wild thought, maybe even persist this information across pages, so that a Trigger Group could fire based on multi-page conditions!

As of now it works only on a single page.

Things to keep in mind

  • Trigger Groups can’t be used as an exception since it can only block from firing is itself.
  • It will fire when all the triggers listed within have fired irrespective of the order, it won’t fire again even if the triggers listed within fire again.
  • Trigger Groups don’t replace the grouped triggers. The triggers you add to the group don’t need to be added to any tag at all – they can exists solely for the sake of Trigger Group itself.

I think now we’re pretty much familiarized with the Trigger Groups and will be able to implement them in our business.

If you need help with this, then we are a crazy team of Google and Adobe Certified Analytics Experts who eat, breathe, sleep and dream Analytics. And we’ve made it our purpose and passion to electrify your business’s potential through Analytics.

Contact us here.

Thank You.

Nary_Max?…What is it & Why it’s important

A blog on Nary_Max!

So, I have a simple question……Why do we use Google DataStudio? (Hint….the answer’s not the fact that its free)

Is it to show data and its different visualizations in a beautiful aesthetic format? Yes

Is it to show data  in a more dynamic and organized way, thus helping in analysis and decision making? Yes

But the basic answer for this question is – Reporting. The google data studio is a reporting platform that lets you collate data from all platforms in which you are investing effort (Well, almost all).

It is important to represent that effort properly to see the current performance of the organization, as well as for efficient future decisions. However, let’s face it, sometimes some data just cannot be represented. It may not exist, it may not be gathered, but for that time period, that data value is just that – A null.

And in data studio, if you are using calculated fields to create another metric, one of your unpredictable problems could be that the data with which you are calculating another metric contains null values. And you definitely cannot show a “null” for your organization’s efforts.

So, the question is, how to translate your null value into a 0 (Zero) when calculating another metric?

For doing that, Nary_Max is your go to function!

Meaning & Example

Basically, this function among n variables, that is, among different rows of data, can pick up the maximum data set. This in itself is a useful application of Nary_Max

But we were discussing on how does it help null values, right?

Let’s take an example to explain that.

In the figure shown below,from data studio, there are 2 fields, that is cost and variable cost. In both the cost and the variable cost data there are null values.

Now, there is a requirement to aggregate these fields into a calculated field called total cost. For more information on calculated fields, you can refer to this blog post here

In the calculated field given above, Nary_Max function is used to differentiate between 2 sets of data and use the higher value. The 2 sets of data in this case mean the actual data and 0.

The entire formula used in the above field is: SUM(NARY_MAX(Cost,0))+SUM(NARY_MAX(Variable cost,0))

Therefore, it will differentiate between the values in both the the fields with o. If there is a null value in any one of the fields, then Nary_Max function will use 0, as it is a higher value than null.

The end result comes like this

The total cost now has 0, if the values involved in both the fields are null.

In this way, the main calculated metrics which are observed by the shareholders are calculated even if they have null values in them.

If you need help with this, then we are a crazy team of Google and Adobe Certified Analytics Experts who eat, breathe, sleep and dream Analytics. And we’ve made it our purpose and passion to electrify your business’s potential through Analytics.

Contact us here.

As I am pretty sure, the above image summarizes itself.

Your one and only web analytics Chica here – Garima Mathur

How to capture scroll depth of web page using Google Tag Manager (GTM)?

In this post I’ll cover one of the recent releases for Google Tag Manager, which is setting trigger based on Scroll Depth. I will also provide step by step explanation on how you can implement various tags based on how deep the users usually navigate through your various web pages

Combining scroll depth trigger with Google Analytics can help you analyse till what point are the users usually interacting with content on your website.

It helps you in making some useful decisions for your web page and increase the user interaction by optimizing the content placement, layout and volume.

So, without wasting much of your time in introduction, let’s look at the steps to set a scroll depth based trigger on GTM:

  1. Click Triggers -> New
  2. Click Trigger configuration and choose scroll depth trigger type.

3. After selecting scroll depth trigger type, you’ll see two scroll depth options:

  • Vertical Scroll Depths
  • Horizontal Scroll Depths

You can select both Vertical and Horizontal scroll depth values in same trigger or any one of them as per your requirements.

After selecting the option, you’re required to set the scroll depth values as either percentage of the page height and width, or as Pixels. You can enter more than one values in both the conditions, but values should be positive integer separated by commas.

For example: 10,20,30, etc.

The “Enable this trigger on”option specifies when this trigger should start listening for relevant interactions. Following are the three options available:

  • Container Load (gtm.js) when the page loads, this one occurs the earliest among the three options
  • DOM Ready (gtm.dom) occurs after DOM is ready to be parsed. 2nd in order
  • Window Load (gtm.load) (default): after all initial content on the page has loaded, it occurs. This is last in order

You can select any one from the options as per your requirement or keep it on default, which is window load, if you aren’t sure which one to use for your web page from the options available.

4. Save the trigger.


Next, lets use the sensational GTM debugger and check in Preview & Debug mode if trigger is firing on set thresholds.


Now, lets setup a Google Analytics tag to record the scroll depth in your Analytics account.

Following are the steps to create a new tag for it and get this information in Google Analytics:

  1. Click Tags -> New
  2. Click Tags configuration and select Universal Analytics tag type.

3. Select track type as “Event”.

4. Following image shows a good way to record the scroll depth. Here I have used category as ‘Scroll Tracking’, Action would report the direction of scroll – horizontal/vertical and finally label would report the threshold value resulting in firing of this tag

5. Set non-interaction hit as true. This will affect your bounce rate calculations. Its up to you whether you wish to consider the scrolling a user interaction on the site or not

6. Select Google analytics settings variable as per your property UA – ID

7. Select the firing trigger for it, which was created earlier – the scroll depth trigger.

8. Save the tag and check in Preview & Debug mode, if tag is firing or not.

9. If tag is firing, you can check in GA under real time events report and check if category and actions values are coming properly as you have set them.

Like this you can set various other tags as well apart from Analytics that can change the user experience based on their scrolling depth, like introducing a pop up form etc

Enjoy coffee.

If you need help with this, then we are a crazy team of Google and Adobe Certified Analytics Experts who eat, breathe, sleep and dream Analytics. And we’ve made it our purpose and passion to electrify your business’s potential through Analytics.

Contact us here.

Found it informative? Leave a comment! You can also give us a thumbs up by sharing it with your community. Also did you know that you can light up our day by subscribing to our blog? Subscribe here –

How to change the font size of axis and data label for charts in Google Data Studio?

In this post you will learn about the recent release in Google Data Studio regarding font size settings of axis and data label of the charts and how you can use it to make your dashboard more aesthetic.

Now you don’t need to put strain on your eyes to see small labels as you can easily change/increase the font size now, all thanks to new release feature of the product.

It will make your dashboards more attractive and can give more value to the elements added to the dashboard.

It is also an important feature as senior management are often particular about the branding of the official content.

Now you’ll further read about how you can change the font size of axis label or data label:

  • Select the chart for which you want to change the font size of axis label or data label
  • Go to the style tab of selected chart
  • See for the “Grid” option under style tab.
  • Now you can see the option to change the font size of axis and
    font size of data label
  • Change it as per your requirement

Enjoy Coffee.

If you need help with this, then we are a crazy team of Google and Adobe Certified Analytics Experts who eat, breathe, sleep and dream Analytics. And we’ve made it our purpose and passion to electrify your business’s potential through Analytics.

Contact us here.

Found it informative? Leave a comment! You can also give us a thumbs up by sharing it with your community. Also did you know that you can light up our day by subscribing to our blog? Subscribe here –

Market Basket Analysis With Google Analytics Data

Market Basket Analysis with Google Analytics Data is one fusions of Digital Analytics and Machine Learning

The data is easily available and it is fairly easy to clean.

In this post I will share steps to present steps on how to do that.

I am starting first with the code and its logic. And later I have briefly covered some theory.

First, getting the data

You can get the Google Analytics data into R by using the googleAnalyticsR package. Grateful to Mark Edmondson and team for creating this.

http://code.markedmondson.me/googleAnalyticsR/

https://code.markedmondson.me/googleAuthR/articles/google-authentication-types.html

// if package not already installed then install it 
if(!(require(googleAnalyticsR)))install.packages("googleAnalyticsR") if(!(require(googleAuthR)))install.packages("googleAuthR")

//load the functions of the package
library(googleAnalyticsR)
library(googleAuthR)

//Login with Google to grant approval to R to access your GA data ga_auth(new_user=T)

//you can replace the above with new_user=F after initial //authentication
//Get the account data structure - Accounts>Properties>Views
my_accounts<-ga_account_list()

Now, in Market Basket Analysis we essentially want to discover how purchase of a set of items affects the purchase of other set of items

For this we need data presenting information on items bought together in various transactions

We will use “ga:productName” and “ga:transactionId” as dimensions to get the products purchased and their respective transaction IDs

We will use “ga:uniquePurchases” as the metric

You also need to provide a date range for this data in “YYYY-MM-DD” format

You need to provide the viewId which you can get from the account structure which we got using the ga_account_list() function above

//provide the view ID from the account structure above 
//ViewId="UA-XXXXXXXX"
//provide the start and end data Start="2018-12-01" End="2018-12-31"

Table <- google_analytics(ViewId,date_range = c(Start,End),metrics = c("ga:uniquePurchases"),dimensions = c("ga:productName","ga:transactionId"))

//Remove the entries without product Name
Table<-Table[Table$productName!="(not set)",]

//Remove the entries without any purchases
Table<-Table[Table$uniquePurchases!=0,]

//Remove any possible duplicates
Table<-unique(Table)

//Replace unique purchase with 1, we just want the presence of product //in a transaction, we do not want its volume
Table$uniquePurchases<-1

The present structure of the Table is something like this :

But to perform the Market Basket Analysis using Arules we need the structure to be like this :

The transaction Ids along the rows and each product name along the columns. For this we will use the reshape2 package created by the legendary Hadley Wickham

if(!(require(reshape2)))install.packages("reshape2") 
library(reshape2)

//Creating a new data frame with the above logic
dcast<-reshape2::dcast(Table,transactionId~productName)

// Replacing Na values with 0
dcast[is.na(dcast)]<-0

//Creating a duplicate to take row names
dcast1<-dcast

//The apriori function accepts only product entries the transaction..
//..Ids can't be in rows and need to be passed as rownames instead dcast1$transactionId<-NULL
rownames(dcast1)<-dcast$transactionId

//Free up some RAM
rm(dcast,Table)

//The Input to the apriori function needs to be of //datatype"transactions"

dcast1<-as.matrix(dcast1)
dcast1<-as(dcast1,"transactions")

Now our dataset is ready, we just need to input that to the apriori function from the Arules package. The package has been created by Michael Hahsler and team

if(!(require(arules)))install.packages("arules")
library(arules)

//the choice of support and confidence 'll depend of domain knowledge..
//..and business objective
rules = apriori(dcast1, parameter=list(support=0.007, confidence=0.25));

//To view the results in Data Table format you can convert the above
Table1<-DATAFRAME((rules))

//Convert the Support and confidence columns to %
// We will need scales package for this again by Hadley Wickham

Table1$support<-percent(Table1$support)
Table1$confidence<-percent(Table1$confidence)
Table1$lift<-round(Table1$lift,2)

Now, lets look at the result:

We have three terms support, confidence and lift. Lets understand each with the smart art below:

The above presents results for chances of purchase of Milk if Bananas are bought. In general, the you will read the results as chances of purchase of items on Right hand side if items on left hand side are purchased.

I personally like this solution a lot as the data is relatively easily available because of Google Analytics.

It presents quick insights on which items can be clubbed together as bundle.

Which items can be suggested at order confirmation page or through post purchase campaigns.

Which items can be suggested as add on in the purchase journey.

You can get as creative as you want.

Contact us here.

Found it informative? Leave a comment! You can also give us a thumbs up by sharing it with your community. Also did you know that you can light up our day by subscribing to our blog? Subscribe here –

How to enhance Google Adwords and Analytics Integration

Google Adwords and Analytics Integration- What is the objective of the blog post –

In this post you will learn how to customize your Google Adwords and Analytics Integration to link your campaign information to other areas of your site apart from landing page and conversion.

How it makes life easier –

With standard integration, one can analyse the performance of Adwords campaign along with the landing URL in terms of cost, conversion and revenue. But, what if you have other variables in the user journey that you are testing apart from the lander?

By using this customization technique you will be able to analyze how combination of your adword campaigns and other areas of your site are affecting the conversion and analyze the complete picture.

Real life scenario –

Suppose an eCommerce company is using Google Optimize to test its landing pages as well as product details pages.

The company want to see which adwords groups, lander and product page combinations are delivering the best results in terms of order conversions.

For this they create a google sheets dashboard to automate the report for analysis through the Google Analytics Addon like this :

Now, with standard integration the company will not be able to see this entire journey and will miss out on some critical information and they will rather see this ugly error:

But, they don’t need to lose hope. DataVinci to rescue. Lets get cracking.

What is the recipe?

Ingredients:
  • 2 custom dimensions sanctioned at session scope (There can be more dimensions depending on the number of variables you are playing with)
  • Custom parameters in landing URL of Google Adwords campaign
  • 3rd Custom dimension to capture the Google Adwords custom parameter. Again, set at session scope
Method:

First, enable the custom dimensions from the Google Analytics admin. Name them appropriately and note down their index numbers. Make sure to set their scope at session level.

Next, customize your Google Adwords campaign parameters by passing in any campaign related information that you want to test. Let’s assume this information is ad group and you are passing this in “_adgroup” parameter.

This video tutorial provides the steps to update the custom parameters in Google Adwords :

Now, customize your Google Analytics implementation to capture the data in the respective dimensions.

This video tutorial provides steps to setup Google Analytics custom dimensions through Google Tag Manager.

https://www.youtube.com/watch?v=so3_bKY0mnM

Now what?

Ok, so when you set a custom dimension to a session scope, the last value that gets passed into it in a session gets associated with all the hits of that session. So, visualize this scenario in your head:

A visitor enters your site from your Google Adwords campaign. You have very smartly passed in custom information through custom url parameters in your landing URL. Your Google Analytics account captures this custom parameter information and stores it in a custom dimension, and since this custom dimension is set at a session scope, all the hits in your visitors sessions can be viewed against this value.

Also, on this landing page, we are capturing the landing URL in another custom dimension set at session scope. That means this information will also be available to be used with other data points captured through out the session.

Next, if the user navigates to the products page, we are capturing the version of the product page url as well and that too again in the session scope.

Now we have the three important dimensions which we want to see together broken down by the conversion metrics to make a decision. And this is how the report will look now:

Through the above minimal setup, the eCommerce company can clearly analyze which combinations are working better than others and push them to the broader audience.

Sweet.

Hope you liked this post on customizing your Google Adwords and Analytics Integration

How can we people?

Google Analytics is a very powerful tool when setup correctly. It can be customized to great extents and provide sensational insights to optimize your digital assets.

If you need help with this, then we are a crazy team of Google and Adobe Certified Analytics Experts who eat, breathe, sleep and dream Analytics. And we’ve made it our purpose and passion to electrify your business’s potential through Analytics.

Contact us here.

Found it informative? Leave a comment! You can also give us a thumbs up by sharing it with your community. Also did you know that you can light up our day by subscribing to our blog? Subscribe here –

Analytics with React-Redux SPAs and Google Tag Manager

React-Redux has become a hugely popular web development combo, but there aren’t too many guides out there on how to sprinkle in analytics. Most implementations require some modification to your app’s code, often with analytics specific business logic.

The most common pattern seems to be with redux middleware, which definitely is a step in the right direction. The redux-analytics package encompasses this pattern nicely. Every redux action becomes a place where insights can be extracted, simply by appending some analytics information to the action metadata.

const action = {
  type: 'MY_ACTION',
  meta: {
    analytics: {
      type: 'my-analytics-event',
      payload: {
        some: 'data',
        more: 'stuff'
      }
    }
  }
};

This is a great start, and I had many of these analytics payloads throughout the codebase for a while and it worked great. The problem was that whenever someone wanted to change pretty much anything, it required a redeployment. Plus you’ll often have less tech savvy users wanting to add their own insights.

We already had an integration with Google Tag Manager (gtm.js), so I was a little biased towards this implementation. This goes two-fold for other departments who were already familiar with gtm.js, which is currently reaping it’s benefits with less development overhead when adding analytics insights.

Anyway lets get started on a basic Redux integration with gtm.js and my personal analytics platform of choice — Mixpanel.


Getting Started

If you’re not already familiar with gtm.js, you can simply inject it’s javascript snippet into your app then get going. All of the configuration is driven through the gtm web UI, which has come a long way in the years.

Now on the app side, the Redux middleware approach is still the way to go here:

const analytics = () => next => action => {
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({
    event: action.type,
    payload: action.payload
  });
  return next(action);
};
// Add in the analytics middleware
let store = createStore(
  todoApp,
  applyMiddleware(
    analytics,
    thunk,
  )
);

Instead of dispatching analytics events from the application, it’s now firing everything to the gtm.js dataLayer. Each dataLayer event needs an event attribute to denote the type of event, but other than that you can structure your data format in any way that suits your application.

Now that’s pretty much it for the initial setup, assuming you already have the gtm.js snippet embedded in your application somewhere. Everything else can now be driven by the Tag Manager UI. I’ve started storing tags/triggers/variables in their own respective folders, but these can be changed at any time.


Creating the first event

To get started, lets setup the beloved page load events that management always seems to want. A typical React SPA usually has some form of client-side routing, so there needs to be a method to track the initial page view (landing) and route transitions. To capture both of these, 2 triggers are required.

Create the trigger in some folder of your choice

First, create the tag for the page load. I used the window loaded trigger here, and named it Global.pageLoad for use later.

Create the first pageLoad event

Next, create the history change event, which will capture route transitions from your SPA router (e.g. react-router). This is similar to the Window Loadedevent above, but the History Change trigger can be selected instead.

Create a new tag Page View that triggers on either of these. I’ll be using Mixpanel throughout, but the same can apply to Google Analytics or your platform of choice.


Tracking authentication

The place where Mixpanel shines is tracking arbitrary events, with arbitrary (and sometimes changing) event attributes. This is the perfect behavior for a dynamic web application, and especially for the range of redux events that are fired.

In many applications, there’ll be some kind of authentication event fired. In my current app it’s structured as follows:

const authenticateAction = {
  type: 'AUTHENTICATE',
  payload: {
    user,
    token
  }
}

1. Create the trigger

This event is now available to use in Tag Manager as a custom event. Create a new trigger referencing this authenticate action:

The Event name should match the string type field in the redux action

2. Access the data

To access variables within your redux events, you need to create a Tag Manager variable for each primitive you want to access. Unfortunately there is no object dot notation access (yet).

Access the user id variable within the redux action

3. Send the analytics event

The complete authentication tag

Now that we have the trigger, and the data, we can send an analytics event. For user identity, this often varies per analytics-platform.

Create a new tag that uses the previous AUTHENTICATE event, along with the User.id variable. Inside a Custom HTML tag, the variable can be accessed using the {{VARIABLE}} notation.

Conclusion

That’s all there is to it to get started, now try login to your application and you’ll see the identification action get triggered and sent to your analytics. Now your analytics platform can grow as your application grows, without littering the code base with metadata tags.

It’s just as easy to add other actions and variables, and create triggers that fire conditionally based on the value of a variable — all within Tag Manager.

 Hope you liked this post.
You may subscribe to us for more good content for Free.
Best,

Non-Interaction Events in Google Analytics

So what are Non-Interaction Events in Google Analytics?

You already know about event tracking in Google Analytics and using it for everything from downloads to video plays. Maybe you’re using jQuery or Google Tag Manager to capture events.

One thing to note about events is that, by default, events affect the bounce rate. That is, if a user lands on a page and an event is triggered, they are not a bounce (even if they don’t view any subsequent pages). In many cases, that’s what you want: after all, if someone engages with the page in some way, you probably don’t want to count them as a bounce any more.

However, you have control over whether those events affect bounce rate. There’s a parameter you can send with the event data to decide this called the “non-interaction” parameter. In a case where a video auto-plays when someone lands on the page, for example, we might want to set the non-interaction parameter so that the bounce rate of that page isn’t zero.

Flagging Non-Interaction Events

The code for a non-interaction event is just a single parameter you set along with the event data.

For Classic GA:

For Universal Analytics:

Using Google Tag Manager:

Screen Shot 2014-05-05 at 8.14.21 AM

Effect on Metrics

Screen Shot 2014-05-01 at 1.03.19 PMNon-interaction events are mostly referenced in regard to bounce rate, but they actually affect several metrics. Setting the non-interaction parameter has the following effects:

  • Bounce rate and time metrics (session duration and time on page) are no longer affected by the event.
  • The number of total events, unique events, sessions, users, etc. are counted normally.

Give us a shout if you need any help with  Analytics by filling in the form below

Check out our Google Analytics solutions here

Check out our Adobe Analytics solutions here

FireBase Analytics Vs Google Analytics

Why FireBase Analytics ?

Because FireBase Analytics was created exclusively for apps.

There is a reason why a lot of app development companies invest on creating in-house analytical tools rather use vendor solutions.

Most digital analytical tools including Google Analytics were created in a “pre-mobile app” era. A majority still cater primarily to website architectures. Mobile applications differ greatly from websites. Websites are click based.

Other than forms where the text is typed, a click is supposed to change the page being viewed. Events like video view or document download are afterthoughts to the basic page based architecture. Apps, on the other hand, have several elements and types of interactions over one or multiple screens. Also, users can call various action by touching, swiping, pinch-in, pinch-out using multiple fingers in various ways. Users can thus interact with various elements that trigger content without changing the screen they are in.

There are many apps out there whose interface is just a single screen. The traditional page of websites does not exist. Also, Firebase analytics has solved a big question Google Analytics is still struggling How to uniquely identify a user who may access the page from multiple devices/browsers/time gaps? For mobile apps, there is no need to force yourself to the website language of Google Analytics.

Your analytics tool has to adapt to your business reality and not the other way around. Pure play app creators need a tool that understands users and events. Firebase Analytics is that solution.

Free unlimited event reporting in Firebase Analytics unlike Google Analytics

Another consequence of the page and session based tools like Google Analytics is that events are an afterthought for them. Thus there are limits to which one can go while analyzing events. Even paid solutions like Google Analytics premium have a limit on how many events you can report and analyze. Firebase, however, provides you with unlimited reporting for up to 500 distinct events.

Did we mention that Firebase is also free?

Funnel analysis makes much more sense in Firebase Analytics than in Google Analytics

The traditional page flow analysis involves analyzing sequence of pages visited in a session prior to the desired outcome. This is not useful. This is because visitors don’t “follow” the path that we want them to follow.

The correct way to analyze user behavior flow is to identify the critical actions taken at every step of the conversion process. Since Firebase is based on events and not on screen views, it allows you to create funnels based on events which give much more value than the page-view based funnels Google Analytics has.

You can connect Firebase Analytics to Google Analytics

Imagine tomorrow your organization decides to use websites in addition to the apps. Alternatively, let us say you still have stakeholders who understand only the language of Google Analytics. Firebase has a tight integration with Google Analytics. Connect your Firebase data to Google Analytics and see your Firebase analytics reports without leaving the Google Analytics user interface.

Unlike Google Analytics, Firebase Analytics is much more than an app analytics tool

Firstly, Firebase is a mobile and web application platform. Its original product was a real time database. Along with the famous Firebase Analytics, it also has services and infrastructure designed to help developers build high-quality apps.

Firebase features can be mix-and-matched by developers to fit their needs. After Firebase was acquired by Google in October 2014, it has expanded to become a full suite for app development with many Google products like Admob also integrated into it. You can take a look at what Firebase has apart from Analytics here. Firebase as a backend service is one of the fast growing businesses in the Android market.

Unlike Google Analytics, Audiences can be used through the rest of the Firebase Analytics platform

Firebase audiences are like segments in Google Analytics. Additionally, Firebase enables audience-specific push notifications and app configuration changes to be sent out without having to collate that information separately. You can identify custom audiences in the Firebase console based on device data, custom events, or user properties. These audiences can be used with any of the other Firebase features mentioned above.

By investing in Firebase, you will be investing in many more tools from Google that helps in app development and monetization. With the purchase of Fabricdeveloper platform from Twitter last month, Firebase has again come to the spotlight. Fabric’s reach of 580,000 developers will grow the user base of Firebase. If your digital strategy is app-driven, Firebase is the right analytics tool for you.

You might like this video on Firebase :

Give us a shout if you need any help with mobile App Analytics by filling in the form below

Check out our Google Analytics solutions here

Check out our Adobe Analytics solutions here

Google Tag Manager (GTM) for mobile apps

Google Tag Manager (GTM) for Mobile Apps was first announced in August this year and has some great implications for app developers.

Perhaps most notably, the product has the potential to overcome one of the most critical challenges in the business: pushing updates to the user base without having to publish a new version on the app marketplace.

Typically, from the moment an app is shipped it is frozen, and from that point onwards the developer can only make changes to how the app behaves if the user accepts an update. By shipping an app with GTM implemented, configurations and values may be continuously updated by publishing new container versions through the web-based GTM interface.

In this post, we will cover how to get started with GTM for mobile apps and how to implement Universal Analytics tags using the GTM SDK for Android. As a heads up, this will occasionally get pretty technical, however I believe it is important to understand the product from its fundamentals.

Initial Set Up

Before we get started, some initial configuration steps need to be completed. More detailed instructions on these are available in the Google Developers Getting Started guide, but in a nutshell they include:

  • Downloading and adding the GTM library to our app project
  • Ensuring our app can access the internet and the network state
  • Adding a Default container to our app project

We will hold back on that last part, adding a Default container, until we have created some basic tags and are ready to publish. We will revisit the Default container later in this post.

Create an App Container

We need to start off by creating a new container in Google Tag Manager and select Mobile Apps as the type. Typically, we will have one container for each app we manage, where the container name is descriptive of the app itself (e.g. “Scrabble App”). Take note of the container ID on top of the interface (in the format “GTM-XXXX”) as we will need it later in our implementation.

App container for mobile app

Opening a Container

Assuming we have completed the basic steps of adding the Google Tag Manager library to our project, the first thing we need to do before we start using its methods is to open our container.

Similarly to how we would load the GTM javascript on a webpage to access a container and its tags, in an app we need to open a container in some main app entry point before any tags can be executed or configuration values retrieved from GTM. Below is the easiest way of achieving this, as outlined on the Google Developers site:

ContainerOpener.openContainer(
        mTagManager,     // TagManager instance.
        GTM-XXXX”,       // Tag Manager Container ID.
        OpenType.PREFER_NON_DEFAULT,   // Prefer not to get the default container, but stale is OK.
        null,                    // Timeout period. Default is 2000ms.
        new ContainerOpener.Notifier() {       // Called when container loads.
          @Override
          public void containerAvailable(Container container) {
            // Handle assignment in callback to avoid blocking main thread.
            mContainer = container;
          }
        }
    );

Before we talk about what this code does, let’s hash out the different container types to avoid some confusion:

  • Container from network: Container with the most recent tags and configurations as currently published in the GTM interface
  • Saved container: Container saved locally on the device
  • Fresh vs. Stale container Saved container that is less vs. greater than 12 hours old
  • Default container: Container file with default configuration values manually added to the app project prior to shipping

We will talk more about the Default container later on. Back to the code. In this implementation, the ContainerOpener will return the first non-default container available. This means that we prefer to use a container from the network or a saved container, whichever is loaded first, because they are more likely to hold our most updated values. Even if the returned container is Stale it will be used, but an asynchronous network request is also made for a Fresh one. The timeout period, set as the default (2 seconds) above, specifies how long to wait before we abandon a request for a non-Default container and fall back on the Default container instead.

We may change the open type from PREFER_NON_DEFAULT to PREFER_FRESH, which means Google Tag Manager will try to retrieve a Fresh container either from the network or disk. The main difference is hence that a Stale container will not be used if we implement PREFER_FRESH unless no other container is available or the timeout period is exceeded. We may also adjust the timeout period for both PREFER_NON_DEFAULT and PREFER_FRESH, however we should think carefully about whether longer request times negatively affects the user experience before doing so.

Tag Example: Universal Analytics Tags

We have completed the initial set up and know how to access our Google Tag Manager container. Let’s go through a simple example of how to track App Views (screens) within our app using Universal Analytics tags.

Step 1: Push Values to the DataLayer Map

The DataLayer map is used to communicate runtime information from the app to GTM, in which we can set up rules based on key-value pairs pushed into the DataLayer. Users of GTM for websites will recognize the terminology. In our example, we want to push an event whenever a screen becomes visible to a user (In Android, the onStart method is suitable for this). Let’s give this event the value ‘screenVisible’. If we want to push several key-value pairs, we may utilize the mapOf() helper method as demonstrated below. In this case, since we will be tracking various screens, it makes sense to also push a value for the screen name.

public class ExampleActivity extends Activity {

  private static final String SCREEN_NAME = "example screen";
  private DataLayer mDataLayer;

  public void onStart() {
    super.onStart(); 
    mDataLayer = TagManager.getInstance(this).getDataLayer();
    mDataLayer.push(DataLayer.mapOf("event", "screenVisible",
                                                   "screenName", SCREEN_NAME));
  }
//..the rest of our activity code
}

We may then simply paste this code into every activity we want to track as a screen, replacing the SCREEN_NAME string value with the relevant name for each activity (“second screen”, “third screen”, etc.).

Note: the container must be open by the time we push values into the DataLayer or GTM will not be able to evaluate them.

Step 2: Set Up Macros In Google Tag Manager

Simply put, macros are the building blocks that tell GTM where to find certain types of information. Some macros come pre-defined in GTM, such as device language or screen resolution, but we may also create our own. First of all we want to create a Data Layer Variable macro called screenName: this is the name of the screen name value we pass along with the event as demonstrated above.

GTM will then be able to evaluate the screenName macro, which can consequently be used in our tags. If we have not done so already, we may also create a Constant String representing our Analytics property ID at this point. These macros are now at our disposal in all container tags.

Macros for Mobile Apps

Step 3: Configure an App View Tag

Let’s set up our Universal Analytics App View tag. Our configurations are visible in the screenshot below (note the use of our newly created macros). The screen name field value of the App View will be automatically populated and corresponds to what we push to the DataLayer as the value of the screenName macro. The gaProperty macro value specifies which Google Analytics property data should be sent to (by reusing it throughout our container, for every Universal Analytics tag, we can both save time and prevent some critical typos).

Tag Manager app view tag

Step 4: Configure a Firing Rule For Our Tag

Finally, we need to set up the conditions under which the tag should execute. Since we are pushing an event with the value “screenVisible” every time an activity becomes visible, this should be the condition under which our tag should fire, as demonstrated below.

Tag Manager firing rule

Step 5: Save and Publish

We can continue to create other tags at this point. It may be beneficial, for example, to create some Google Analytics Event tags to fire on certain interactions within our app. We should apply the same logic in these instances: We need to push various event values to the DataLayer as interactions occur, and then repeat the steps above to create the appropriate Universal Analytics tags. When we’re happy, all that’s left to do is to create a new version of the container and Publish.

Tag Manager version

As we ship our app with Google Tag Manager implemented, requests will be made to the GTM system to retrieve our tags and configuration values as we discussed earlier.

Hold on, there was one more thing: the Default container!

Default Containers

When we are finished with our initial Google Tag Manager implementation and feel happy with the tags we have created, we are almost ready to ship our app. One question should remain with us at this point: what do we do if our users are not connected to the internet and hence unable to retrieve our tags and configurations from the network? Enter the Default container.

Let’s back up a little bit. In the GTM world, tag creation, configuration, settings, etc. is primarily handled in the web-based GTM interface. The power of this is obvious: we no longer need to rely on our development teams to push code for every change we want to make. Instead, we make changes in the GTM interface, publish them, and our tags and values are updated accordingly for our user base. This of course relies on the ability of our websites or applications to reach the GTM servers so that the updates can take effect. Here things get a bit more tricky for mobile apps, which partly live offline, than for websites.

To ensure that at least some container version is always available to our app, we may add a container file holding our configuration values to the project. This can be a .json file or a binary file, the latter being the required type to evaluate macros at runtime through GTM rules. We may access the binary file of our container through the GTM user interface by going to the Versions section. Here, we should download the binary file for our latest published container version and add it to our project.

create tag manager version

The binary file should be put in a /assets/tagmanager folder and its filename should correspond to our container ID (the file must be located in this folder, and it must be named correctly with our container ID). At this point, we should have both the JAR file and the binary file added to our project as shown below.

Mobile app tag manager files

Once this is done, we are ready to ship the app with our Google Tag Manager implementation. As described earlier, Fresh containers will be requested continuously by the library. This ensures that, as we create new versions of our container and publish them in the web-based GTM interface, our user base will be updated accordingly. As a back-up, without any access to a container from either the network or disk, we still have the Default container stored in a binary file to fall back on.

Summary

Let’s summarize what we have done:

  1. After completing some initial configuration steps, we created a new app container in the web-based GTM interface
  2. We figured out how to open our container as users launch our app, choosing the most suitable opening type and timeout value (taking into consideration user experience and performance)
  3. We then implemented code to push an event to the Data Layer as various screens become visible to our users, setting up a Universal Analytics App View tag in GTM to fire every time this happens
  4. We downloaded the binary file of our container and added it to our app project to be used as a Default container
  5. Lastly, we created and published our container in GTM

We are now ready to ship our application with GTM implemented!

Closing Thoughts

Google Tag Manager for mobile apps can be an incredibly powerful tool. This basic example shows how to implement Universal Analytics using this system but barely scratches the surface of what is possible with highly configurable apps that are no longer frozen. Simply put, getting started with GTM for mobile apps today sets businesses up for success in the future, I recommend trying it out as soon as possible.

I would love to hear your thoughts around Google Tag Manager for mobile apps. What are your plans for (or how are you currently) using it?

Check out our Google Analytics solutions here

Check out our Adobe Analytics solutions here

Say Ola! by filling in the form below.