When utilised correctly, Digital Analytics can be a powerful tool that businesses can leverage to gain an edge in today’s competitive market. However, I still come across numerous businesses that aren’t using the analytics data they have to its fullest potential. At the moment majority of business with an online presence is practicing what I like to call “Wasteful Analytics”.
An end to end analytics process needs to be followed for a business to understand the data it has at its disposal and ensure that its collected, reporting, analysed and acted upon in an effective manner. This article outlines a robust process to help business nail down the collection (implementation) part. We will cover the reporting, analysis & action-taking components in later blogs.
A formal digital analytics implementation process should be followed for every website redesign, feature improvement & functionality update conducted by the business. The process can easily be adapted to the Scrum-style project management which is commonly-used by most digital development teams.
The Digital Analytics Implementation Process consist of these 5 key stages:
- Define Business Requirements
- Create Solution Design
- Develop/Implement the Data Layer
- QA & Validation
- Launch Implementation to Live
Stage 1 - Define Business Requirements
The implementation process should start off by gathering and documenting the analytics requirements of the business. An “Analytics Brief” should be used for this and should capture information such as:
- Stakeholder
- Date of request
- Priority
- Business Question/Brief Description of Request
- Potential Value to Business
Using a standardised format of this document that used throughout the whole organisation would be beneficial for your analytics team as it would make it easier for them to understand, prioritise and plan solutions for the requirements they are receiving.
The volume, complexity and variability of the analytics requirements will depend on the size & maturity of the organisation. Smaller organisations will likely have fewer and less complex analytics requests whereas larger enterprise-type organisations will likely have larger and more complicated analytics requirements. Once all the requirements have been gathered from the stakeholders, consolidating them into a document will be extremely useful for referencing purposes and ensuring that your team keeps on track whilst working on the solution design and implementation stages of the process.
Below is an example of a consolidated business requirements document we use for one of our clients:
Stage 2 – Create the Data Layer Specification & Solution Design Reference Documents
Creating the Data Layer Specification & Solution Design Reference (also known as SDR) documents are crucial for translating the business requirements into the data that will be collected into the organisation’s digital analytics tool. This stage of the implementation process is often overlooked but arguably the most important stage of any digital analytics implementation. Whilst the Data Layer Specification & Solution Design Documents are similar, they serve different purposes through the digital analytics implementation process.
The Data Layer Specification is typically created before the implementation work commences and contains a list of all the variables that will be included in the website/app’s Data Layer along with the values that would correspond to those variables according the different pages, journeys and features of the organisation’s website/app. Ideally, a separate Data Layer specification (but with the same variables) should be created for each section of the organisation’s website/app.
Below is an example of what a Data Layer Specification typically looks like
A Solution Design Document (SDR) is typically created after the implementation work been completed and provides a wholistic view of the variables, events and Data Layer structure of the organisation’s digital analytics implementation. A well-documented SDR can serve as the base foundation which the analytics implementation will build and grow from. It will help provide understanding and transparency for all users of the digital analytics data in the organisation and ensure that the solution is keeps up with the organisation’s requirements.
At Swayven Digital, we recommend building the Data Layer Specification and SDR documents in an Excel format and expand with additional worksheets as the organisation’s requirements, digital platforms, and processes evolve.
Stage 3 – Develop/Implement the Data Layer
A Data Layer is the structure that enable websites/apps to collect timely and consistent analytics data as users navigate through them. The most common way to define the data layer is through a Universal Data Object (UDO) and typically sits in between the Experience Layer and Application Layer.
During this stage of the implementation process, either the analytics developer or web development team implements the Data Layer in the organisation’s website/app according to the Data Layer specifications you created earlier. For websites, we recommend that whoever is implementing the data layer should have familiarity with the CMS that has been deployed on the website. The CMS can be used to add various data points and metadata to the page automatically without you having to specifically deploy variables on each page.
We also recommend that a full specification of your APIs be made available when defining your data-layer, which will help in defining the source of certain data points. For example, if you would need to retrieve the visitor’s first name then you would need a CSM API (or similar) to retrieve it.
Stage 4 – QA & ValidationStage 4 – QA & Validation
Similar to a web development or software engineering project, a digital analytics implementation must always go through a QA & Validation testing phase. This phase is crucial to ensure that the data layer has been implemented correctly and the data collected from the website/app is correctly getting transferred into the analytics tool and appearing as expected.
We recommend that the QA & Validation process should be conducted on the website/app’s development environment. This would allow the flexibility to correct any implementation defects before the website/app goes live.
The QA & Validation process is typically conducted by simulating the customer journeys on the website/app and using debugging tools such as Chrome Inspector, Omnibug, GTM Debugger, Tealium Debugger, Charles, etc. to inspect the analytics server requests.
Stage 5 – Launch Implementation to Live
Once the data layer implementation has been QA’ed and signed-off by the analytics team, it’s time to push the implementation to the live/production environment. In some business cases, the business user who first requested the implementation changes would also need to provide their approval before it it’s launched.
A common practice in these cases would be for the analytics team to provide sample reports to give the business user an idea of what data would look like once the implementation goes live. However, depending on the timelines and urgency of the project, this may not always be possible.
Another best practice is to conduct another QA once the implementation has gone live to ensure that the live data is getting collected into the analytics tools as expected. I have come across scenarios where the analytics data from the development environment is functioning as expected but the data from the production isn’t. These cases are rare but they do happen so be aware!
In order to ensure a robust, effective and valuable digital analytics implementation, an official, standard business process should always be followed. Depending on the nature of business and complexity of the project, the implementation may vary but as long as there is an official process that is documented, it can always be updated and refined as the organisation becomes more skilled at deploying analytics implementations with fewer defects.
Interested in having us build a digital analytics implementation process for your business? Get in touch or email us at [email protected] and we’ll be happy to help.
Thanks for reading!
