1. Design using a business requirements best practice library
To start, the organization should be able to review a list of business requirements that have been implemented by many organizations over the past twenty years. The analytics team could review this list of best practice business requirements
with their stakeholders to make sure that the ones they focus on are the most important.
The analytics team shouldn’t have to guess at what business questions can be answered. Instead, they should have a menu of requirements to choose from that incorporates the best thinking about analytics. Otherwise, they may miss out on some great information that stakeholders didn’t even know they could get from their analytics tool. Business requirements should be grouped by site function and industry vertical so it is easy to zero in on the most relevant for each business.
Once the ideal business requirements have been selected, the analytics team shouldn’t be required to know how to design a solution for each requirement. Instead, the best solution for their analytics tool should be available automatically. The solution shouldn’t be dependent upon how much the team knows about their analytics tool, but instead should be based upon what has been proven to work in the past by experts who have tried various approaches and purposely picked the best approach.
2. Enable instant access implementations
At the same time that business requirements are selected, the organization should have instantaneous access to the ideal data layer and tagging specifications
for each business requirement. The act of simply choosing requirements should pre-populate the data layer and tagging specifications. This means that developers are only responsible for populating the data layer they are provided.
Of course, the tag management system used by the organization should also be programmatically configured
so that it supports the business requirements and tagging specifications. Since there is a direct line from business requirement to data layer to code, all of these implementation elements should be interconnected such that a change to one is a change to all.
3. Automatically validate data
Also, since the analytics management system created the data layer and tagging specifications, it knows what data is expected, so quality assurance should be interconnected
as well. This helps ensure that only the right data makes it to the production data set. All of this means that organizations can spend less time implementing and more time actually analyzing data.
4. Programmatically create dashboards
Once data is being collected, the analytics team shouldn’t have to start from scratch to build reporting and training. Since the business requirements that were selected have been used in the past, why not auto-create the appropriate dashboards
and reports for end-users. In addition, if there are segments or conversion metrics that have been proven to be useful for a business requirement, those should be available as well.
5. Built-in capacity-building
Finally, there should be some sort of requirement-level training provided so end-users don’t just learn how to use the analytics tool, but are also trained on how to take action from each business requirement.