You\u2019ve probably come across a number<\/a> of guides<\/a> or posts talking about why it\u2019s necessary to block so-called internal traffic<\/em> from your web analytics reports. The reasons are pretty solid: internal traffic does not emulate normal visitor behavior, it rarely contributes to conversions (skewing up your conversion rate), it inflates page views, and it wreaks havoc on your granular, page-by-page data.<\/p>\n Internal traffic is vaguely described as \u201cyour employees\u201d, \u201cpeople really close to your brand\u201d, \u201cyour marketing department\u201d, \u201cyour web editors\u201d, and so on. Basically, it should be a term which covers traffic that does not adequately represent trending visitor behavior on your site<\/em>. Most often, this is \u201cinternal\u201d, in that it is traffic by people who generate the content. It can also be your proof-readers (wives, husbands, best friends), beta testers (wives, husbands, best friends), outreach marketers (wives, husb\u2026 you get my drift).<\/p>\n In this post, I\u2019ll introduce two methods to annotate this kind of internal traffic using (mostly) Google Tag Manager. The underlying premise is that your internal traffic comes from such a diverse number of sources that it\u2019s impossible to filter it using Google Analytics\u2019 own filters. Another possibility is that you\u2019ve decided to anonymize IP data<\/a> sent to Google Analytics servers, which means that even if you\u2019d just have a certain range of IPs, you couldn\u2019t use Google Analytics\u2019 filters, since the last octet has been censored (more about this later).<\/p>\n By the way, I use the term annotate<\/em> instead of block<\/em> (except in the search engine friendly title, GUILTY!), because whether or not you actually want to block the data or just segment it is up to you. You could also follow Bounteous\u2019 excellent guide<\/a> on preventing the data from being sent to Google Analytics in the first place, but I wanted to follow a more reconciliatory route, offering a way for you to still incorporate internal traffic in your reports, if you so choose. And this route is, of course, a custom dimension<\/strong>.<\/p>\n \n \n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n <\/span><\/p>\n I will introduce two methods: 1) Visit to URL, and 2) IP extraction. Both have their pros and cons.<\/p>\n If the people you want included in your internal traffic<\/em> are constantly on the move, use a variety of devices on the road, or are hard to pin down just by using an IP address range, you should use the first method. This way you\u2019ll also leave these people an out. You see, sometimes your employees are also your customers or normal site visitors, which means that their behavior should be included in your actual traffic reports.<\/p>\n IP extraction requires that you have specific IP address ranges in mind which you want to block. This is best for traffic which originates from stationary places, like office buildings or office networks.<\/p>\n Whichever you choose, you\u2019ll need to set up a custom dimension<\/strong> first, which will store your data. It\u2019s really simple, and Google has a great guide<\/a> on how to get started.<\/p>\n If you want to provide your internal traffic an out, you should create a session-scope<\/strong> custom dimension. This way internal traffic is annotated separately from one session to the next.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n If, however, you want the annotation to stick \u201cfor life\u201d, you should create a user-scope<\/strong> custom dimension (user<\/em> is the same as device<\/em>). This way the annotation will persist from session to session, even if the IP extraction fails or the user doesn\u2019t visit your designated \u201cinternal traffic\u201d URL.<\/p>\n I really like this method, since it\u2019s completely client-side, it doesn\u2019t require any custom functions or external API calls to retrieve the IP address, and it provides an out for your employees or users, if they wish to be treated as external traffic.<\/p>\n One thing that it does require, however, is that your internal traffic remembers to use the URL every single time they visit your site (unless they don\u2019t want to be treated separately). Since you\u2019re using a session-scope dimension here, it\u2019s ok if the internal traffic URL is not the landing page<\/em> of the visit. A session-scope custom dimension hit is applied retroactively to all hits in the session, so as long as the custom dimension is sent with a single hit during the session, it will suffice to annotate all hits in the session.<\/p>\n I prefer to use a URL query parameter<\/strong> as the trigger that tags the visitor as internal traffic. This means that:<\/p>\n You need to make sure that your server accepts query parameters in URL addresses<\/p>\n<\/li>\n You should canonicalize all pages to the parameter-less version, so that search engines won\u2019t index your internal traffic page by accident (use You should configure your Google Analytics view so that this query parameter is stripped from reports (because it doesn\u2019t add any value content-wise)<\/p>\n<\/li>\n<\/ol>\n For this example, I\u2019ve chosen the query internal=true<\/strong> as the trigger. So if you navigate to the homepage, you\u2019d need to use Here\u2019s how you use the query parameter as a custom dimension in your tags.<\/p>\n Create a new macro (Macro Name: Internal URL<\/strong>, Macro Type: URL<\/strong>, Component Type: Query<\/strong>)<\/p>\n<\/li>\n In the field Query Key<\/em>, add internal<\/strong><\/p>\n<\/li>\n<\/ol>\n <\/p>\n <\/a><\/p>\n<\/div>\n When called, this macro looks at your URL, tries to find the query parameter \u201cinternal\u201d, and if it does, it returns its value (\u201ctrue\u201d). If no parameter is found, it returns an undefined<\/em> which suits us just fine.<\/p>\n Next, you\u2019ll need to send this along with your page view tag.<\/p>\n Open your page tracking tag<\/p>\n<\/li>\n Go to More Settings<\/strong> \u00bb Custom Dimensions<\/strong><\/p>\n<\/li>\n Add the index number of your custom dimension in the appropriate slot<\/p>\n<\/li>\n Add {{Internal URL}}<\/strong> into the Dimension<\/em> field<\/p>\n<\/li>\n<\/ol>\n <\/p>\n <\/a><\/p>\n<\/div>\n And that\u2019s it<\/em><\/strong>! The beauty of Google Tag Manager macros is that you don\u2019t need a separate page view tag for undefined custom dimensions. You can just use this one macro. If the query parameter \u201cinternal\u201d is found, its value (\u201ctrue\u201d) is sent as a custom dimension along with your page view hit. However, if no such parameter is found, no custom dimension is sent<\/em>, so you don\u2019t have to worry about overwriting your data with an empty custom dimension or something.<\/p>\n Finally, check with a debugger like WASP<\/a> that your custom dimension is actually being sent over.<\/p>\n If you or your internal traffic users find that using a URL query parameter is tedious, you should set up a 301 server-side redirection, and use either a vanity URL or a subdomain to handle the redirection. So if A popular way to separate internal traffic from external traffic is to use the client\u2019s IP address. The most common method is to use Google Analytics\u2019 standard features to filter out any IP addresses that are within a specified range. Because this is so \u201cstandard\u201d, I won\u2019t go into it (you can read the official words here<\/a>).<\/p>\n This guide is for annotating<\/em> internal traffic, not for filtering it, so you\u2019ll be checking the client\u2019s IP address against a specified range, and if there\u2019s a match, you\u2019ll send this information via custom dimension.<\/p>\n (Pro tip<\/strong>: This is especially useful if you have IP anonymization<\/strong> set up. In Google Analytics, IP anonymization censors the last octet of the client\u2019s IP (111.222.333.XXX<\/strong>) and sets it to 0 (111.222.333.0<\/strong>). This is what\u2019s sent to Google Analytics servers, ensuring a higher level of security, if you don\u2019t want the geeks at Mountain View looking at your visitors\u2019 IP addresses.)<\/p>\n To extract the client IP, you have a number of choices. The accuracy will vary greatly, since if the visitor is using a proxy, for example, it\u2019s not really their IP that\u2019s retrieved but the proxy\u2019s. In this guide, I\u2019ll introduce you to a simple PHP value retrieval, and also how to retrieve the IP with JavaScript using an external API call.<\/p>\n This is one way to do it, and it should work if you have a site which is parsed with PHP (WordPress, Drupal, etc.). In your page template, before your container snippet, you create the dataLayer object with window.dataLayer = window.dataLayer || [];<\/strong>. Use this to enter the client IP into the dataLayer object as it is created. This way it will be ready when the container is set up and your page views are sent:<\/p>\n This will retrieve the IP address using the designated PHP variable, and it will store it in the data layer variable ipaddress<\/strong>.<\/p>\n This is a great way to extract the IP address, since you don\u2019t have to wait for an external API to resolve the address. Here\u2019s a more thorough guide<\/a> on retrieving the IP with a PHP call.<\/p>\n Next, create a Data Layer Variable Macro through which you can process the IP:<\/p>\n Create new macro (Macro Name: Retrieve IP<\/strong>, Macro Type: Data Layer Variable<\/strong>)<\/p>\n<\/li>\n Set ipaddress<\/strong> as the Data Layer Variable Name<\/p>\n<\/li>\n Set none<\/strong> as the Default Value<\/p>\n<\/li>\n<\/ol>\n <\/p>\n <\/a><\/p>\n<\/div>\n (Why the default value, you ask? Well I like dealing with declared entities, so that I won\u2019t have to check for undefined<\/em> every single time I want to process a variable.)<\/p>\n Next, you\u2019ll need a Custom HTML tag in which you\u2019ll process the IP address. The aim is to push a data layer variable \u201cinternal\u201d: \u201ctrue\u201d, if the IP matches a given address or range.<\/p>\n You have two choices in the code above. Either you do an exact match (if your office has just one IP address), or you check against a range. In the range check, I check if the last octet (111.222.333.XXX<\/strong>) is between 1 and 100, so remember to modify this to match the range you want to check for. And if you have multiple IP addresses you want to include in the check, just modify the if-clause to your liking. You can (and should) also use regular expression pattern matching, if the variations get more diverse.<\/p>\n Whatever you do, this should push the data layer variable \u201cinternal\u201d: \u201ctrue\u201d if the IP address matches a given pattern. Finally, you push a trigger event \u201cipComplete\u201d, which is what will fire your page view tag, with which the custom dimension is also passed along.<\/p>\n The Firing Rule here is {{event}} equals gtm.js<\/strong> to ensure that the code is run at the earliest possible opportunity, to avoid delaying the page view call any more than necessary.<\/p>\n If you can\u2019t use PHP or server-side scripting, you can use JavaScript. Well, you can\u2019t technically<\/em> resolve the client IP using just JavaScript. You need to request the IP from an external resource such as Hostip.info<\/a> or GeoPlugin<\/a>. This means that this approach is a bit more suspect, because you have to trust the request endpoint to serve you with the correct data every time. Nevertheless, if you can\u2019t retrieve the IP server-side, this is what you should try.<\/p>\n I use Hostip.info in my example, but there are a number of APIs out there that you can use. I suggest you find an API that allows you to retrieve the data with an asynchronous AJAX request (you could also use an XMLHttpRequest), and which returns the data as a JSON object that you can then parse. This way your contraption won\u2019t go up in flames, taking most of your website along in its carnival of destruction, if the endpoint chooses to change the way it distributes.<\/p>\n I\u2019ve added the AJAX call to the Custom HTML Tag where I\u2019ll be doing the pattern matching as well.<\/p>\n NOTE!<\/strong> This script requires that you have loaded jQuery<\/a> before this script is run. So make sure the library is loaded first.<\/p>\n Phew!<\/strong><\/p>\n In this tag, you send an asynchronous HTTP POST request to the endpoint at hostip.info. The request returns a JSON script, which you parse for the node \u201cip\u201d. The value stored in this node is then stored in the data layer variable ipaddress<\/strong>. Finally, as soon as the request is complete, you call a function called matchIP()<\/strong>, where the actual parsing takes place.<\/p>\n The parsing is identical to what we did in the PHP IP retrieval script, so you can either evaluate an exact match or a range of IP addresses. With small modifications you can check versus multiple addresses and ranges, if you so choose.<\/p>\n Again, the desired end result is a new data layer variable \u201cinternal\u201d, which should have the value \u201ctrue\u201d, if traffic is internal. It should remain undefined if traffic is not internal, or if an error crops up in your AJAX request.<\/p>\n And again, there\u2019s the trigger event \u201cipComplete\u201d, which is the firing rule for your page view, which will be the vessel for your custom dimension.<\/p>\n The firing rule for this Custom HTML Tag is {{event}} equals gtm.js<\/strong>, because you want to make sure that the script is run at the earliest possible moment to avoid delaying your page view call any more than necessary.<\/p>\n And, finally, we are about to reach the end of this arduous journey. It\u2019s time to modify your page view tag, so that it includes information about the traffic type in a custom dimension.<\/p>\n First, create a Data Layer Variable Macro for your internal traffic.<\/p>\n
\n X<\/span><\/p>\n
\n The Simmer Newsletter<\/strong>\n <\/p>\nThe premise<\/h2>\n
![\"Create](\"https:\/\/www.simoahava.com\/images\/2014\/03\/custom-dimension.jpg#ZgotmplZ\")
<\/p>\nMethod 1: Visit to URL<\/h2>\n
\n
<\/code>)<\/p>\n<\/li>\nhttp:\/\/www.mydomain.com\/?internal=true<\/code> to be tagged as internal traffic.<\/p>\n\n
![\"Internal](\"https:\/\/www.simoahava.com\/images\/2014\/03\/internal-url.jpg#ZgotmplZ\")
<\/p>\n\n
![\"Internal](\"https:\/\/www.simoahava.com\/images\/2014\/03\/custom-dimension-pageview.jpg#ZgotmplZ\")
<\/p>\nPro tip, use a URL rewrite<\/h3>\n
http:\/\/www.mydomain.com\/?internal=true<\/code> is just too difficult to manage, make it so that http:\/\/www.mydomain.com\/office<\/code> or office.mydomain.com<\/code> redirect the user to the home page with the query parameter in place (or both!). If you have an Apache server, you could try something like this for the subdomain redirect (check with IT first!):<\/p>\nRewriteEngine<\/span> on<\/span>\nRewriteCond<\/span> %{HTTP_HOST} ^office\\.mydomain\\.com$\nRewriteRule<\/span> ^$ http:\/\/www.mydomain.com\/?internal=true [R=301,L]<\/code><\/pre>\n<\/div>\nRetrieve and process the IP with PHP<\/h3>\n
window<\/span>.dataLayer = window<\/span>.dataLayer || [];\n window<\/span>.dataLayer.push({\n \"ipaddress\"<\/span>: \"\"<\/span>\n });\n<\/code><\/pre>\n<\/div>\n\n
![\"Retrieve](\"https:\/\/www.simoahava.com\/images\/2014\/03\/retrieve-ip-dlv.jpg#ZgotmplZ\")
<\/p>\nscript>\n var<\/span> ipaddress = {{Retrieve IP}}; \/\/ Retrieves the IP from the data layer\n<\/span>\n \/\/ Comment following three lines if you want to use the IP range method\n<\/span> if<\/span> (ipaddress == \"111.222.333.444\"<\/span>) {\n dataLayer.push({\"internal\"<\/span>: \"true\"<\/span>});\n }\n\n \/\/ To use the following IP range check, comment the previous three lines\n<\/span> \/\/ of code and uncomment the following lines\n<\/span> \/\/\n<\/span> \/\/ var ipRange = ipaddress.split(\".\");\n<\/span> \/\/ var lastOctet = parseInt(ipRange.pop());\n<\/span> \/\/ if(lastOctet >= 1 && lastOctet \/\/ dataLayer.push({\"internal\": \"true\"});\n<\/span> \/\/ }\n<\/span> \n dataLayer.push({\"event\"<\/span>: \"ipComplete\"<\/span>});\nscript<\/span>><\/span><\/code><\/pre>\n<\/div>\n\n
Retrieve and process the IP with JavaScript<\/h3>\n
script>\n function<\/span> matchIP(ipaddress) {\n \/\/ Comment following three lines if you want to use the IP range method\n<\/span> if<\/span> (ipaddress == \"111.222.333.444\"<\/span>) {\n dataLayer.push({\"internal\"<\/span>: \"true\"<\/span>});\n }\n\n \/\/ To use the following IP range check, comment the previous three lines\n<\/span> \/\/ of code and uncomment the following lines\n<\/span> \/\/\n<\/span> \/\/ var ipRange = ipaddress.split(\".\");\n<\/span> \/\/ var lastOctet = parseInt(ipRange.pop());\n<\/span> \/\/ if(lastOctet >= 1 && lastOctet \/\/ dataLayer.push({\"internal\": \"true\"});\n<\/span> \/\/ }\n<\/span> }\n \n var<\/span> ipaddress = \"\"<\/span>;\n try<\/span> {\n jQuery.ajax({\n type : \"GET\"<\/span>,\n dataType : \"json\"<\/span>,\n url : \"http:\/\/api.hostip.info\/get_json.php\"<\/span>,\n async : true<\/span>,\n success : function<\/span>(data) {\n ipaddress = data.ip; \n },error : function<\/span>(errorData) {\n ipaddress = \"none\"<\/span>;\n },complete : function<\/span>() {\n matchIP(ipaddress);\n }\n });\n } catch<\/span>(e) {\n console.log(\"Oops, something went wrong: \"<\/span> + e.message);\n }\n dataLayer.push({\"event\"<\/span>: \"ipComplete\"<\/span>});\nscript<\/span>><\/span><\/code><\/pre>\n<\/div>\n\n
Send custom dimension with page view tag<\/h3>\n
![\"Internal](\"https:\/\/www.simoahava.com\/images\/2014\/03\/internal-ip.jpg#ZgotmplZ\")
<\/p>\n![\"Page](\"https:\/\/www.simoahava.com\/images\/2014\/03\/pageview-tag.jpg#ZgotmplZ\")
<\/p>\n