Exclude WordPress Admins from Google Analytics

This is the much requested, follow-up article to The Best Way to Exclude Yourself From Google Analytics Data. In that previous article, I shared my technique for filtering yourself or your staff out of the GA data collected on your website. Since it was a generic walkthrough, I’ve received a bunch of requests for a WordPress specific tutorial.

Overview of the Technique

Read the entire post here.

  1. Create a Dimension in Google Analytics

    In the Admin tab of Google Analytics for your property, add a new custom dimension and name it User Type or User is Admin. Select a scope of User. Select the Active box and click Create.

  2. Create a Filter in Google Analytics

    Create a new view and apply a filter to it. The filter should be a Custom type, using the Exclude option, and set to use our new Custom Dimension. For filter pattern, you may enter true or, if you are specifying different user types, then enter the type of user or users you are excluding.

  3. Set a Cookie for Any Access to the Admin / Special Page

    Add a PHP snippet to set a cookie to a file that is only loaded when you’re logged into your admin or use a special page that only you and the users you want excluded will know about.

  4. Set the Dimension When the Cookie Exists

    Find where you’re outputting your Google Analytics tracking code on your front-end. Conditionally insert your custom dimension and value based on the existence of the cookie we set. You’ll want to include it just above ga('send', 'pageview');.

Pro Tip: Keep an unfiltered view for all data, even that which is messy and bloated with your own activity and that of bots or spammers. Then primarily monitor a view called Real Users, which consists purely of the data from real people. Add your filter to this view.

If any of this was over your head, please read the original article on The Best Way to Exclude Yourself From Google Analytics Data. I promise it will make a lot more sense as that article is very thorough.

Now onto the WordPress specific tutorial…

Exclude WordPress Admins

This is actually quite simple. That may be why I haven’t bothered to update the previous article. But since that’s not nice to the less savvy code monkeys, I finally got around to it – and here you go.

Everything from Steps 1, 2, and 4 is exactly the same for this technique. Once you’ve completed those steps, take a break. You’re almost done. And yes, you can safely complete Step 4 out of order. If the cookie doesn’t exist, nothing will happen, so you won’t break anything if you complete those three steps first.

For Step 3 we will be adding our cookie code to our theme’s functions.php file.

