Tutorial: Exclude Logged in WordPress Users with Google Tag Manager

This tutorial will explain how to configure Google Tag Manager – GTM for short – so that your own visits your site don’t trigger Google Analytics tracking code. It makes the following assumptions:

  1. You’ve already set up Google Tag Manager and added the code to your site
  2. You’ve already set up Universal Analytics

Here, I will only show you how to prevent the Universal Analytics tag from firing when a logged in WordPress user visits the site. Let’s get started!

Step 1: Log into GTM and Create a new Variable

Sign in to your tag manager account, and go to “Variables” on the left hand side of the screen. Then click “New” as shown here:

Select Variables in GTM

This will bring up the following screen. Click “Choose a variable type”, and a list of variables will fly out from the right-hand side of the screen. Scroll down till you reach the sub-heading “Page Elements”. Then click “DOM Element” like this:

Choose Variable Type in Google Tag Manager

Then do the following:

  1. For “Selection Method”, choose “CSS Selector”
  2. Under “Element Selection”, type “body.logged-in”
  3. Under “Attribute Name”, type “class”

Here’s a screenshot to show you the settings:

Create the variable in Google Tag Manager

Save your changes and you’ve created a new variable!

Step 2: Modify the Universal Analytics Tag

I assume that you’ve already placed the UA tag to be fired on your website. Go to “Tags” on the left-hand side of the screen, and click “Universal Analytics”:

This will bring up your existing settings. Under triggering, you need to make sure that you’ve chosen a “DOM Ready” trigger, and NOT a regular “Pageview” trigger type like most configurations.

Make Sure that Analytics Loads on DOM Ready - Not Pageview

If you do have a plain “Pageview” as the trigger, click and edit it like this:

Select the DOM Ready Trigger Type

Under “Page View”, select “DOM Ready”. Now the Trigger Type should show “Page View – DOM Ready” instead of just “Page View”. Next, do the following:

  1. Under “This trigger fires on”, choose “Some DOM Ready Events”
  2. Under the section “Fire this trigger when an Event occurs and all of these conditions are true”, insert this rule:

“WordPress Logged in” “equals” “null”. See the screenshot below to understand:

Fire Analytics only when Variable is null

Give your trigger a name at the top – I’ve used “Page has loaded”, and save your changes. You’re done. Now it’s testing time!

How Does this Work

Before we go into testing, let me explain what we just did. Basically, whenever you visit your website as a logged in user, WordPress inserts a class attribute into the body tag of the page called “logged-in”. See the screenshot:

WordPress adds logged-in class to body

This class value is absent when a regular visitor lands on any WordPress page or post. If by some by some chance your theme has modified this, then this solution will NOT work for you. You’ll have to use some PHP code to output some unique HTML when the user is logged in – it shouldn’t be difficult. Some action hook with the “is_user_logged_in” function to insert a bit of unique HTML should be sufficient.

And of course, you’ll need to change the “Element Selection” value in Step 1.

But most of the time, this won’t be necessary. Hardly any theme would change the default classes supplied by WordPress and replace them with something else.

So our tag variable checks for the existence of the “body.logged-in” class. If it doesn’t exist, it returns the string “null”. Otherwise, it outputs the entire contents of the “class” attribute. I filled in the “Attribute Name” field to class because otherwise the variable would take the value of the entire post text. And that would be very inefficient!

Finally, we tell Google Tag Manager to trigger the Universal Analytics code on DOM events. But only SOME DOM events. We tell it to trigger only when the value of the variable we created is “null”. Which means the “logged-in” class value is missing. Which means the user isn’t logged in. And so it fires only for regular visitors and not for users!

Nifty eh? Before we publish our changes, let’s test them and see if they work.

Testing if our Changes to GTM Work

Step 1: Disable Cloudflare

This took me a long time to figure out. Most of us use Cloudflare to speed up our site. But to enable the preview mode of Google Tag Manager, you need to temporarily pause it. To do this, go to the Cloudflare dashboard, and choose “Overview”. From there, click the “Advanced” link and then hit the “Pause” button as shown here:

Disable or Pause Cloudflare

This will temporarily pause Cloudflare until you re-enable it. But your browser probably hasn’t realized it yet and still caches a lot of stuff. Everyone tells us to press “Ctrl+shift+R” to clear the cache, but it never works. At least it’s never worked with me.

