5 Things I Learned about Google Tag Manager Being RoR Developer

Photo of Mateusz Górniak

Mateusz Górniak

Jul 26, 2018 • 9 min read

Google Tag Manager is a great tool to make fetching of analytics data much easier. Created for marketing specialists might be very helpful for web developers who don’t have to spend a lot of time on implementation of similar features, making Google Analytics powerful source of the truth about your users and app.

Even if it seems to be very straightforward, there are some rules you should know to be sure your data are collected right way. Here are few tips I learned about Google Tag Manager and Google Analytics last months that should help you to add basic configuration to your page.

Events and Virtual Pageviews

It’s a common question every beginner asks - should I use the events or virtual pageviews to measure users actions? Both might be used to collect informations about the interactions not generating typical page views but there are some differences you should be aware. Please look at the table below to get to know the most important ones:

Virtual Pageviews


Page views

Artificial increase on total pageviews

No increase on total pageviews

Tracking details

Limited information

Tracks more details correlated to actions

Impact on Bounce Rate

Might distort (decrease) stats

“Non-Interaction Hit” to avoid distorting

Virtual Pageviews have been created to collect data about users activity where we’d expect page refreshing but because of the used architecture, reloading is not possible or doesn’t make bigger sense (like changing the view for Single Page Apps). The second possible choice is using the GA events. They might include more informations about the context of the users actions executed without refreshing the page and shouldn’t duplicate our global stats. That’s why for most cases I’d recommend events as a default source of your data, but the final decision is yours to make.

How to configure triggers?

The next reason you will love GTM is the number of the built-in triggers (actions) we might use.

Google Tag Manager - Triggers-1

The standard list includes page views, form submissions, clicks or even visibility of the page’s elements. The choice might seem to be obvious but not always the simplest solution is the best one.

Let’s consider a Multiple Page App (for example RoR monolith app) with many Forms being a part of profiles multistep creator. We want to know how many users finished entire wizard and how many stuck on the one of the previous steps. This kind of data might be helpful to find out the reason of low conversion. The first approach, you might think about (Form Submission) wouldn’t work for us. Why?

  • Trigger doesn’t work well with MPAs (especially without using client-side validation) and we’re not able to count action based on the server response - submit is just considered as a sent request and it doesn’t matter what response’s code the server returns. In such cases sending invalid data might be considered by GTM as a finished step.
  • Most important issue: Even for the Forms with client-side validation there’s still possibility that you’ll lose a lot of data. Weak internet connection or too fast server’s response (or at least faster than communication with GTM server) might block the data and reduce number of events in our statistics.

How to deal with it? There are no perfect solutions. We should be aware of some smaller problems that might affect our data and know at least basic behaviour of our app. Assuming we’re using unique address for every step, we might get quite good results using page view trigger and count how many users (unique sessions) achieved all the pages.

Separating test and production data using lookup tables

As a developer you know process of development includes a lot of test environments (like your local machine, beta, staging etc.). Using debug mode is a great way to test how all the triggers works, but unfortunately default configuration doesn’t block requests from being sent to the production container. To be sure your tests don’t affect production data you should disable GTM scripts everywhere excluding production or even better - use separate Google Analytics container and store all your debug informations there.

How to do it? Here’s the example to-do list:

  1. Define variable you should send with every request from GTM script. Here’s the example pseudocode for RoR app you might add to one of your layouts:

    dataLayer.push({'productionEnv': '<%= Rails.env.production? %>'});

  2. Define the same Data Layer Variable in GTM Config
    Google Tag Manager - Data Layer Variable
  3. Use lookup table structure to return proper GTM account based on the variable’s value
    Google Tag Manager - Lookup Table-1
  4. Enable “Enable overriding settings in this tag” for all tags and define lookup table variable as “Tracking ID”

IP anonymization

According to the GPDR we shouldn’t share any private data with 3rd party apps without users permission. Even if you follow the good practices and not use any personal data to identify users (like e-mail addresses), there’s still one more thing GA is able to get from your users because of the default configuration - their IP addresses.

How to disable it for all the tags? It’s quite easy ;-)

Google Tag Manager - IP anonymization

  1. Open the Google Analytics Settings variable config
  2. Expand "More settings" option and expand "Fields to set"
  3. Click on “Add a field” and add following configuration:
    • Field name: anonymizeIp
    • Value: true
  4. Save and publish the changes

Session Unification

Analytics data are very helpful to find any trends for users behavior based on the actions they made. We’re able to find out the most popular pages / functions used by the users or the weaknesses of our product. To have the best perspective and gather not only some data but to try to identify our users needs, it’s worth to know a little more about them. As you might know (that’s not a big surprise, I think), Google is able to collect a lot of information or predict some of them, like location, gender or even hobbies and based on some groups show their expectations. Great, let’s analyse it! Is there something that may go wrong? Sure!

Think about a user who visited your webpage on the computer, created an account, logged in and tried to login once again but this time mobile device was the source of the traffic. From the GA’s perspective without any information from our side, Google might treat this user as a two completely different people. This quite common case (we’re using more and more ways to reach internet resources) might make your data worthless.

How to prepare Cross Device solution? It’s simple. Just tell GA who’s your visitor by setting UserID and turn on session unification. To understand how this process works, I recommend reading their official resources and very short article from my Friend about setting UserID in practice.


Google Tag Manager helps to check users expectations and might be a great source of the data about your projects. I’ve provided some tips that should be helpful for all the devs who want to configure their projects and measure basic events. Hope you liked it!

Photo of Mateusz Górniak

More posts by this author

Mateusz Górniak

A student of Computer Science at the Poznan University of Technology who's deeply in love with...
How to build products fast?  We've just answered the question in our Digital Acceleration Editorial  Sign up to get access

We're Netguru!

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency
Let's talk business!

Trusted by:

  • Vector-5
  • Babbel logo
  • Merc logo
  • Ikea logo
  • Volkswagen logo
  • UBS_Home