A Perfect Example of Why You Should Do a Pre-Migration Google Analytics Audit

In Analytics, The Digital Marketing Blog by Scott0 Comments

Est reading time 8 minutes

I couldn’t think of a more specific title for this post.

I will deliver exactly what I have promised, one very specific example of why pre-migration Google Analytics Audits are critical.

If you are struggling to help someone understand why they should audit Google Analytics at all, this post and the image below provide you with substantial ammunition.

If they don’t, email me and I’ll see what else I can do to help.

I won’t stop banging on about this.

Years ago, someone (I forget who, sorry) told me a story about a digital agency that had lost a client following a migration because their client’s post-migration organic traffic plummeted. The client was furious and handed in their notice within a couple of weeks.

It was only several months after the client left that they realised, organic traffic hadn’t decreased at all. In fact, the old site had been double-counting sessions due to two instances of Google Analytics code having been implemented on the majority of pages. This had gone undetected.

When (unknowingly) this issue had been fixed on the new site, the data in Google Analytics gave the impression that traffic had dropped.

Wow. What a dumb reason for losing a client.

This story stuck with me. In the years since, whenever someone has asked for my advice on anything migration related, I’ve always made a point of referencing the need to undertake a pre-migration Analytics audit. Probably so much that I’ve irritated people.

I have often walked away from these conversations not entirely satisfied that the person I am speaking to will follow through with my recommendation. In a lot of cases, they haven’t.

Why?

I am not 100% sure.

Perhaps:

a) I am really rubbish at explaining things.

b) The recipient of this recommendation was too busy to listen to me.

c) Migrations can be big, intense projects. In digital, most people are so focused on the SEO implications, that other migration factors can become “out of scope” or afterthoughts. When a Google Analytics Audit isn’t budgeted for, it can feel like an unnecessary, additional migration cost.

d) The recipient needed to visualise what I was saying in order for it to really sink in.

My guess? A combination of c and d.

If it’s a, please stop nodding and lying to my face. Someone is going to lose money.

I don’t want people to disregard the importance of Analytics auditing during a migration.

I don’t want people to be fired unnecessarily.

I want to give you an example you can keep coming back to.

A recent example.

Double Counting Google Analytics Example

About a month ago, one of my colleagues came to me with screenshot above.

I was so happy.

Here’s the story with this particular client.

Back in July 2015 this client informed us that they were going to be undertaking a migration project in the next 3-6 months.

Aha. Another great opportunity for me to poke my nose in and recommended a Google Analytics Audit.

Somewhat unfortunately, the aforementioned scenario I discussed in the opening of this article played out once again. On a budget, the focus shifted to the organic search factors related to this client’s website and there wasn’t budget available to assess or resolve this issue at this time.

Fortunately, the importance of an audit early was highlighted to the client early enough for this to be considered at a later date. A Google Analytics project was scheduled for a later date, once the SEO factors had been fully assessed.

There are a couple of good lessons here:

  1. Have the conversation early.

Migrations are stressful. There’s no getting round it. They don’t have to be, but they often are.

No matter your position, you don’t want any unexpected obstacles or costs during a migration. They can be annoying and upsetting.

This makes it easy to bury your head in the sand and reluctant to raise non-SEO factors in fear of being seen as disruptive. My only advice is to speak up, you really will be saving someone else a headache. At least if you say something, it’s on someone’s radar.

  1. Don’t give up.

Let’s say you or your client doesn’t have a whole lot of budget. It’s completely understandable to focus just on the core SEO elements of a migration.

But, don’t let Analytics slide. Build out the scope of non-SEO migrations elements and ensure you revisit them at a later date.

Otherwise, you’ll get so wrapped up in the migration process that you’ll forget about Analytics and any data collection issue will continue to slip under the radar.

So, what was the issue with this client?

In this instance, the client had upgraded to Universal Analytics via Google Tag Manager but did not remove the previous Classic Analytics code from the page.

This resulted in two (and in this example, sometimes more than two) sets of Analytics code on the page, causing multiple sessions to be recorded.

