In a previous post, I discussed the role of web analysts as “information architects”, responsible for outlining complex data and findings into easy-to-understand information. However, there is another hat we analysts wear, which is to serve as a an interpreter, or translator, between business users and analytics information.
Analysts are often charged with responding to business users’ requests for information. Whether it be a report of simple metrics or a more complicated analysis, this is the reactive side of our role. (Hopefully you also have a proactive aspect to your role, but that’s a topic for another time.)
Now, with no disrespect intended to business users (who know many things we don’t, and are good at many things we’re not) the simple truth is that business users don’t always know what they need.
Remember, this business user might be the person to whom you’ve explained the difference between a visitor and a visit, or a page view and an ad impression, four times already … this week. That’s okay – it’s our job to explain the subtle nuances of data and metrics. But you need to keep that conversation in mind when they later come back to you for information. Just because they want visitor information, doesn’t mean that’s the information they actually need. Perhaps a visits metric would be more appropriate in this case, because of XYZ reason that they’re not aware of, or because they’ve simply mixed up terminology.
I see this most with more junior analysts. Especially as the business person requesting the information becomes more senior, there is often an eagerness to provide exactly what they asked for, as quickly as possible. However, as an analyst, an essential developmental step is to question what is being asked of you.
It is less important to provide the information the user wants. What is crucial is to provide the information they need.
This is where an analyst needs to stop, consider the request, and ask: “What question are you trying to answer?” or “What problem are you trying to solve?” Once you understand what they need the information for, you’re then in a position to evaluate the request and ensure that the information you provide helps them with their business problem. After all, how can you respond to something you don’t even understand? Perhaps the user thinks they want visitors, but they actually want visits. Or perhaps they think they want last month’s information, but you know that it will help them to see last month, which was abnormally high or low, in the context of the last 13 rolling months. Perhaps there is even additional information available (other metrics, segmentation, etc) that they aren’t even aware of, that could help them solve this problem!
If done correctly (I don’t recommend rolling your eyes and saying, “Don’t be stupid, you don’t want that metric, duh!” – though not from personal experience! I just suspect it wouldn’t go over so well) business users really appreciate this assistance! They actually rely on it, whether they realise it or not. As subject matter experts, analysts are invaluable in helping the business figure out how to best solve problems, with the right information. We should be sharing our knowledge, and working collaboratively to solve business problems. After all, what’s the point of you handing over what they want, them finding it either useless or worse, it actually guiding a poor business decision?
This interpretation of requests never goes away, but it’s worth noting that it does lessen over time. As your business users and analysts work more closely together, and at least somewhat speak the same language, business users get better at knowing what to ask for and what is available, and analysts get better at understanding the business, and can proactively provide information that can help to solve problems, before it’s even asked of them. Makes you smile, doesn’t it?