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?

I was fortunate enough today to catch Eric T. Peterson‘s webinar about engagement, held by the International Institute for Analytics. The presentation was informative and, in some ways, reassuring. Why? Because even one of the leading experts in Web Analytics essentially agrees that engagement is not an objective, clearly defined metric, nor an easily measurable one. (What a sad day it would be to find out that measuring engagement is clear and simple, and I was just missing the point!)

While Peterson spoke of various definitions, as well as a “formula” by which he has measured engagement, he was very clear that this wasn’t the only possible formulation, nor that there was even one agreed upon industry definition.

What it came down to essentially was that:

• Engagement truly doesn’t have a clear definition, at least not in the sense of “it is comprised of X + Y + Z metrics”. We all agree on the concept generally, but not necessarily what elements go into measuring it.
• Sites really need to evaluate what engagement means in relation to their experience.

Perhaps this should be disheartening. Perhaps I should want a clear, defined notion of “engagement”.

But here’s why I don’t …

• Web analytics is not simple (and anyone who thinks it probably isn’t doing much with it – if you are, and you still think it’s simple, please send me your resume!) Therefore I can’t believe a concept as powerful as engagement can actually be simple. Few (if any) web metrics are useful in and of themselves. We need context for our data to be meaningful. Engagement should be the same – it needs to be defined in the context of the site in question. (And its definition should be continually repeated and reinforced within an organisation, so everyone understands. A metric becomes more meaningless as we start forgetting what it actually represents and how it is defined.)
• This fuzzy lack-of-definition of engagement allows flexibility. It allows the concept of an engagement metric to be truly tailored to the site it is measuring. No cookie-cutter solutions, or square pegs shoved into round holes, but something that is thought out, keeping in mind the goals of the business and the site’s visitor behaviour.
• But most importantly – sites that work to define engagement as it pertains to their experience, to capture the data and to process, analyse and segment by engagement level will not let it turn into another useless metric touted at executive meetings. It will have meaning because of its specificity to the site in question, because it is truly helpful in understanding the site and its visitors’ behaviour.

Everyone knows that analysts are constantly elbow-deep in numbers, math and data sources. However, in seeing my own skills develop from my very first analysis, as well as training and working with other analysts, it quickly became very clear that an analyst’s ability to translate large volumes of data into a concise, clear summary separates the mediocre from the invaluable.

Yes, web analytics can be granular. Yes, you are looking at a thousand different things, pulling together multiple data sources, segmenting and diving into detail, even investigating theories that did not pan out. But if you can’t tell others what you found, even just the one most important point, in a sentence or two, and in plain language, then you are missing an essential skill that we need as analysts. Your role is not just to dive into the data and draw out insights. It’s to share them with others in a way that they can understand.

Why?

Executives are busy. If you can’t fill them in on your findings in one or two sentences, they don’t have the time. You are not always going to be given an hour to present your findings in a lengthy PowerPoint. At times, the closest you may get to “presenting” your analysis may involve bumping into your President in the lunch room and having exactly 15 seconds to respond to a, “So how’s that home page redesign performing?”

Same thing goes for email. Eyes glaze over upon opening a lengthy email (normally followed by “Mark as Unread” with a, “I’ll come back to it later …”) Ask yourself this: “If someone only reads the first paragraph, have I given them everything they need to know (even if it’s abridged)?” By all means, provide more information below, or in an attachment, for those who are more involved and need additional detail. But understand that many just want (or only have the time for) the CliffsNotes version.

The simple truth is that executives are also not as close to the project as you are. You need to be able to pull yourself out of the trenches and find a way to summarise your insights to someone who is not as close to the business and the details of it as you are.

What it comes down to is that your job is not just to analyse data, you are also an information architect. Your role involves taking what is complicated, and making it feel easy to understand and digestible to a less-analytically inclined audience. This involves perfecting two crucial skills:

1. Summarising. (Then summarise your summary. Chances are, it’s still too long!)

2. Presenting your findings in the right way to the right audience. A twenty-five words or less approach may work with your executive team. However, further details with visuals may be appropriate for your data-driven business user. Know the difference. So much of our online business is in trying to present the right offer/ad/site experience/etc to the users of our site. We need to do the same to the users of our insights.