In several different situations you may want to track the traffic made by logged-in users in a blog. For example, you manage a large corporate blog when a relevant quota of traffic is made by employers and you want to segment it. Or, most probably, you simply want to filter out your and your co-authors’ own traffic in a smaller blog or magazine. Here we’re going to discuss how to track and eventually filter traffic from logged-in users in Google Tag Manager and with a very small fix to your WordPress theme.


Before starting, let me explain that I’m not a style paranoid, nor a narcissist. Yes, I admit I usually preview my posts so many times I would ended up to skew my entire analytics. But, I do that because english is not my mother tongue and I care about my loyal readers we deserve a better grammar. Really!

Common ways to tag admin traffic from Google Analytics or WordPress

As I said, there’re several ways to track out your own traffic from Google Analytics. If you just want to filter, you could block your IP or setting a dummy cookie. The first approach is easy, but not portable, while the latter needs to build a custom page with some JavaScript inside, which is something a CMS usually won’t allow you to do (yeah, I’m talking to you,WordPress!). But of them suffer of one huge defect: the filtered traffic is lost forever.

Another strategy is to use a plugin. This is fast and easy, but I prefer to not bloat my WordPress installation with tons of plugins, if I can carry out the task without. Dont’ forget we’re talking about a full plugin to just add 5 lines of JavaScript here and there. Rainmaker say no-good.

In facts, what we just need to do here is to tell GTM if a given page view comes from an authenticated or from an anonymous user. This is a bit of information the CMS (WordPress) actually knows, so we just need to pull it out and push to GTM.

The WordPress part: get the information we need

Using a child theme(still not using a child theme in WordPress? You should!), the task is as easy as populate the GTM data layer with some useful variables we’ll later use on GTM itself to make a trigger.

Open the functions.php file of your child-theme and add these lines of code:

What this code simply does is to push a WordPressReady event with a visitorLoginState payload, which in turn can assume only two values: logged-in and logged-out. The event was introduced for GTM to be informed about when WordPress has returned the data.

It’s important to note that WordPress queues the script in the HEAD section, while, as guidelines state, the GTM container should be placed just after the BODY opening tag. This is absolutely legit, as events are sequentially resolved even if they are pushed before gtm.js is loaded.

In facts, that’s exactly what we need because this effect allows WordpressReady to be executed before the Google Analytics Pageview event (which is typically fired a bit later, when the gtm container has finished to load itself), ensuring the the data we pulled from WordPress is available when the GA tracking tag is fired. And that’s exactly what we need!

Remember: if the code snippet is inserted after the GTM container script, the variables will be available on Google Tag Manager only after the page view event is fired and the value won’t be pushed to Google Analytics!

I said Google Analytics? Yeah, close WordPress as we finished here and open your Google Analytics console, now.

The Google Analytics part: define the custom dimension used to store the login status

One of the nicest features of Google Analytics is the possibility to add custom dimensions to our page views and events and to use in our reports. But before pushing data to Google Analytics, we must tell GA itself.

To do so, open the admin section of your Google Analytics property and find the Custom Definitions area, then go to Custom Dimensions.

Google Analytics - Where to set Custom Dimensions

Click on New Custom Dimensions and fill the form. It’s important to set the dimension scope to Session: this way, if a user browses some pages before performing the login, these pages will be tagged as being made by an authenticated user anyway. The mechanism is simple: the entire current user session is tagged with the last value the dimension carries on.

Don’t worry about the JavaScript code, since Google Tag Manager will take care of that. But write down the number that GA gave to the custom dimension (2, in my case), as it will used later in GTM.

Settings for the custom Google Analytics dimension to track login state

Now, the final magic.

The Google Tag Manager part: map the datalayer variable into Google Analytics stuff

First of all, let’s import the visitorLoginState dataLayer variable into GTM. Go to the Variables panel and create a new variable:

  • Variable Name: Login State
  • Choose Type: Data Layer
  • Data Layer Variable Name: visitorLoginState
  • Data Layer Version: Version 2

How to set the GTM data layer variable to track the login state

This imports the variable we set in JavaScript to GTM.

Now. go to the Tags panel and select the Google Analytics page view tag you should have already (if you haven’t, just check my intro tutorial). Go to Configure Tag, then to Advanced Settings. Finally, define a custom dimension with the index  you have from Google Analytics (2, in my case) and the GTM variable which holds the value.

How to setup the GA custom dimesion for login state in GTM

 

Et voilà! Now, every session will be tagged as logged-in or logged-out in Google Analytics. Now let’s have a look on the sequence the tags were fired from the GTM Preview feature:

This screenshot shows how the WordPressReady event was fired before Pageview event and how the latter has all the data we need into the data layer

The screenshot clearly shows how the WordPressReady event was fired before the Pageview event and this ensures the latter has the data layer perfectly set. As you may see, in my setup I have more custom data, like author and page type and this actually is the subject for the next tutorial.

Bonus part: a graceful solution if you won’t use a WordPress child theme

Really….give me a reason to not use a child theme in WordPress? Ok, you’re right. it’s not my business. What’s that really matters is that a workaround actually exists. It’s not as elegant as a romantic dinner in Venice, but it works (for now).

The trick here is to use to use the WP Admin Bar to check if a user is logged or not. Thanks to WordPress designers, this bar has a unique ID and won’t show if a user is not logged.

So, let’s go on GTM and define the Login State variable as follows, instead:

  • Choose Type: JavaScript Variable

And fill the tag with these lines of code:

I won’t say that I love this solution: it’s not guaranteed to work with future versions of WordPress or in some exotic plugin configurations (such as, CloudFlare plugin that removes the WP Admin bar at all). But better than nothing, right?

Share This