Monitor your dataLayer’s data quality in real-time using Google Tag Manager custom templates and Firebase

In my first Medium article I explained how you could use Google Tag Manager’s addEventCallBack API in combination with Firebase Functions and Real-Time database to monitor and receive notifications when tags fail to load.

This time, I want to share with you a new Google Tag Manager custom template that does something similar, but it checks the values in your dataLayer against conditions you can define yourself.

Implementing this dataLayer monitor will help you take your next step in improving your data quality through tag management.

The Customer ID Business Case

Let’s say your website or app loads customer IDs, when a user is (auto)logged in, into the dataLayer so that every hit sent to Google Analytics contains that ID. This is a best practice since it will allow you or your analysts to track user behavior more granually.

Can you imagine what the impact would be if that customer ID fails to load properly? Exactly. I have witnessed this scenario first hand with a client before and it took 2 weeks to become aware of the flaw and a few more days to fix the issue.

What to do? Back then, nothing really. Now, you can use my Google Tag Manager custom template and Firebase Function with Firebase Real-Time database to receive notifications when this happens.

Can you come up with any cases for yourself? I have a list created for my clients already. This solution is extremely versatile.

The DataLayer Monitor template

There are 2 facets to this solution:

1. Google Tag Manager Custom Template
2. Firebase Account with Functions and Real-Time Database activated

First, the Google Tag Manager Custom Template. This template will allow you to do 2 main things:

1. Define which dataLayer values you want to check, against which condition and against a specific value.
2. Define and endpoint to send your failed checks to for real-time monitoring and notifications, just like my previous solution.

Basic overview of the dataLayer Monitor tag

The custom tempalte allows for conditional checks such as:

• equals
• containt
• starts with
• ends with
• does not equal (includes an undefined check)
• does not contain
• does not start with
• does not end with
• has length of (to check against string lengths)

As you can quickly ascertain, there is no conditional checks related to regex. This is due to the fact that Google Tag Manager Custom Templates’ sandbox does not allow this feature. So eventhough you could theoretically enter a regex argument in the last field, there is no way to change that value from a string to a regex argument in the code. Once this does happen, I will update the template.

Other items that are missing are your quantitative conditional checks such as less than or greater than or equal to. Again, this is due to the inability to change the value type of the last field from a string to a number. parseFloat is not recognized for instance.

The special condition is does not equal into which I have built in a functionality to also check for undefined types. I hope this helps some of you overcome this hurdle when checking against undefined values.

To further compensate for the lack of regex checking I have added has length of to the option with which you can check to see if a dataLayer value at least has a certain length such as customer IDs, transaction IDs etc.

What will you need?

The prerequisites are the same as for my previously documented real-time notification system.

1. IDE, for editing code
2. Node on local machine to install Firebase Tools
3. Firebase account with Blaze Plan enabled
4. Firebase Tools from NPM
5. Zapier account
6. Firebase Functions script (Github repo)
7. my DataLayer Monitor Custom Template (Github repo)

How to implement your dataLayer monitor?

STEP 1 Download or clone both Github repos.

STEP 2 Setup Firebase by creating a project, activate functions and databases, then deploy the functions script. Follow steps 1 through 7 in my other article with the new functions script.

STEP 3 Copy and save your Firebase Function endpoint URL and keep it ready to use in the tag template in Google Tag Manager.

STEP 4 Import the custom template into Google Tag Manager.

Import the dataLayer Monitor template

STEP 5 Create a new tag in Google Tag Manager using the new template and assign it a trigger for All Pages and if you want also all events.
The latter can be done by creating a trigger using the Custom Event template. Enter .* as the Event Name and check the option Use regex matching. It should look something like this:

Custom Event trigger to work on all events

STEP 6 Fill in the dataLayer keys in the dataLayer Monitor Custom Template tag you have just created in step 4 with the values you want to monitor.

dataLayer = [{
'customerId': '123456789',
'country':'nl',
'meta': {
    'path':'/some/path',
    'title':'Some Title'
  }
}];

Now, let’s say your dataLayer was set on page load and it contains the values in the example above.

In the dataLayer Key fields you can enter the following values for each:

• customerId
• country
• meta.path
• meta.title

