0115 964 8205
Recently we’ve begun to notice a local host address showing up in a fair few Analytics accounts.
Not only is a pretty odd, it’s also skewing data, which of course isn’t great.
Notice how each perceived session instantly bounces at 0:00. Not huge numbers but 156 of those is sure going to bring your averages down if bounce rate and time on page is one of your KPIs.
A few different variations of this localhost IP have been reported including:
Maybe there’s a correlation to the pages receiving this phantom referral data from 127.0.0.1:8888. In Behaviour -> Site Content -> Landing Pages, a secondary dimension of Source can be applied to do just that.
Checking the first instance, we noticed that every landing page impacted has been a landing page for an AdWords campaign, including a PPC-dedicated page with a noindex tag.
Coincidence? Maybe but we could be on to something.
The next logical step would be to repeat for every client with referral traffic from 127.0.0.1.888/orange.html and other variations.
We found the same scenario with a second, third, fourth and so on client. There’s a pattern starting to emerge.
Looking at properties that run no ads at all, there is no recorded traffic from localhost. That’s surely enough to assume that this only affects sites using AdWords.
Interestingly enough, looking at location data seems to suggest a big chunk of incoming sessions from Michigan. The majority of our clients with these referrals don’t deal with the US at all. A sudden surge would be odd, even if it was genuine.
There seems to be massive jumps from Lansing and Detroit correlating with an influx of referral traffic.
That’s all well and good but it still doesn’t mean anything at this point. All we have is a bunch of additional ‘traffic’ wreaking havoc on our data.
Now see what happens when we set a secondary dimension of Service Provider:
Is this some kind of Google product or platform registering referral traffic? A quick look on the Google careers site [[https://careers.google.com/locations/]] tells me that, what do you know, there are Google offices based in Detroit.
We’ve amassed a few clues now:
We can’t say for sure, but it seems Google is testing something, or has made an error somewhere along the line.
Perhaps an ad-specific crawler to check landing page quality and the like? We don’t know. What we do know, however, is that we should exclude these visits from our data.
To stop this data from marring our real insights, we can filter it out. It’s pretty easy to do and very effective.
Remember – it’s always a good idea to keep a raw data view with no filters. You also won’t be able to retrieve any filtered data from a filtered view, it’s not recorded or saved. An unfiltered view will keep you safe if you accidentally use a filter that you shouldn’t have.
Click the admin button, right at the bottom left of the page.
On the far right side under View, find the Filters tab and click it to create a new filter.
The name is unimportant, just make it easily identifiable in case it’s needed for reference.
To remove 127.0.0.1:8888 in Analytics, fill in your fields like so:
Once saved, this will prevent future sessions from being recorded.
Alternatively, you may want to remove Google LLC as a whole. If any traffic creeps through under another medium, direct for example, this will be excluded too.
Follow the same path as before but this time, use the following fields to exclude a specific ISP in Analytics:
We’ve cleared up any future problems now. Our data is still home to our ghost referrals, though. We can eliminate it from historical data by using an advanced segment.
Follow these steps to remove spam from Analytics data.
Alternatively, replace exactly matches with contains and type 127.0.0.1 in the field.
The data within Google Analytics should have any skewed source data excluded.
If not, you should be able to find your newly created segment in the list when clicking Add Segment.
Over the last few weeks, the amount of ‘referral’ traffic seems to have significantly slowed and in most cases stopped altogether.
It’s certainly still worth implementing the elements in this post if you have been affected at any point.