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 –

Bucket Testing

What Is Bucket Testing?

Bucket testing (sometimes referred to as A/B testing or split testing) is a term used to describe the method testing two versions of a website against one another to see which one performs better on specified key metrics (such as clicks, downloads or purchases).

There are at least two variations in each test, a Variation A and a Variation B. Metrics from each page variation are measured and visitors are randomly placed into respective ‘buckets’ where the data can be recorded and analyzed to determine which performs best.

Companies that market and sell products or services online rely on bucket testing to help them maximize revenue by optimizing their websites and landing pages for conversions.

How It Works: An Example

Let’s look at a hypothetical example. Each bucket test begins with a hypothesis that a certain variation on a landing page will perform better than the control. Say you have an existing landing page for a free nutrition eBook, Eat Raw Foods and Live Longer.

The button on the bottom of your landing page’s sign-up form says ‘Submit,’ but your hypothesis is that changing the text to ‘Get Your Free Copy’ will result in more form conversions. The existing page with the ‘Submit’ button is the control, or Variation A. The page with ‘Get Your Free Copy’ on the button is Variation B. The key metric you will measure is the percentage of visitors who fill out the form, or a form completion.

Because you have an ad campaign driving several thousand visitors a day to your landing page, it only takes a few days to get the results from your bucket test. It turns out that ‘Get Your Free Copy’ has a significantly higher click rate than ‘Submit,’ but the form completion rate is basically the same. Since the form completion rate is the key metric, you decide to try something different.

Bucket Tests & Conversion Optimization

Bucket testing plays a big role in conversion rate optimization. Running a bucket test allows you to test any hypothesis that can improve a page’s conversions. You can continue to try higher-converting button text for Eat Raw Foods and Live Longer or you can go on to test other hypotheses, such as bolder headline copy, more colorful imagery or arrows pointing to the sign-up button that will get more people to convert.

Companies spend millions of dollars to drive traffic to landing pages and websites that promote their product or service. With simple variations to page copy, imagery, and layouts, you can conduct a series of bucket tests to gather data and to iterate towards your highest-performing version of the page. You simply create variations of the page, changing one element at a time and measuring key metrics, then collect the results until reaching statistically significant results for each experiment.

Bucket testing can make a significant impact on conversions per page, resulting in revenue increases on your highest-trafficked pages.

Bucket testing can also help to eliminate subjective opinions as deciding factors in a page’s design or layout. The author of Eat Raw Foods and Live Longer may think that her photo will drive more customer demand – or she may insist on a rainbow palette of colors.

With bucket testing, there is no need for debate on what design or page elements will work best to convert a customer. The quantitative data will speak for itself, and drive the decision for you.

Tests should be prioritized to run on your most highly trafficked pages, since you may need hundreds or thousands of visitors to each variation to gather statistically significant data. The more traffic a page receives, the quicker you will be able to declare a winner.

Common Page Elements To Test:

  • Headlines and sub-headlines: varying the length, size, font and specific word combinations
  • Images: varying the number of images, placement, type of imagery (photography vs. illustration) and subject matter of imagery
  • Text: varying the number of words, style, font, size and placement
  • Call-to-action (CTA) buttons: varying common ones such as ‘Buy Now,’ ‘Sign Up,’ ‘Submit,’ ‘Get Started,’ or ‘Subscribe’ and varying sizes, colors and page placement
  • Logos of customers or third party sites: build credibility and convey trustworthiness (could include Better Business Bureau, TRUSTe or VeriSign logos as well as customer logos)

Give us a shout if you need any help with A/B testing by filling in the form below

Check out our Google Analytics solutions here

Check out our Adobe Analytics solutions here

Split Testing

Split Testing Simplified

Split testing (also referred to as A/B testing or multivariate testing) is a method of conducting controlled, randomized experiments with the goal of improving a website metric, such as clicks, form completions, or purchases. Incoming traffic to the website is distributed between the original (control) and the different variations without any of the visitors knowing that they are part of an experiment. The tester waits for a statistically significant difference in behavior to emerge. The results from each variation are compared to determine which version showed the greatest improvement.

This marketing methodology is frequently used to test changes to signup forms, registration pages, calls to action, or any other parts of a website where a measurable goal can be improved. For example, testing changes to an online checkout flow would help to determine what factors increase conversions from one page to the next and will lead to increased orders for the website owner.

Seemingly subjective choices about web design can be made objective using split testing, since the data collected from experiments will either support or undermine a hypothesis on which design will work best. Demonstrating ROI (return on investment) for a testing platform can be measured easily because tests are created with a quantifiable goal in mind.

Split testing results

Split testing tools allow for variations to be targeted at specific groups of visitors, delivering a more tailored and personalized experience. The web experience of these visitors is improved through testing, as indicated by the increased likelihood that they will complete a certain action on the site.

Within webpages, nearly every element can be changed for a split test. Marketers and web developers may try testing:

  • Visual elements: pictures, videos, and colors
  • Text: headlines, calls to action, and descriptions
  • Layout: arrangement and size of buttons, menus, and forms
  • Visitor flow: how a website user gets from point A to B

Some split testing best practices include:

  • Elimination: fewer page elements create less distractions from the conversion goal
  • Focus on the call to action: text resonates differently depending on the audience
  • Aim for the global maximum: test with the overarching goal of the website in mind, not the goals of individual pages
  • Provide symmetric and consistent experiences: make testing changes consistent throughout the visitor flow to improve conversions at every step of the process

Habitual testing for a website owner or business helps to build a culture of data-informed decision-making that takes into account audience preferences. Each click on a website is a data point from a potential customer. Conflicting opinions can be put to the test with split testing methodology, and the visitors to the website will inform the final decision on the “best” design.

Split testing Process

Split testing is equivalent to performing a controlled experiment, a methodology that can be applied to more than just web pages. The concept of split testing originated with direct mail and print advertising campaigns, which were tracked with a different phone number for each version. Currently, you can split test banner and text ads, television commercials, email subject lines, and web products.

Hope you liked the post.

Give us a shout if you need any help with A/B testing 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.