All of it. That is one of the most common stakeholder answers to the question: What data do you want to track? It can be more valuable to identify and collect the actionable data points than to record every possible element. Identifying those data points efficiently requires a basic plan and creative discussions with the stakeholders.
If a data point provides a clear or plausible input to some analysis or optimization, then it is worth capturing in Adobe Analytics. If not, then it should be considered out of scope for now. It requires incremental effort to collect all possible data points and to maintain those collection processes. If you surround the useful data points with hundreds of irrelevant elements, you will hinder adoption for the consumers of your data!
An Analytics administrator can often identify data that matters, but not always. Where standards and best practices are common, as with typical web page interactions, the important data is easier to identify. However, as new digital innovations, customized analyses, or specific business objectives are involved, the important data can’t be identified confidently except through collaborative stakeholder interviews.
There is an art to efficient communications with others regarding their needs – or what they perceive to be needs. If you communicate like a detective, especially one who is unfamiliar with the local culture, you will help both sides identify the goals, wants, and needs more clearly. Assume nothing and ask for clarification about everything!
Companies, business units, and teams have a unique culture and related language. Especially when buzz words and acronyms are involved, ask follow-up questions to ensure you and your stakeholders properly understand one another.
Establish some principles before the discussion. As the Analytics administrator, you need to acquire the right inputs to develop and provide the ideal solution for your stakeholder.
Send a list of questions for your stakeholder to review before the discovery meeting. They can provide answers upfront or simply become familiar with the discussion topics. You can provide sample answers along with the questionnaire if that will clarify expectations further.
The questions will vary by technical or analytical prowess, company structure, or complexity of the data collection topic. It is often helpful to start at a high level, with questions about the entire organization, then discuss your stakeholder’s role in support of those organizational goals, and so on into increasing levels of detail. You can then ensure that the granular data points discussed will effectively support the overall objectives of the organization. It also empowers you to think creatively and suggest new ideas for data that support their goals.
Explore this template containing several sample questions for stakeholder interviews. Reuse them or tweak them to prepare relevant questions for your discussions.
Your stakeholder should provide you with actual or mocked-up examples of data points of interest and how they might be used or reported. These reports offer another glimpse into the goals, approach, and culture of your stakeholder and their current or ideal state.
Requests made and data ideas discussed during discovery are not commitments to your stakeholders. There are layers of complexity involved in execution of data collection, which you can’t evaluate fully until after the interview. You may discuss ideas in creative brainstorming that are ultimately de-prioritized because of their low relevance to their goals. For these and other reasons, the discovery phase is an idea-gathering opportunity only, where ideas captured are not promised to be made available in reports.
After discovery and subsequent vetting or follow-ups from the Analytics administrator, there should be a meeting to reconvene and discuss level of effort, timelines, and commitment. This method supports free and creative discussion in discovery, which contributes to a more robust solution overall.
Discovery interviews should generate documents, ensuring that useful ideas are not forgotten and increasing the likelihood that stakeholder and administrator agree on what was discussed. However, the level of detail, the structure, and its storage medium are all flexible. A record should exist and it should include some amount of detail on requirements, regardless of whether they become implemented or not. That will later help teammates to understand the purpose of a data point or to review gaps.
It is better to have some requirement context recorded than to have none. It could be as minimal as recording only the implemented data points by using the built-in name and description fields within Adobe Analytics. On the other hand, this could be as complex as listing the requestor, dates, granular level of effort, etc., but that is typically the wrong direction for this principle. Once it becomes cumbersome to record or to review, the process is ignored and abandoned, such that later colleagues asking about a data point will be met with the common refrains: I don’t know…It was implemented before I joined…We don’t trust it. This does not instill confidence and adoption in your data.
Adobe offers some tools and templates to help with this step. Use these and adjust them to suit your needs.
Analytics administrators often have a great sense of what data is useful and what is not. If you frame your stakeholder discussions as recommended here, you will help to bridge the gap between a colleague’s goals and the data needed to measure and prove related success. An admin who is also a skilled detective will confirm the requested data points that matter and uncover hidden opportunities or requirements, making them a powerful asset to the broader organization.