Today I was asked by a customer to filter out their internal IPs from all DMS reports.

There are two approaches for obtaining this. Either very simply add the IP addresses to the Sitecore.Analytics.ExcludeRobots.config as excludedIPAddresses.

But I did not like this approach. The customer editors are not robots, so this is messing up domain entities.. Instead I took a different approach and simply wrote a new processor for the startAnalytics pipeline.

Excluding IP addresses from being tracked

First I wrote the processor which simply checks if the UserHostAddress of the current request exists in a static list of IP addresses.

Then I wrote a repository which reads the excluded IP addresses from config using the built-in IPList class from the Sitecore API.

The IPHelper.GetIPList(XmlNode) method expects a list of IP addresses or ranges separated by linebreaks or semi-colons.

Then I patched the IP addresses into config in a new .config file and patched the new processor in the beginning of the startAnalytics pipeline.

That was it, including sipping some coffee and waiting at the coffee machine, the actual implementation took less than an hour to complete. One might argue that it would have been faster just to add the IP addresses in the excludeRobots configuration but as I wrote in the beginning of the post, the editors are not robots and I don’t like calling something a name which it isn’t just because it is easier. In the long run this always leads to confusion and messy code.

Notice that this implementation does not work if you manually start the tracker elsewhere in code.

Considerations

A completely different take on this task could have been to create a new traffic type in DMS called Internal which we then could mark all internal visits with so the customer could filter these visits out in their reports but still include them if desired.

This could be done by adding a new entry in the TrafficTypes table in the analytics database and then add a new processor in the trafficTypes pipeline.

This processor would then evaluate the IP in the same manner as shown in this post but instead of stopping the tracker then it would return the new custom TrafficType in the pipeline arguments.