How did we find this out?

  1. Via a Custom Google Analytics Intelligence Event that was set to for session increases.

Please, if you only do one thing today, go away and set up Custom Alerts for session increases. At a minimum, I would recommend a Custom Alert for All Sessions that increase by 50% or more compared to the same day in the previous week.

A lot of people make the mistake of just focusing on Custom Alerts for traffic decreases. Setting alerts for traffic increases can alert you to any unusual tracking behaviour (such as double counting) but it can also help keep you in the loop of any positive trends that you can capitalise on (such as an increase in a referral sessions).

  1. Monthly reports.

In this scenario, a monthly report highlighted the unusual increase in year on year session data.

  1. Confirming the reason for double tracking.

This was the fun part.

In August 2015, Google released a brilliant new feature to the Chrome Tag Assistant extension called Tag Assistant Recordings. It was my favourite new Analytics tool that was released in 2015.

In short, it allows you to record yourself navigating your way through your site and when you stop recording, you can create a report which shows you how data would have been reported in your Google Analytics view. In addition to this, there is lots of other data around errors, code conflicts, code warnings etc.

It’s BRILLIANT. Go play with it. Tell me what you find.

Running through this process highlighted to us that indeed, there were issues with multiple sessions being recorded.

  1. Confirming the severity of double tracking.

Quick note: I keep using the terms double counting and double tracking.  I actually don’t like these terms because in some cases, it can be more than two sessions recorded in Google Analytics. So, just know I am talking about inflated session counts when I use this terminology.

Ok. So now we knew that there were indeed some pages that were causing multiple sessions to be recorded.

The next question was: Just how many pages is this likely to be occurring on?

This was even more fun to answer.

I started out by exploring a range of potential existing solutions (Screaming Frog Custom Extractions, WASP, Observepoint etc.).

In the end, none of these gave us quite what we needed. So we built our own and called it the Tracking Coverage Report.

Here’s a peek:

SiteVisibility Google Analytics & Google Tag Manager tracking coverage report

SiteVisibility Google Analytics and Google Tag Manager tracking coverage report example 2

Pay attention to the arrows above and you’ll see that almost all pages on the site had more than one Google Analytics tracking code as well as containing a Google Tag Manager container.

So, we knew that the issue we had identified was likely to be site wide.

What happened next?

During the migration, the client removed the double-tracking and this resulted in “clean” data being collected post-migration.

Double counting Google Analytics example

What to look out for.

There are a few other common scenarios that result in double-tracking. These include:

  • Upgrading to Universal Analytics and failing to remove Classic Analytics code
  • Installing multiple Google Analytics WordPress plugins instead of using just one
  • Implementing Google Analytics via Google Tag Manager and failing to remove old Google Analytics code

What else can affect Google Analytics data during a migration?

  • Changing from Classic Analytics to Universal Analytics
  • Implementing Google Analytics code or Google Tag Manager container in different positions in the source code
  • If you make any custom Google Analytics configurations (e.g. custom bounce rate)

Why else are pre-migration Google Analytics Audits useful?

Aside from identifying issues relating to session inflations, undertaking Google Analytics Audits during a migration can help open up further conversations relating to performance measurement.

In turn, this can help remind all parties that with a new website comes new conversion considerations and so it’s a good time to revisit both goal and event tracking as well as updating any measurement plans you have in place.

These new tracking configurations can subsequently be tested on a staging server, so that when you do launch your new site (or make significant changes to your website), you launch safe in the knowledge that you’re accurately collecting the data you care most about.

Conclusion

Undertaking a Google Analytics Audit before you migrate can help prevent the misinterpretation of post-migration data.

In addition to this, it’s a great time to consider goal and event tracking for a proposed new site so that you can start accurate performance measurement as soon as you launch.

I hope the next time you or your client is considering a migration, you consider undertaking a Google Analytics Audit.

At very least, you put it on people’s radar.


If you’re thinking about undertaking a website migration, take a look at our Ultimate SEO Website Migration Checklist

Related Posts Plugin for WordPress, Blogger...

Leave a Comment