Exclude analytics from dot net core in development

CG - Software Development Director

22/10/19

Google analytics (other analytical tracking tools are available) from a web agencies perspective are commonplace and a necessary evil for most customers.  Without them how do they know their website or web application is being used and working as expected?  

Well, yes, there are ways.  My goto favourite way of checking activity is to read the log files directly.  Otherwise we can check the database for specific entries such as purchases or user signups.  But that’s not what the purpose of this blog.

It’s almost embarrassing to admit, but until recently I wasn’t properly excluding development traffic from a live application.  It was only a “WTF” moment when I wondered “Hey, why is there so much activity in the admin pages?” which prompted both a) a mild panic, and b) to realise the traffic was all on the day and time we had been working on some new administration-only tools.

Silly story aside, here is exactly how I exclude development mode traffic from Google Analytics:

  1. Place all script tags into an environment binding element.
  2. Add an exclusion rule in Google Analytics to ignore traffic from your pre-prod site.

Place script tags into an environment element

The first option is the main point and will cover all of your in-house development exclusions.  Here is a before and after of the page layout of one of our .NET core applications on the Google Tag Manager snippet.

Before:

Standard script block for google tag manager without environment conditional element wrapper

After:

Standard script block for google tag manager inside environment conditional element wrapper

The <environment> tag will determine if the condition (set as an attribute) is met, and if met will render the inner HTML content for delivery to client browsers.  If the condition is not met, is simply not rendered and therefore doesn’t exist as far as the client is concerned.

This is a really nice feature, other alternative approaches involve giving all of the content to the client and then setting or unsetting the usage of different scripts, which can be overridden or manipulated by the end user if they wanted to.

me

Now this is in place, we can dev away knowing we won’t be spoiling any metrics by giving false impressions or false activity.

BUT… what about our pre-production environments?  Fear not…

Exclude your pre-production environment from google analytics

Your pre-production environment doesn’t know its not production.  Therefore it will render and tell its users to load the scripts inside the environment tags.

One solution to this is to add some sort of flag or identifier which would allow us to trigger some clever IF code to exclude the scripts from running, but, as discussed earlier, this is open to false positives and could still be bypassed.

A better solution then is to simply instruct Google analytics to exclude all metrics sent from the pre-production site.  We can do this by filtering all data sent from a given host address.

We will typically adopt a sub-domain for any pre-prod sites, alternatively host using a subdomain of one of our development domains.  As an example, the website being monitored is supercoolapp.co.uk and the pre-production environment is preprod.supercoolapp.co.uk

We can instruct Google Analytics to exclude all metrics sent from preprod.supercoolapp.co.uk.

We do this as follows:

  1. From GA console, click admin (the cog icon)
  2. Click filters from the Website data column
  3. Enter a name for the filter (such as “exclude preprod”)
  4. Select Predefined filter type
  5. Select the 3 following options
    1. Exclude
    2. Traffic to the hostname
    3. That begins with
  6. Enter your preprod hostname (in this example, enter preprod.supercoolapp.co.uk)

And that’s it!  The really cool feature is if you are late to the party and have a pre-prod site already sending metrics, you can click “verify this filter” to see how this filter would affect the current view’s data, based on traffic from the previous 7 days.

We have cookies. Still want to browse? Learn More.