What you need to do is open up a window in your browser’s Incognito mode after waiting for a minute or so. Fire up your website and view the source code. If you find any references to the “rocket” script, it means that Cloudflare is still working on your site. Keep opening Incognito browsers with Cloudflare disabled until you no longer see the phrase “rocket” in your site’s source code.

Step 2: Enable the GTM Preview Mode

Once you’re sure your site is uncached, sign into your WordPress site in Incognito mode. Now visit some page that you want to test.

Next, go to the Google Tag Manager and click the “Preview” button as shown here:

Enable Preview Mode in Google Tag Manager

This will bring up an orange bar that sets GTM in preview mode. It allows us to debug our changes before they go live. When preview mode enabled, reload your website page in another tab next to GTM. You should see a Google Tag Manager window open up below it.

Step 3: Test if Our Variable is Working to Exclude Logged in WordPress Users

Since you’re logged into your site, you should see the following under the “Summary” section of the GTM window:

No Tags Fired when Logged into Website

Under “Tags Fired On This Page”, it should say “None”. Now go to the “DOM Ready” section and click the “Universal Analytics” box:

Select Universal Analytics in DOM Ready View

Click the “Tags” tab. Now scroll down till you reach the section “Firing Triggers”. As you can see below, the “Page has Loaded” trigger has a red cross next to it – meaning that it has not fired.

Exclude Logged in WordPress Users with GTM

The reason for this is that the “WordPress Logged in Variable” is false – also evidenced by the red cross next to it. Since our condition is that it should “null”, a red cross means that it’s NOT null. Therefore, we are logged in, and it’s preventing the tag from being fired.

We can further test this by clicking the “Variables” tag. Scrolling down, we see that the “WordPress Logged In” variable has some value. In other words, it’s not null.

WordPress Logged in Has Some Value

So the tag wasn’t fired!

Step 4: Re-enable Cloudflare

After your testing, don’t forget to re-enable Cloudflare!

Wrapping Up

And that’s how we exclude logged in WordPress users from being tracked with Google Tag Manager. The Universal Analytics tag only fires when a certain variable for logged in users is missing. I hope you found this tutorial useful and easy to follow!

About Bhagwad Park

I've been writing about web hosting and WordPress tutorials since 2008. I also create tutorials on Linux server administration, and have a ton of experience with web hosting products. Contact me via e-mail!


  1. This was very helpful. Suggestion – it’s important to Publish the change and save a version after making these changes or they won’t take effect.


  2. I was trying to exclude my own visits from GA without using the “exclude IP” method but couldn’t find any articles that had easy-to-follow instructions. I was getting frustrated until I came across your article. THANK YOU SO MUCH


  3. Exactly what I needed, and it works like a charm! Thank you very much for this very clear and well written article.

    For me, the question was not to exclude all registered users but only part of them (the project team members), namely “administrators” and a certain type of Buddypress users called “hidden_members” (such as persona for testing purpose). So I used exactly your technique and just added this little piece of code in my function.php file:

    //*** Add class in body tag for admins and hidden members (used for excluding them from GA analytics in GTM)
    add_filter( ‘body_class’, function( $classes )
    global $user_ID;
    if( is_admin() or current_user_can(‘administrator’) or bp_has_member_type( $user_ID, ‘hidden_member’ ) )
    $classes = array_merge( $classes, array( ‘s4s-team-member’ ) );
    return $classes;
    } );

    Of course, the test can be replaced by any other one and so is the added class name.

    Thanks again for this very elegant and simple solution!


  4. Extremely helpful tutorials. It seems like it’s working on my end. I have to yet check if it’s working as it is supposed to when I launch the site. Thanks a lot, Bhagwad


  5. Would this still work if we kept the “All Pages” firing trigger and added an exception trigger that is configured as described in this article? Essentially the tag would then have:

    Firing Trigger: All Pages
    Exception Trigger: Page View โ€“ DOM Ready (as per this article)



    • Try and see! Let me know if you manage to make it work ๐Ÿ™‚


      • I prefer to use exception triggers. I set this up a little differently. For the “LoggedIn” DOM variable, I put “body” as the selector. For the trigger, I configured a Pageview with some some pageviews, “LoggedIn” contains “logged-in admin-bar” and then, I added this exception to the universal GA tag. This worked.


  6. This was so helpful. Thank you very much!


Speak Your Mind