How to exclude admin users from being tracked

One of the most common requests for any analytics plugin is to keep the site owner and the staff out of the reports. With Google Tag Manager the question is wider than Google Analytics alone, because whatever you exclude applies to every tag in your container: your test conversions stay out of your ad accounts, you stay out of the remarketing audiences and your own work on the site stays out of the reports.

This page describes GTM4WP 2.0.0 and newer. Features introduced by that release are marked New in 2.0.0 and are not available in the legacy 1.x versions. Where 1.x behaved differently, the older behavior is marked with a bold GTM4WP 1.x: lead-in.

Two ways to exclude a user

GTM4WP can keep the container out of the page for the user roles you choose, or it can write the login state and the role of the visitor into the data layer so that you decide inside Google Tag Manager which tags are allowed to fire. The first one is a single setting. The second one takes a few minutes of work and leaves you in control of every tag.

Leave the container out of the page

The User roles to exclude option in the Google Tag Manager container section, on the Advanced tab, lists every user role of your site with a checkbox. When the logged in user has one of the checked roles, the container code is not written into the page, so none of your tags run for that user.

Two things stay as they are. The data layer is still rendered, so your own code that reads it keeps working, and GTM4WP writes a message into the browser console explaining why the container is missing, unless you turned on the “Do not use console.log() messages on frontend” option.

The drawback is that this is an all or nothing decision. Every tag disappears for those users, including the ones you may want to keep, and Google Tag Manager preview mode needs the container to be present, so you cannot debug your container while you are logged in with an excluded role. You have to log out, use a private browser window or switch to a user with a different role.

GTM4WP 1.x: the same option lives on the Advanced tab of the settings screen.

Exclude tags with Google Tag Manager triggers

The other approach keeps the container on the page and blocks individual tags with exception triggers. Some tags in your container may have to fire even while you are testing the site, and preview mode keeps working, which is why this is usually the better choice.

Remember that you are describing the case when a tag must NOT fire, so you have to think of your trigger the other way around. When the trigger conditions are met during page load or during a later interaction, the tags that use it as an exception stay silent.

Turn on the data layer variables you need

Both variables used below are switched off by default. You find them in the Page variables section, in the Visitor data group: Logged in status adds visitorLoginState and Logged in user role adds visitorType. Both are described in detail on the user and visitor data page.

GTM4WP 1.x: the same options live on the Basic data tab.

Simple case: exclude everyone logged in to your site

visitorLoginState is a simple data layer variable. The value logged-in means that someone is signed in to your site, whatever their role, and logged-out means that the visitor is anonymous. You read the value with a Data Layer variable in Google Tag Manager:

On many sites everyone who logs in is an admin or an editor, which makes this enough for a trigger:

Use the Custom Event trigger type and enter the regular expression .+ in the Event name field. This way you are not blocking only the tags that fire during page load: the same exception also covers add to cart and every other event that happens after the page has loaded. The .+ pattern works as an “every event” rule and matches page load as well.

Exclude admin users or other user roles

The trigger above is too broad for a WooCommerce store, where your customers are ordinary WordPress users without access to the admin area. In that case, and in any similar one, you need the role of the logged in user.

The data layer variable visitorType carries it. Create a new variable in Google Tag Manager to read the value:

When nobody is logged in, the value visitor-logged-out indicates that state. For a logged in user the variable holds the name of the role, administrator for admins and something like editor for lower level users. Using this, you can build a trigger that matches one specific role:

A user who has more than one role is reported with all of them in a single string, separated by commas, for example administrator,shop_manager. An “equals” condition fails for exactly those users, so the safer setup is ‘matching regex (ignore case)’ with the roles listed and separated by pipes: administrator|editor|whatever-userrole. Keep in mind that such a pattern matches anywhere in the value, so choose it carefully if one role name contains another.

Exclude but not while debugging

A trigger that blocks every tag for admins also blocks them while you are checking your tracking codes, when your goal is the opposite: you want the tags to fire so that you can see what happens.

To achieve this, enable the Debug Mode built in variable in Google Tag Manager and include it in the trigger:

This built in variable evaluates to true while you have preview mode turned on in Google Tag Manager and you open your website. Now you can add one more condition to your trigger:

What changes with the cache-safe data layer

New in 2.0.0. The experimental Cache-safe data layer option keeps visitor data out of HTML that a page cache would serve to everybody. With it enabled, visitorLoginState and visitorType are no longer part of the first data layer push. They are requested in the browser and pushed later, in a single event named gtm4wp.visitorData, and an anonymous visitor receives neither of them instead of the logged out values.

An exception trigger built on these two variables therefore cannot block a tag that fires on page load, because the values have not arrived yet. If you run the cache-safe data layer, exclude your staff with the “User roles to exclude” option instead, or keep the trigger approach for tags that fire on the gtm4wp.visitorData event and on the interactions that follow it.

The option is off by default. While it is off, everything described above works as written.

Add your exception trigger to tags

Now you only have to add the newly created trigger to each of your tags as an exception trigger: