In the last post of this blog series on being successful with digital analytics, I shared my thoughts on training internal customers on digital analytics and some of the associated challenges. As I described, teaching people who don’t do digital analytics for a living how to get the data they need and use it correctly can be a monumental task. In this post, I am going to share how shortcomings in documentation and analytics tool administration can compound the problem and offer some ideas to help.
When I audit digital analytics implementations, besides the lack of defined business requirements I bemoaned about in an earlier post, I also am shocked by the utter lack of implementation documentation. As I review each aspect of their implementation, I see names of data points that a reasonable jury would not understand and when I ask for documentation, all I get as the outdated SDR that has very little information. For example, a recent implementation had a metric named “Punchouts” with no supporting documentation. While perhaps employees at the company know that term, would new employees inherently understand it? Even those who do know what it means may not be aware where in the website visit the metric is set without proper documentation. I never like to assume that people logging into a digital analytics tool know what a data point means and where it is set.
Most digital analytics tools provide a very basic way to document data points in the administration area like this:
While I suggest doing much more than this, I am amazed at how few of my clients even bother to fill in descriptions here. Why not describe what the data point is, where it is set and some tips on how it should be used?
I suggest taking it a step further and creating a full data dictionary for your digital analytics implementation. It doesn’t have to be fancy or time consuming and might be as basic as this:
I like to include this type of document directly in the digital analytics tool, possibly on a dashboard that everyone has access to upon logging in.
If you have done a good job of following my homework assignments, your new requirements driven SDR is also a great tool for helping your users understand your implementation. For example, if you are not sure what the “Chat Purpose” dimension is, you can reference the requirements document, find the dimension in the Data Points column and then slide over to see the business objective and requirement that drove its implementation:
I would also suggest that you create a presentation that documents the key events that occur on your website along with the data points that are collected in each website event.
Action Items
Your homework for this post is to:
Make sure you have added a description to EVERY data point in your implementation.
Create a data dictionary with information on all data points in your implementation.
If possible, create a presentation that explains how your implementation is setup. Pretend that you and your entire team were leaving the organization and had to pass on everything you know about the implementation to a team that follows you. What would you tell them? If needed, record videos of you narrating the implementation and save those video files on your intranet and ultimately make them available to anyone who wants it within the organization.
In the next post, I will continue on this theme and share how you can improve the general governance of your implementation to help your end-users.
