Tutorial: Exclude Logged in WordPress Users with Google Tag Manager

This tutorial will explain how to configure Google Tag Manager (GTM) to exclude logged-in WordPress users from triggering the Google Analytics tracking code. It assumes you have already:

  1. Set up Google Analytics 4 – GA4
  2. Added GA4 to Google Tag Manager

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!

Table of Contents

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
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 DOM Element from Page Elements
Choose DOM Element from Page Elements

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
Create the Variable in Google Tag Manager

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

Step 2: Create a “Not Logged into WordPress” Trigger

On the left-hand side of Google Tag Manager, click “Triggers” and create a new Trigger called “Not Logged into WordPress” with the following configuration:

Create a Trigger for Not Logged in Page View - DOM Ready
Create a Trigger for Not Logged in Page View – DOM Ready

Under “Trigger Type”, select “Page View – DOM Ready”. This will ensure that the trigger will fire only after the HTML has been rendered. Select “Some DOM Ready Events” and select the “WordPress Logged In “variable we created in step 1, where it says:

“Fire this trigger when an Event occurs and all of these conditions are true”

Select “equals” and type “null” in the following box. This means that the “body.logged in” CSS selector wasn’t found, implying that the user isn’t logged in.

Step 3: Modify the GA4 Tag in GTM

Next, head to the list of tags in GTM and click the tag you already have for GA4, as shown here:

Select the GA4 Tag Configuration in Google Tag Manager
Select the GA4 Tag Configuration in Google Tag Manager

In the tag configuration, modify the trigger at the bottom to “Not Logged into WordPress” that we created in step 2, as shown here:

Select the Not Logged into WordPress Trigger in the GA4 Tag Configuration
Select the Not Logged into WordPress Trigger in the GA4 Tag Configuration

Save the changes to your GA4 tag.

Don’t Forget to Publish your Changes!

Many people miss this final step. Don’t forget to submit and publish your changes. Without this, GTM won’t load your new trigger and tags.

How This Works

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

WordPress adds logged-in class to body
WordPress adds a logged-in class to the body

This class value is absent when a regular visitor lands on any WordPress page or post. If by some chance your theme has modified this, then this solution will NOT work for you. You’ll have to use PHP code to output unique HTML when the user is logged in – it shouldn’t be difficult. An 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”. This means the “logged-in” class value is missing, and 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 pause it temporarily. 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
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.

It would help if you opened up a window in your browser’s Incognito mode after waiting a minute or so. Fire up your website and view the source code. Cloudflare is still working on your site if you find any references to the “rocket” script. 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 a 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
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 is 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
No Tags Fired when Logged into the 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
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
Exclude Logged in WordPress Users with GTM

This is because the “WordPress Logged in Variable” is false – also evidenced by the red cross next to it. Since our condition is that it should be “null”, a red cross means it’s NOT null. Therefore, we are logged in, 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
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 Google Analytics tag only fires when missing a specific variable for logged-in users. 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!

Comments

  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.

    Reply

  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

    Reply

  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!
    Yves.

    Reply

  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

    Reply

  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)

    Thanks
    Sascha

    Reply

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

      Reply

      • 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.

        Reply

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

    Reply

  7. This is the best method, other articles wanted me to install an additional plugin, or insert code. Genius using the CSS selector like you. I also learnt something new about GTM. So many powerful features, and not much documentation or learning materials for this.

    Reply

Speak Your Mind

*

WP-Tweaks