The Art of Building Web Analytics Reporting, Part I

Yes art. Call me nerdy all you want but when I see a beautifully constructed report set that flows from rich tab to rich tab, I see art. To help you see art too I have constructed this list, which I will give to you in two installments, of basic dos and don’ts when building a web analytics report. Everything in this post and the next is at a basic and general level, but stay tuned for part three that will feature more advanced tool specific techniques of building faster, better reports.

And for more on reporting check out Paul Legutko's recent blog on the centuries old question of "If a Report is sent out and no one reads it, is it still a Report?"

1. Use Excel. No exceptions…Ok, ok there are exceptions when you want to use a dashboard or bookmarked report within your tool’s interface but these instances are few and far between. Interface reports tend to be limiting and thus often misleading, so if possible avoid them. Excel      maximizes your distribution and formatting flexibility, so if you want your report to be seen, saved, shared and used then Excel is your best bet.

2. Automate everything possible. Spend as much time up front as is necessary to make refreshed data one button away. Start with automating everything within your web analytics tool data references. Often this will involve referencing dates, segments, etc. from  other Excel cells. When the automation capabilities of your tool end that’s when you begin to use      Excel. Regardless of what you want to do there is probably an Excel equation for it. Often the seeking out of an equation will involve Googling “Excel” followed by the tool description, but this method has surprisingly good results (its always nice to use an application used by millions of others). Automation is an art in itself. I’ll get into more tips and tricks on it in my third post the art or report building form. 

3. Don’t settle for the format the tool supplies data in. This is especially true for Omniture’s Exce lClient, but for all tools you should be constantly be asking yourself if your happy with the formatting of the data. Don’t be afraid to make all the cells the report recipients see be references to other hidden cells within the same worksheet or even better yet a data specific worksheet.

4. SAVE AS early and SAVE AS often. Plain old saving just doesn’t suffice when it comes to web analytics reports. Web analytics report building tools are buggy—all of them. If you build enough reports not a case of if your data references (some or all of them) will disappear, but when. In the instance that your references disappear its not sufficient to have saved five minutes ago, they still are going to be gone. Saving as allows you to go back and work off a recently updated and complete version of a report. 

5. Use language your company/audience is familiar with. Just because your tool has a specific      name for a report or metric does not mean it is the best one to include in your report set. Have a specific audience in mind for the report and build your language around them.

6. Connect the dots in your reporting with hyperlinks. Let others drill down into deeper levels of data (presumably on later tabs) with document hyperlinks. This is an effective tool into bringing people deeper into the area of the report they want to go from an initial dashboard page. Hyperlinks will make your report flow better and decrease the amount of time it takes new user to get comfortable with the report. 

7. Visually illustrate your numbers whenever appropriate. No matter what your audience graphs, pie charts, etc. usually hit home. Forgo the use of things like gauges (judging site performance based on the three colors in a stop light is just crazy) and instead try to find the best illustration of your actual numbers.

8. Build your own metrics. If you’re pulling total page views, visits and visitors and are calling it a report you’re inevitably only showing a tiny sliver of the story. In addition to the basics you should be integrating metrics not found (unless you built them there) within your tool. Things like “x events/registered visits” or "percent difference from client average" can often say a lot more than the number of page views generated within a month ever can.

Comments

[benry]

Good suggestions Jesse.