In the last post of this blog series on being successful with digital analytics, I discussed why your old, outdated Solution Design Reference (SDR) will not help you get to the next level in digital analytics. The main reason for this is that the SDR only tells you WHAT you are tracking, but not WHY or HOW you are tracking it. This is not helpful for digital analysts and business consumers or your digital analytics data. In this post, I will walk you through how to start the process of identifying the WHY and HOW behind the WHAT of your SDR.
Let’s start off with a simple question – why does your website (or mobile app) exist? What would happen to your business if it were shut down? Amazingly, when I work with clients and I ask them why they have a website or app, it takes them some time to articulate it. This is likely because the website/app was built many years ago by predecessors who no longer work at the organization. In most cases, the business objectives of the website/app don’t change very much over the years, but in some cases they will. Most websites have two super high-level goals:
- Make the organization more money by providing access to content or selling products or services 24/7/365
- Save the organization money by enabling visitors to perform actions that would otherwise cost the organization money in human resources
Each of these macro-level objectives can be broken down into smaller objectives. For example, a financial institution might determine that their business objectives are to:
- Allow customers to deposit money, transfer money, perform trades, etc. online so it can reduce headcount at branches and possibly reduce branches as well
- Provide a venue for prospects to read about financial products and reach out to the organization with questions
- Provide a venue for prospects to apply for products online and process applications without human intervention
- Provide online support to customers via FAQ’s, support chats, etc. that may reduce overall support costs
As mentioned in a previous post, I am a big fan of asking open-ended questions and if you want to do some internal research, go ahead and survey your key stakeholders and ask them why they think the website/app exists. You will see some consistency but may be surprised by the responses. Once you solidify this list, I recommend working with your stakeholders to rank them by priority.
Next, you should work with your team to determine how much time is being spent on each of the website objectives. Using the financial example above, is your team spending its time primarily on transactional analysis and less on the others (i.e. 80%/5%/5%/5%)? Or is work evenly split amongst the objectives? Once you have your objectives down and you know where time is currently being spent, you can have an intelligent conversation with your executives and stakeholders about the focus or alignment of your team. If together you can help you prioritize the objectives and map that to where your team is spending its resources, you will minimize the risk that your team is not delivering what the organization needs. For example, it may be the case that there is a new push from the “C” suite to improve customer satisfaction scores, so perhaps more time should be devoted to the support objective. Either way, this process will also help you get buy-in from the people who will ultimately consume your analysis and fund your budgets!
Action Items
- Survey your internal stakeholders and ask them why they think your website/app exists, consolidate the responses and prioritize them.
- Identify where your team is spending its time and map it to these business objectives.
Once you know and are aligned on your business objectives, the next step is to focus on business requirements. In the next post, I will cover why business requirements are so valuable and how they can be used to continue digging into WHY you are tracking what you are and what may be missing from your implementation.
