In today’s Big Data world, where companies are drowning in data but often starving for insight, organizations can no longer afford to simply live with an analytics deployment slapped across digital properties by web developers or the IT department as an afterthought.
Companies jockeying for position in a highly competitive space, seeking to win consumers who are more empowered than ever before, must treat their data like an enterprise asset—perhaps the most valuable one they have.
It’s time for a business objectives-driven approach to deploying your data collection technologies, and this starts by creating a solution design reference (SDR).
What is a Solution Design Reference?
Referred to by myriad names, including: variable map, tag plan, solution design, tech spec, site reference and more, a solution design reference (SDR) is the documentation of your digital analytics strategy and process—a foundational piece of your data governance framework.
A solution design reference is the blueprint for your analytics implementation.
An SDR takes business requirements identified by stakeholders throughout your organization and maps them to metrics that can be measured across your digital properties.
The SDR helps analytics architects know where, when, and how to implement code.
Why You Need an SDR
An SDR creates a baseline for data governance processes, to ensure organizations are maximizing the ROI of their MarTech stack and collecting high-quality data to make strategic business decisions.
“Data Governance programs have a way of starting and then fading away. This creates peaks and valleys in an organization’s ability to engage relevantly with their analytics program. Forrester finds that 45% of organizations govern data inconsistently across business units.”1
Documentation is essential to collecting and governing high-quality data. Without an SDR:
- Business initiatives fall through the cracks
- Analytics efforts fail
- Code degrades
- Data quality suffers
Establishing a Solution Design in 7 Steps
This white paper details 7 steps that support establishing and deploying a robust SDR across analytics teams and organizations.
Designed to build on one another, each step steers your team towards greater data governance capability in a simple and scalable way.
- Ownership of the SDR
- Location of the SDR
- Collecting Business Requirements 4. Defining Metrics to Measure
- Building the SDR
- Coding the SDR
- Maintenance and QA
Whether you are building a solution design in-house or utilizing the services of an expert agency, ensuring each of the above areas is addressed sets your team up for success.
Step One: Ownership of the SDR
There are two critical points of leadership for establishing the SDR and creating a culture of true data governance in an organization.
Data Governance Leader
With direct ownership of data governance and quality in an organization, a data governance leader should have the correct background and authority, including:
- A strong technical background
- Familiarity with MarTech solutions
- Knowledge of the platforms their digital properties are built on
- Organizational seniority
- Understanding of the business value of data
- Thorough data orientation
Industry research indicates that organizations with a dedicated data leader, what Forrester calls a Chief Data Officer, are top performers:2
Data Governance Council
In supporting the data governance leader, a data governance council should be composed of business leaders from all areas of the company who understand their unique business objectives and the company mission. A data governance council should:
- Incorporate leaders from Marketing, Sales, IT, Operations, Finance, Human Resources, etc.
- Respond to requests of the data governance leader • Meet at least quarterly to review the SDR
- Be a strategic priority
The key to having an effective data governance program is to prioritize and maintain it. A regular meeting of the data governance council might include the following:
- Review quality assurance notes on the latest implementation
- Discuss any outstanding actions on your implementation, such as inactive tags
- Review the business requirements and discuss potential additions
Step Two: Location and Format of the SDR
Treat your SDR as a living, breathing document.
“Governance needs to become more agile by means of dynamic collaboration.”3
Step Three: Collecting Business Requirements
Every business has unique objectives and data needs. An SDR should always be aimed at understanding these needs in order to provide an actionable and accurate measurement and implementation plan.
Identifying your business requirements begins with business questions:
1. Why are we doing this?
2. What do we want to know about the user?
Example: If you would like to know the channels visitors use to reach your website, you can include that as one of your business requirements.
Answering the initial questions around identifying your business requirements usually involves asking another question like, "What is their objective for being on our site?" These secondary questions will lead you to determine specific use cases.
Your business requirements should articulate, specifically, what you want to know about the user experience (UX).
Example: You might be wondering, “Are visitors to the site finding the content that they are looking for?” Or even just, “What are visitors looking for?”
You can quickly generate a list of unorganized questions, and then work to focus your collection. This will save you more time throughout the next steps of building your SDR.
Collecting Business Requirements
Analytics Demystified experts recommend categorizing the business objectives your stakeholders want to know and then mapping each question back to the appropriate category, or use case.
So, your collection document might look something like this:
Step Four: Defining Metrics to Measure
Ask yourself, “What story does this metric tell? How can it help leadership make the right decisions?”
Every metric should be mapped to an end goal.
Once the data governance council has established what they want to discover, analysts and developers should work together to define appropriate metrics to generate actionable insights.
One of the challenges in this is that while analysts may have a solid understanding of how the data that is unique to each business goal should be analyzed and represented, they are often working with stakeholders who may not.
Generating example reports helps address this common disconnect.
It is tempting to skip this step because it is time-consuming, but generating mock analytics reports has several advantages, in that it:
- Validates that your team is collecting the right information
- Shows stakeholders they will be able to make decisions about their digital asset with these reports
- Helps your analytics team understands the business requirements
- Provides an opportunity to refine your metrics
- Lessens the likelihood that your team will have to go back and implement tracking that was overlooked during initial discovery
Here are some questions to ask:
“Are my visitors finding the content that they are looking for?”
If a user is looking for something on your site, they will most likely utilize the internal search function. Businesses must consider user search actions and how they can be measured.
The second part of the business requirement is:
“Did they find what they were looking for?”
This can be measured by whether or not their search yielded results. The metric that combines these two use cases would be an internal search that yielded results.
“Are visitors getting the information they need from the frequently asked questions section of my website?”
A corresponding user action could be clicking a link to the FAQ page or expanding a FAQ field. You can monitor the frequency of clicks on certain FAQs to understand what your visitors want to learn more about.
Step Five: Building the SDR
An SDR concisely outlines all the events and coding details to help your data governance council and designated programmers maintain coherency and consistency with your metrics.
Once you have decided on a specific event for each metric, you can begin assembling your SDR.
Make sure that you give your SDR a name that is clear and concise, along with some context, like the website name and some sort of timestamp.
A comprehensive SDR is a matrix of use cases and variables. It should contain similar information to the chart provided.
Step Six: Coding the SDR
A completed SDR will provide programmers all the necessary information to code an effective analytics implementation that produces actionable data.
The SDR will serve as a reference point for all who collaborate on the project in the short and long terms.
Once you have documented your SDR, your team can really dive in and start programming the implementation in a staging environment.
This will usually be done by an IT team, but with the amazing power of some tag management systems, marketers can also build analytics rules themselves, easing demand on the IT department.
If you don’t have the resources to code your implementation in-house, don’t be afraid to work with a contractor or an agency that specializes in analytics implementations. The only thing worse than no data is bad or misleading data—and you could save yourself a lot of frustration and headaches if you outsource this essential task to an experienced analytics firm.
Step Seven: Maintenance and Quality Assurance
Validate your analytics implementation against your SDR during staging, development and after release.
Missing, misfiring or duplicate tags can result in incomplete or misleading data, which destroys confidence in your data for decision-makers. Always double- and triple-check your tagging integrity, even when using a tag management system.
When to Perform QA:
- In a staging environment before releasing your implementation
- After releasing your implementation
- Periodically to ensure that any updates or changes have not affected the functionality of your implementation
Automated Quality Assurance
Tag management systems have made it extremely easy to build and deploy code, both for programmers and marketers. If not properly regulated, however, this can lead to issues with your implementation. Massive amounts of tags deployed on multiple sites, with subdomains and different languages operating on different browsers, can make monitoring and maintaining all of these implementations a very sticky job—one that takes thousands of hours of manual spot-checking and validation.
Thankfully, automation is possible.
Constant validation allows you to keep your baseline true.
With an automated QA solution, rule-based scans can be used to run audits on thousands of pages to ensure that your analytics tags are firing correctly, according to the expectations established in your solution design.
Active critical-path monitoring notifies you if your critical paths are functioning properly so that users can move through your site towards conversion.
Automated Audit Example
Automated analytics tools save you time and manpower for maintaining an effective analytics implementation.
Here’s an example of an automated audit from a popular website. This audit covered 100 high-traffic pages.
- 454 duplicate tags indicate inflated data
- 6 failed business compliance rules means 6% of pages aren’t collecting data as expected. These rules can be set on the variable level— in this case pagename is missing.
- Only 84% of pages with status 200, leaving 16% of pages likely suffering from excessive redirects, risking SEO scores. Another possibility is that some of these pages are returning 404 errors, meaning your visitors can’t find content.
- 9.6 seconds for average load time is well above the three-second acceptable average, suggesting potential high-traffic loss and unfired analytics tags.
This quality assurance audit took about 5 minutes from set-up to completion and provides the URLs where issues occur so they can be addressed immediately to promote your data to trustworthy quality.
Summary - 7 Steps
1. Ownership of the SDR
2. Location of the SDR
3. Collecting Business Requirements
4. Defining Metrics to Measure
5. Building the SDR
6. Coding the SDR
7. Maintenance and QA
Building a successful analytics implementation is essential to understanding and responding to user behavior and maximizing the functionality of your website. Tag management systems, automated quality assurance and other analytics tools have simplified the process of deploying and maintaining analytics implementations.
The best way for your organization to accomplish your goals is to really take control of your data governance and develop an SDR outlining all of the business requirements that you hope to achieve through your implementation.
Doing so emphasizes that your marketing data is an enterprise asset—one that drives your competitive advantage and ultimately your bottom line.
To see how ObservePoint’s automated tag governance solution can help your business, schedule a demo.
About the AuthorLinkedIn More Content by Jason Call