One of the fundamentals is often missed when it comes to quality assurance. This is the reasoning for completing the task in the first place: ensuring that your data house is in order. In other words, what you see in your Google Analytics is reflective of what you expect to see. This is, of course, relative to the size and popularity of your website but all in you should have a strong idea of how many visits, sessions and other metrics of that nature, you expect to see show up in your account. It’s always best to ensure that tracking and implementation are set up correctly. Otherwise, the accuracy of the data being pulled into Adobe or Google Analytics could come in question. This is where Quality Assurance testing comes in. This is a simple test to see that your analytics implementations have gone to plan. Generally speaking, they should not entail a lot of technical know-how, as long as the plan (which I will layout shortly) is precisely explained.

Before we jump into the test case, it is worth explaining the difference between two terms that may overlap during this article. Those terms are quality assurance and quality control. Ostensibly, these may appear to sound and act in the same way, and while that may not be entirely untrue, they serve as different terms in this context. Quality Assurance, in it’s simplest of terms, is the test we will be undertaking to review the output of our data. Quality Control is a term that involves a more thorough look under the hood, reviewing the engine in more detail. Generally, a quality control review would occur after identifying any issues during the QA (Quality Assurance) test. It’s worth noting that this isn’t always the cause of action, but it’s the route I take when testing and modifying implementations.

Below is a simple framework to keep in mind when testing data quality, to make things easier when following along. This framework will go a long way when reviewing the effectiveness of your implementations and tests. The framework is the lifecycle (steps) to ensuring data quality.

1. Define the business process, data rules, data goal and stakeholders involved.
2. Measure existing data in-line with the above data rules and subsequent goals.
3. Analyse existing data against the data quality goal. (Generally, this takes the form of gap analysis.)
4. Based on the Analyse (3) findings, improve, with a new initiative to solve the issue(s) raised.
5. Implement business and technical solutions device at the Improve (4) stage.
6. Control (and measure) the data to assess non-biased implementation, in-line with the data rules, goals.

At the final stage (6) the data should then be in a good place to monitor. In other words, this should be included in any business reporting or dashboard to review daily or weekly for updates. This will form the basis for future data initiatives, so tracking is essential to record progress and mitigate errors.

A test plan is usually undertaken right before an element, page or template goes live on a website. I wanted to include it in here as it’s an entirely relevant sub-step to quality assurance. Consisting of two components, the final plan isn’t quite as taxing as a full QA plan. With that being said, this should not replace any QA work you are doing. The two have different purposes but ultimately help with ensuring accurate web and data functionality.

The linked scorecard case study has more detail on the terms above if you need more clarity on the definitions and use cases. A test plan should only concern one section, page or template. This isn’t a site-wide test, but, in other words, more akin to an A/B test of sorts. The first step is to list a series of interactions a user can make on a given page or element. Then, for stage two, list the data you expect to see from said interactions. This could be metrics as basic as hits (sessions, clicks, etc.), listed individually against the aforementioned actions a user takes. A thought to keep in mind is that this process should instil trust in the data you are working with.

If you wanted to add more detail to the test plan, you could also add in stakeholders responsible, method of delivery and tooling. However, for this example, this is where it ends. And while that last step isn’t being done here, it does not make it unimportant. With that being said, from the examples of test cases and research here, you should have an idea of how far you would like to take the evaluation.