How SDR improve web analytics data governance

What is SDR?

A Solution Design Reference (SDR) is a document that contains the list of web analytics variables/events used and the data layer structure. It can also be expanded to include full details of tags, if they are not already documented in a separate file.

Why is SDR important?

Without a SDR, it is nearly impossible for anyone else to understand what exactly has been implemented and what the data stand for. SDR can help us:
  • Understand in detail what each piece of data stands for
  • Ensure the completeness of data to track every single KPI
  • Visualize the data shown in reports
  • Develop a comprehensive data layer structure
  • Keep track of all the tags implemented
  • Ease troubleshooting during implementation and testing phases
A properly documented SDR will act as the base foundation which the analytics implementation will build on. This will greatly increase transparency for all parties involved and ensure that the analytics solution is built to scale.

Who should be in charge of SDR?

It greatly depends on the scale of web analytics adoption in a company. For a company that has taken web analytics seriously, there usually is a data governance body who will determine the analytics strategy and provide the necessary framework to ensure that the analytics implementation collects the data necessary to answer all the objectives (KPIs). For web analytics implementation of a smaller scale, the analytics guy/implementer will need to own this very important piece of documentation. Having identified the owners, it is their responsibilities to ensure that the SDR is made available to all parties involved (Business users, web developers, UI/UX developers, marketers, etc). SDR is a dynamic and ever-changing document. Anyone can contribute by suggesting new KPIs to be monitored, which will trigger changes to the SDR.

What are the components in SDR?

4 most important components of SDR:
  1. List of variables/metrics
  2. List of events
  3. Data layer structure
  4. List of tags

1. List of variables/metrics

This list will contain all the data that we will need to capture in order to monitor the different KPIs. It is advisable to clearly document the purpose and usage of each variable/metric. This will allow different stakeholders to have a good idea which data are important to them and if their questions can be fully answered with the data captured. De-duplication will be key, as there is a limit to how many variables are available for use (eg. Adobe – 200). Even without the limit, it is important to ensure data cleanliness to avoid confusion in future reporting. Nothing is more confusing than to have multiple variables representing similar purposes.

2. List of events

This list will contain all the events that we will need to capture in order to identify key user interactions on the website/mobile. Some examples of events:
  • Click of button/tab/link
  • Play of video
  • User login
  • Cart addition
  • Form completion
  • Page scroll
Keep in mind that events represent key user interaction, and should not be confused with the data stored in variables. Through proper planning, we can minimize inflating the event list as events can be re-used to a huge extent. A simple example will be a click of a web element (button, tab, link, etc).

Simple Setup

Without proper planning and understanding, it can be tempting to allocate 3 events:
  • Event 1 – Button click
  • Event 2 – Tab click
  • Event 3 – Link click
On top of that, we will need to store the name of the web elements:
  • Variable 1 – Button name
  • Variable 2 – Tab name
  • Variable 3 – Link name
This setup (3 events + 3 variables) works, but it uses more events than necessary.

Optimized Setup

Consider a more optimized setup (1 event + 1 variable):
  • Event 1 – Web element click
  • Variable 1 – Web element name
How does this work? Simple.
  1. In the report, display the number of instances where Event 1 (Web element click) was triggered
  2. Break it down by Variable 1 (Web element name)
In this way, you will be able to see how many times has a web element (named xxx) been clicked. But there’s still one question left. How do we determine whether the web element is a button, tab or link? By appending prefix to the value stored in Variable 1, we can differentiate the web elements!
  • For button, append “b_” to the name of the button
  • For tab, append “t_” to the name of the tab
  • for link, append “l_” to the name of the link
In this way, we have not only simplified reporting in the future by presenting all the necessary information with minimal steps, we also ensure that the lists of variables and events are kept manageable.

3. Data layer structure

Data layer is crucial for data governance and provides a structured way of passing data from the website to the report database. If you are unsure of how data layer works and how can it help you, we have an article right here to guide you. Benefits of documenting data layer structure down:
  • Give web developers a reference on the kind of data to capture and how to store them
  • Allow analytics implementer to figure out what are the data he/she can work with, to come up with business-friendly values to be used for reporting
  • Ensure that changes made to the data layer structure are tracked and made known to all relevant parties
If you do not already have a data layer, create one now!

4. List of tags

If you have a Tag Management System (e.g. DTM, GTM, etc), you would have all the tag details stored in it already. Having said that, regardless of whether you have a Tag Management System, it is still advisable to store the tag information in a documentation for referencing purposes. Here are 4 reasons why we choose to store tag information in a documentation:
  1. Provide easier reference for all parties
  2. Restrict the number of users who can access the Tag Management System
  3. Act as the authoritative source to validate changes made in the Tag Management System
  4. Act as the single source of truth when there is no existing Tag Management System
Now that we have established the importance of having the tags documented down in the SDR, it is time to identify what are the tag details required. Here are 5 important details of tags that need to be captured in the documentation:
  1. Tag name
  2. Purpose of tag
  3. Data layer mapping (for web developers)
  4. Code snippet for tag (for web developers)
  5. Data/Event mapping in Tag Management System

In Conclusion…

We have covered the importance of SDR and how does each of the component contributes to a better data governance. For new projects, it is of utmost importance to start on the right foot by creating the SDR right away. For ongoing/existing projects, do take some time to start the SDR and slowly supplement it with information. Creating the SDR from scratch for an ongoing/existing project can be daunting, so take your time, build the components one at a time. Every little effort spent on building the SDR can only benefit you and your company in the long run. Remember, Web Analytics implementation is a never-ending process. New requirements, requirement changes, KPI changes, tons of things that will require us to revisit the whole process again and again.
About admin 30 Articles
Analytics Consultant who loves numbers and data! In love with Adobe Analytics.

Be the first to comment

Leave a Reply

Your email address will not be published.


*