CAVEAT there is one problem with reading dataLayer keys from a custom template at the moment. Google Tag Manager will not allow you to access to the root dataLayer by default. In the template’s Permissions tab you will need to enter all the dataLayer keys you want to monitor before you can save your tag.

Root access to the dataLayer is not allowed

You can use dot notation to traverse the dataLayer into deeper levels.

Your tag should look like this now:

dataLayer Monitor tag with 4 keys filled in for monitoring

Now we need to add the conditional statements. Let’s use the following:

• customerId has length of 9 digits/characters
• country has length of 2 characters
• meta.path does not equal undefined
• meta.title contains Tagticians

Your tag will now look like this:

dataLayer Monitor tag with 4 keys and conditions defined

Now copy your Firebase Function endpoint URL into the Notification Endpoint URL field at the bottom. Make sure it ends on /collect since this is the define endpoint that Firebase listens on for incoming requests.

STEP 7 Save and preview. Test (see below). When satisfied publish to production.

Testing the dataLayer monitor to see if it works

If you want to test the dataLayer monitor before you publish to production, which you should always do, there are a few ways to do this. It comes down to you forcing errors in the dataLayer to trigger the custom template to send a request to the Firebase Function for testing.

The easiest way to do this, is to create a new Custom Event trigger. Give the trigger a name and enter the custom event name you want to use for testing. In this example I have used dataLayerMonitorCheck, very creative yes.

Setting up the Custom Event trigger for testing purposes

Remove all the triggers from the dataLayer monitor tag you have just created and add the new testing trigger. Save and review.

Now, in your browser’s Javascript console, use a dataLayer.push method to inject data into the dataLayer.

dataLayer.push({
'event':'dataLayerMonitorCheck',
'customerId': '123456789',
'country':'nl',
'meta': {
    'path':'/some/path',
    'title':'Some Title'
  }
});

Test with different values for each key and make sure to also test values that will fail the conditional checks you have defined.

The next thing you want to do is open Firebase’s Real-Time database linked to your project and watch the data, the dataLayer keys that contained errors, flow in.

Just like the other monitoring function scripts I have made, the record will be paused and a notification sent when more than 3 errors come in within 60 minutes (default). You can change this time limit in the functions script to anything you want.

Snapshot of the Firebase Real-Time database when a notification has been sent

Now that it has been tested and everything is working, let’s setup Zapier.

Setup Zapier Webhooks to receive and parse data

This process of using Zapier Webhooks was documented in a follow up article for the real-time notifications for tag failures. In it I describe how to setup Zapier Webhooks with the functions script and build an action to send this data to your destination of choice.

The only difference between that article and this new script are the values I send to Zapier.

So don’t forget to add your Zapier Webhook url to the dataLayer monitor functions script and redeploy it to Firebase!

The values for the dataLayer monitor script which you can subsequently use in Zapier are:

1. keyRaw: this is the original key you were checking against, ie. meta.path or country.
2. keyValue: this is the value recorded that caused the error to trigger.
3. condition: this is the conditional statement your were using to check the dataLayer value against.
4. url: this is the url of the page the error last occurred on prior to sending the notification.
5. timepause: this is a number to indicate how long notifications have been paused for a specific dataLayer key being monitored.

I will leave it up to you how you want to build your action in Zapier, but you can do quite a lot already with these 5 values to detect those pesky dataLayer errors.

Afterthoughts

There are a few things to consider before you start implementing this dataLayer monitor.

First of all, ALWAYS TEST! If you have a high traffic website and a lot of dataLayer errors your server calls to Firebase might go beyond the free limits and you will be charged a fee.

Don’t implement it if your not capable or don’t have access to resources to fix errors. The purpose of the dataLayer monitor is to detect errors and notify you when the exceed certain predefined parameters.

The dataLayer monitor is limited by the absence of regex or number constructors in the Custom Template sandboxed environment. Add to that the inability to access the dataLayer at its root level, makes this a more complex setup. When updates to these impediments do come, the capabilities of the dataLayer monitor will become more substantial.

Future Iterations

I will perform futher tests on this and update it where needed. There are so many ways to extend this script going forward, not to mention when we can use regex and compare numeric values.

Other ideas include a user interface to pause all or certain notifications, change notification pause values and to check against values in the dataLayer only of the key is present, or another key has a certain value, ie. loggedInStatus or isClient. You name it. Share your ideas in the comments or contact met through LinkedIn.