function my_exclude_admin_cookie() {
    $expire_time = time() + 60 * 60 * 24 * 180;
    setcookie( 'user_is_admin', 'true', $expire_time, '/' );
if( is_admin() ) {
    add_action('init', 'my_exclude_admin_cookie');

That’s it. Now whenever a visitor has accessed the admin (and become a known admin user), they will have the cookie to stop them from being tracked.

Please keep in mind that this will exclude all logged-in users. Keep reading for how to specify only certain user types.

Alternative Methods

I have two alternatives for accomplishing the goal of filtering WordPress admins from GA. One of them modifies the above technique and the other completely removes the need for any code at all!

The “No Cookie” Method

We can change our method of tracking WordPress admins if we don’t want to use cookies. The cookie method is great if you want to set a really long expiry time on tracking the admin. But if you only want to exclude views while a user is logged into the admin, then you can skip the cookies (and Step 3).

Instead, we’ll modify Step 4‘s code to utilize WordPress’ built-in functions for checking user roles. This still goes within your Google Analytics tracking code before you set ga('send', 'pageview');.

if( current_user_can('editor') || current_user_can('administrator') ) {
    echo 'ga(\'set\', \'dimension1\', \'true\');';

Here I’m setting my custom dimension to true if the current logged-in user is either an administrator or an editor. You can now pick which of your user types will be filtered out with a bit more control. You could also apply this to setting a cookie if you would rather have the control over user types but want the exclusion to apply long after they are logged out.

The “No Code” Method

This method is actually the one I’m utilizing here on this blog, now that I’ve redesigned it on WordPress. I’m going to publish yet another article very soon on this method. I’ll update this post with a link to the “No Code” method as soon as it’s up. Bookmark my blog or follow me on Twitter to keep up with new posts.

In conclusion, it really wasn’t all that hard to adapt the code to WordPress. Most of you who have been asking should now know just how to exclude WordPress admins on your site. However, another question I receive frequently is how to do this with Google Tag Manager, and as of yet, I’ve never used it and I simply don’t know. If you know how to adapt this technique for Google Tag Manager, please let me know in the comments.

And of course, stay tuned for the “No Code” method!

  • Pingback: The Best Way to Exclude Yourself From Google Analytics Data — AndrewMiguelez.com()

  • I figured out how to do this using Google Tag Manager!!! Now, the method I’m using will not allow you to have a separate filtered and unfiltered view. The reason is because this method basically tells GTM that when the cookie is present, don’t send the analytics info. You won’t need to worry about Steps 1 or 2. But definitely Step 3. You still need that cookie in your functions.php file.

    Here’s what you do next:

    4A. Create a new Variable. I named mine “Admin Cookie”
    Variable Type is “1st Party Cookie”
    Cookie Name is whatever you set your cookie name to.

    4B. Create a new Trigger. I named mine “Blocking – Admin Cookie”
    Trigger Type is “Custom Event”
    Event Name is “.*”
    Make sure to check “Use regex matching”
    Fire the trigger on “Some Custom Events”
    Set the variable (first dropdown) to your new “Admin Cookie” variable.
    Set the second dropdown to “matches RegEx (ignore case)”
    For the third box enter “true” or whatever your filter pattern is set to.

    4C. Finally, edit your “GA Pageview” tag.
    Under Triggering you’ll see “Add Exception”
    Add your “Blocking – Admin Cookie” trigger.
    Save, Publish, and Test!

    Do a full blown happy dance, because I did!

    • Andrew Miguelez

      Very cool. Thanks for sharing!
      I’m sorry that I didn’t reply for so long. I was planning on writing a new post on GTM once I had done a test with it and wanted to incorporate your example. However, I got busy and forgot to say thanks. Anyway, I do plan on posting an overview of using Google Analytics with a plugin in WordPress and skipping all the coding necessary to achieve this manually. Hope you will check it out when it gets published and let me know if you can do the same with GTM.

  • Andrew Miguelez

    Very nice, Anthony! Happy dance indeed. Thanks for sharing this advanced version of tracking with GTM!

  • Thank you for this!

    My theme (Extra, but Divi is the same way) has a place to insert additional code in the header. When I tried to put the PHP there, it was printing the PHP directly rather than executing the PHP script. So, I added this to my header.php file, and then copied that edited header.php file over to my child theme.

    I’d be interested in the no code option—also, I’m not sure if there is a way to add just the Google Analytics script to my child theme functions.php file to insert into the header.php file. I’m not a coder, but I know enough to be dangerous. 🙂

    Thanks again for your work on this tutorial. It’s extremely helpful.

    • Andrew Miguelez

      Jacob, so glad this helped you. I will certainly let you know when I publish a post on using a plugin for a no-code solution. As for adding to a child theme without overwriting the rest of the functions.php file, there is no way to do this unfortunately. It would be a great feature if you could make a functions file that loaded before or after the theme’s functions file so you could add on without having to keep it up to date when changes are made to the theme. But alas, no. That’s not a feature of WordPress theme structure.

    • Andrew Miguelez

      Also… a pastor who maintains his own website? I’m down with that. Keep it up, Dude!

      “An intelligent heart acquires knowledge, and the ear of the wise seeks knowledge.” – Proverbs 18:15

      “Give instruction to a wise man, and he will be still wiser; teach a righteous man, and he will increase in learning.” – Proverbs 9:9

  • Hi Andrew,

    Thanks for this article. One issue with these methods is that, if you place the code to set the cookie in your theme’s functions.php file, the code gets replaced when your theme is updated. Does your “no code” method get around this problem?

  • Andrew Miguelez

    Since it was deleted, original comment follows:

    Hi Andrew,

    Thanks for this article. One issue with these methods is that, if you place the code to set the cookie in your theme’s functions.php file, the code gets replaced when your theme is updated. Does your “no code” method get around this problem?

  • PhYrE

    Whoa! This is wrong. See the function reference for is_admin: “Does not check if the user is an administrator; current_user_can() for checking roles and capabilities.”

    If someone hits website/wp-admin/, admin or not, the cookie will be set. I guess arguably few end users may do that, but it’s incorrect to set this kind of cookie based on is_admin versus checking if they’re logged in and an admin user. This cookie could be used for other things.

    if( current_user_can(‘editor’) || current_user_can(‘administrator’) ) {
    add_action(‘init’, ‘my_exclude_admin_cookie’);

    ensures the user is logged in at the time and works much better.

    • Andrew Miguelez

      Wow, you are so right! It’s been a while since I’ve looked at this code (haven’t used it in years since WP GA plugins do it so much more easily) but yeah! The use of `is_admin()` is incorrect for what I was claiming. I’ll definitely update this post to reflect this revelation though I’m not worried about anyone’s analytics being skewed as in practice this would have worked perfectly in 99.9% of cases.

      Thank you so much for bringing this to my attention!

    • Andrew Miguelez

      Upon further review, I agree with my original code example in this post. As per https://codex.wordpress.org/Function_Reference/is_admin :

      is_admin() will return false when trying to access wp-login.php

      So I believe the section Exclude WordPress Admins is accurate since it says, “Please keep in mind that this will exclude all logged-in users.“. Though I can surely appreciate the confusion since I used the word “Admins”.