Several years ago when I worked as a trainer at Adobe, I had a client reach out to me asking me to teach their team about implementing and using Adobe Analytics. I was happy to help, but was surprised when I examined their site and discovered that Adobe Analytics was already implemented.
I asked, “Why do you want to learn how to implement analytics if you’ve already got it all set up?”
They responded, “Our developer just left, so we need to be able to start where they left off.”
So I asked, “Okay, why don’t you give me your solution design reference, or any analytics documentation you have for your site?”
Silence. They had no idea what I was talking about. Their developer had never documented their analytics implementation, or if she had, was the sole owner of the documentation and never passed it on after leaving the company.
As a result, my client was blind to their own implementation, a position you do not want to be in.
The Solution Design Reference
The solution design reference (SDR), sometimes known as a variable map, a tech spec, or an implementation plan, is a key component of your company’s data governance strategy. It’s a blueprint of your MarTech architecture, describing how each technology ought to collect, manipulate and distribute data.
Documenting your implementations not only makes it easier for a developer to implement your analytics, but it allows you to confirm that the data you’re collecting is what you actually intended to collect. In other words, it is a tool to help you validate the integrity of your data.
The problem is that companies often approach SDR creation as a once-and-done or a once-in-a-while process, instead of as part of a continuous data governance strategy that frequently revisits what should be a dynamic, high-touch document.
Web and mobile technologies change rapidly, especially since data layers and TMSs have made onboarding new technologies immensely easier. SDR maintenance needs to match that cadence.
Reverse Engineering an SDR Using Automation
Because this client didn’t have documentation or an automated tool to generate documentation, the company had to manually reverse engineer their analytics implementation so they could have a baseline to work from. It was either that or start over. It was a painful process, one that could have been avoided with stronger data governance practices.
Thankfully, automation is possible.
Data from automated data quality management audits can be leveraged for SDR documentation, saving you tons of time. These audits capture some of the most pertinent information necessary for a compelling SDR, and can be repurposed for data governance documentation.
Tim Munsell, Lead Web Analyst at DaveRamsey.com, applied this process:
“The report we get from ObservePoint is a more useful and accurate reflection of our implementation than our original documentation. We are able to export our audit to Excel and essentially work backwards, making sure that the data collected on each page on our site matches our business requirements.”
Not only does the ObservePoint technology help you build a comprehensive solution design reference, but it helps you validate your data against that SDR. It shows you what is currently implemented on your site and allows you to test and validate your tags across your digital properties.
Mapping your tag audit data against your existing SDR on a continuous basis will help you keep a pulse on your data governance strategy, so that even if your developer leaves, you won’t be left in the dark.
To learn more about how ObservePoint can help you generate an SDR from your current implementation, check out the SDR Builder.
About the AuthorLinkedIn More Content by Matthew Maddox