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
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:
$visitorLoginState = (is_user_logged_in() ? "logged-in" : "logged-out");
window.dataLayer = window.dataLayer || ;
'visitorLoginState': '" . $visitorLoginState . "',
add_action( 'wp_print_scripts', 'wordpress_ready_gtm' );
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.
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.
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
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.
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:
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:
And fill the tag with these lines of code:
var adminbar = document.getElementById("wpadminbar").textContent;
if (adminbar != undefined ) return "logged-in";
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?