Anyone who has spent any time doing Web analytics knows that you get a lot of requests for analysis. The bigger the company and the more seriously they take analytics, the more requests you will
get. And the requests will range all over the map -- from simple data pulls to dashboarding/reporting requests to comprehensive analytics projects to statistical modeling to pretty much everything
under the sun, whatever people consider "analytics."
People have even told me that requests for analysis can even be a tactic for people outside your analytics team to pass the buck in
order to make an excuse for not delivering on their own work. The idea being that because you do analytics, you instantly have all the data at your fingertips and can deliver it in a flash, so why
aren't you helping me?
False conclusion. Analytics is hard and complex. And the bigger the corporation and more integrated the analytics, the harder and more complex.
In
many cases with Web data, the data may not already have been collected, the data may have to be sourced from another system, extracted, transformed, or made available in a dashboard or a report -- if
at all even possible to report and analyze.
Or, the data may only exist as a figment in the imagination of the requester.
The data may be impossible to report because you
have inadequate data model, or an entrenched BI team that doesn't get how the schema affects reporting -- and doesn't care enough to help.
And real analysis of the data takes
uninterrupted time, which you may or may not have time to get to today, next week, or next year because you are working at correcting the data model, ensuring the right data is collected, letting
queries run, dealing with the intracacies of overly complex tools, building reports, dealing with other requests, working on already prioritized projects, and trying to answer your email and attend
meetings.
That's why when you, data and analysis consumers, ask for data or analysis, you sometimes don't get it quickly from the Web analytics team. You are just one of the many
people making many requests to what in many companies is an already overburdened, often understaffed team dealing with nonstandardized or clearly-defined data coming out of many different systems and
third-party applications.
Thus, when you are a Web analyst, you need to carefully consider what you say yes to do and how you respond to requests for analytics work. Because as soon
as you say "yes, will do" you've committed to what could be the analytics equivalent of daisy-pulling in a sunny meadow on a summer's day -- or a Herculean cleaning of smelly stables in freezing
weather. What follows is some advice on how to prioritize your requests for reports and analysis:
Is revenue at risk? Anyone who has worked with me knows
this is one of my favorites. If revenue is at risk, then the analysis will be done! Profitable revenue is the chi, the lifeforce of any business. And analytics that supports revenue generation is of
the highest kind of analysis. But you must prove it. Just because you work for a group that produces revenue doesn't mean your request going unfulfilled puts revenue at risk. Tell the team exactly
where the risk is -- don't generalize. Who's asking? Is it your boss asking, her boss, their boss' boss? Then the work gets done. We're not talking HIPPO
here. We're just talking MOPPO (most powerful person in the organization!). Keep your boss happy. How difficult is the request? Just because something is
"too hard" doesn't mean it won't get done, but as an analytics professional, you need to set delivery expectations when requests are so difficult that they will take time. Perhaps the schema needs to
be modified, changed, or just simply remodeled in order to get that data, maybe you need to rewrite the tags, reconfigure the tool, build a bunch of new reports, figure out the data delivery tool.
Maybe five other groups need to work collaboratively in coordination with all their other projects just to get the data to a point where it can be reported. Manage the expectations of the requester.
Can it be self-serviced? Just because requesters don't know how to use the tool (RTFM), it's too slow, don't know where the report is, can't understand the
report, don't get Web analytics, don't know how to write SQL, or don't know where to look, doesn't mean the Web analytics team is going to do for you what your job requires you to do. The analytics
team should teach self-servicing as a best practice because wasting time easy fishing in shallow waters means you may miss the big analytics catch in the deep data pool! When is the analysis needed? Of course a time frame helps you to prioritize. Requester wants the weight of the world at microsecond N during the equinox by the end of the day
tomorrow? They're probably out of luck unless 1) revenue is at risk or 2) they are the boss. A week? Well maybe, but the weight of world requires querying the Atlas database and queries don't run
like Mercury. The analyst needs to set expectations based on a number of interplaying factors about when the work can be delivered. Why is the analysis
needed? Just curious about the number of X that goes to Y from Z? Time spent on page Z of your microsite? Or do you need to make a real business decision to advance the core mission of your
company? By communicating to your analytics team the importance of the request's "why," you can get better service. Analysts that know why they are delivering can more effectively prioritize. As an analyst, use these questions above to:
Help you prioritize your work Figure out what's really important Frame how to
manage expectations Deliver what's really necessary to drive the business as soon as possible Not get caught in the tar pit of wasted time constantly
servicing low-value requests Am I right, wrong, on target, misguided? And how do you prioritize?
So true, so true. Try to always as "Why?" -- How will this information be used...?
Sometimes the requester doesn't even know enough about the data systems to ask the right question(s). Probe on the problem trying to be solved upfront...in the end, it saves a lot of time and effort for the Analyst and time and frustration for the requester
Judah, you are totally on target. Data is often messy and can take a lot of time to mine. Even more important, it takes good upfront planning on insight questions and tracking implementation to get the right data in the first place.
Judah - great post. As Laura hit upon - you need to get the end user teams on board during implementation. Having been through 2 Omniture SiteCatalyst roll outs I speak from experience. User understanding is critical,
I think that some of the high expectations of web analytics comes from all the hoops that you have to go through to get some companies just to implement it. In justifying the cost and time involved. It sets high hopes that you're getting the Oracle of Delphi!