Imagine this. You, the data analyst, are ready to present the monthly overview on the performance of the recently launched SEO campaign to your boss. You found a surprising drop on the performance of the specific landing pages for the campaign. You spent a good amount of time to analyze this and think you came up with a decent explanation.

5 minutes before you start, the SEO guy approaches you and offhand mentions that he added a bunch of landing pages and changed some wordings on the other ones and that you should probably adapt your segments you use to analyze the landing page performance…

And now, you’re lost. All the work done for nothing? Just because you probably compared apples to oranges? And all because some other dude changed something and didn’t inform you?

The truth is, it’s not his fault. And it’s not yours. If multiple people work on the same “thing” good communication is fundamental. And where communication is, there are processes. Those processes have to be properly engineered to make the information sharing watertight.

So, how do we make sure to not miss changes other people made to the data we see? In all that mist of Google Analytics, TMS (Tag Management Systems), SEO Tools and Social Media data?

The answer is to always, and I mean always, document changes made to the setup in a reliable way. I give the details below and explain them with an example.

Note: I talk about analytics setups, which in my case almost always included, but is not limited to Google Analytics and the Google Tag Manager. But the process (as outlined below) works for any analytics setup.

The Outline of a Proper Documentation

There are three classes of changes to a web analytics setup that will influence the data:

1. changes to the marketing campaigns (e.g. new banner campaign, changes to utm parameters, competitor launches large topic related campaign)
2. changes on the technical hit collection level (e.g. Google Analytics code added to new websites, code customized in some way)
3. changes made inside the analytics tool (e.g. someone added a bunch of keywords to your SEO tool, someone changed a segment in GA, etc.)

Each type of change should have it’s own place to get documented. Why? Because different people usually commit those changes. And the nature of them differs. So anything else will get messy.

Where to we document those changes?

An Example of this setup

Say you’re currently running one website with Google Analytics implemented via Google Tag Manager. You’re IT department set up the website, so there’s JIRA to keep track of the tickets of implementing the code and possible customizations.

1. Additional landing pages created. If you create new landing pages within your website, this will impact your overall conversion rate, bounce rate, etc. (hopefully, after all that’s the point of landing pages). So everyone who analyzes data like this needs to know about it. So the proper place to document this change in your marketing campaign is the Google Analytics Annotation feature. This way everyone can see it right away while analyzing data.
2. Addition micro site added. If you add your Google Analytics code to a new micro site, you’re making technical changes. Those changes should be kept track of in the ticket system.
3. If you then go on and create a new property for your new micro site, you should document it in a specific Google docs excel using a Google docs form. A perfect example of this is at Online-behavior – Implementation (I adapt this form to track both Google Analytics and Google Tag Manager changes, I don’t think they should be separated).

How do I keep track of what goes what?

Finally, once you set up your documentation system you still need to make sure everyone needs to know where which document is located at. I’d suggest once you create a new project e.g. in basecamp, you also create an “overview” document (e.g. in the Docs section in basecamp) and pin the most important places things are located.

This should include the actual offer, possible ticket IDs, the links to the relevant documentation files and the links to your current implementation best practices.