In the last post of this blog series on being successful with digital analytics, I shared my thoughts on aligning your team with its stakeholders/executives around website/mobile app business objectives. That is akin to making sure that you are all on a boat or plane and agree on the destination. But there are many different ways to get from point A to point B, so business objectives have to be broken down into more tangible components. This is where business requirements enter the picture.
Over the years, when I have been brought in to help organizations struggling with digital analytics, one of the first things I ask to see is the list of business requirements that is driving their digital analytics implementation. As I mentioned in a the SDR post, the normal response is to provide a Solution Design Reference (SDR) spreadsheet. But knowing what you have tagged will not help you meet the business objectives discussed in the last post. That is like saying your boat is trying to get from point A to point B and here are the gauges and buttons on the captain’s deck that you have to use. What you really need is a map or a compass to get you where you are going.
Business requirements are the conduit between business objectives and the detailed data points in your implementation. They articulate the specific business needs or questions that your team feels it needs to answer in order to advise on the higher-level business objectives. For example, let’s say that one of your organization’s business objectives is to reduce costs incurred by providing real-time chat support to customers. If you were taking the SDR approach to your implementation, you might decide to tag the following on your site:
- Chats Started (metric that fires when real-time chats are used)
- Chats Engaged (metric that fires when user selects purpose and begins typing)
- Chat Type (dimension that captures the reason for the chat from a picklist within the chat tool)
These three data points would be implemented and then data would start pouring in. But what would your analysts then do with this information? Would they know where to start? Would any analysis they do on the data be in line with the needs or expectations of your stakeholders? Maybe, maybe not.
But what if you first focused on business requirements/questions instead of diving right into tagging? Imagine that your team did a quick brainstorm of all of the questions that you’d like to have the answer to related to real-time chat in order to come up with stakeholder recommendations. Off the top of my head I can think of a few questions:
- How often are visitors using real-time chat?
- How much money is real-time chat costing the organization each day?
- What is the chat/visit ratio for the website overall?
- On what pages is real-time chat being used most often?
- What page flows or journeys are resulting in the most real-time chats?
- What types of questions are visitors asking most often in real-time chats?
- Have visitors using real-time chat also used the onsite search function? If so, how many minutes was it between the search and the chat? What search terms most often were used leading up to chats?
I am sure there are many more that could be added to the list. But if you took this list to some of your internal stakeholders and got their feedback and their guidance, you could then prioritize them and have a map that can guide your analysis on the subject. You already know that the overall objective is important through the exercise from the business objectives post. Now you are confirming with your stakeholders the tactics you will use to zero in on the issue. Then, and only then, should you begin doing incremental tagging. In this case, if you are already tracking pages, internal search, etc., you may end up in the same place (implementing two new metrics and one new dimension for chats), but now you know exactly WHY you are doing it and have alignment and buy-in from your internal customers.
While the difference can be subtle, I have found that it makes all the difference in the world. Business requirements allow you to have a common language with your stakeholders (most of whom tune out when they hear terms like eVars!). They know what your team is working on and what to expect after tagging and analysis is complete.
Action Items
For your homework assignment, I’d like you to start thinking about your business requirements using the following steps:
- Take your list of business objectives from the last post and in a spreadsheet begin writing down any business questions that you and your team can think of that might be of interest related to each business objective.
- For each business question you identify, next to it in the spreadsheet, explain why you think it would be helpful and/or what you would do with the data that answered the question if you had it today.
- Next week, I will dig deeper into how to create your full business requirements list including the items you identify in the preceding assignment.
Adam Greco
greco@hey.com
P.S. Have something you want to discuss about this post? Email me at greco@hey.com.