Getting reports to display bar graphs in data columns

A couple weeks ago Sean Browning was messing with some WebTrends reports during one of his WebTrends Lunch’n’Learn webcasts.  As usual, at least one WebTrends Outsider was lurking in the audience.

One of Sean’s reports showed a bar graph in the fourth column — a colored horizontal bar in each row, its length proportional to the stat for that measure in that row.

You’ve probably seen those bars in WebTrends tables and haven’t given them a second glance.  In the out-of-the-box reports and the defaults for any custom reports, the horizontal bars are always set up to be in the first (the leftmost) column of the table.  That’s the column which by default is how the whole table is sorted.  That’s also the column that’s the basis for the big bar graph just above the table.  So those bars-within-the-column are just a sideways version of the frequency bar graph in the same report.  Bo-rrrr-ing.

Sean’s table however had the bars in the third column, the column that showed “length of visit.”

Suddenly things were interesting.  Instead of showing a ho-hum decreasing array (if the bars had been based on the first column), the length of these bars varied wildly from row to row.  You could instantly see that certain popular items (popularity meaning “at the top of the list”) had really pitiful time-spent-on-site statistics.  That’s worth knowing. 

This report wasn’t showing any NEW data.  But it was showing existing data in a visual way.  And visuality often yields insight. 

(Yes, “visuality” is a word.  I looked it up.)

Think about how helpful it would be to see your report sorted on one measure while a bar graph happens based on a different measure:

• Entry pages sorted by popularity, with a bar graph for “time spent on site”
• Search terms sorted by popularity, with a bar graph for “# of pages in the visit”
• Pages sorted by popularity (visits), with a bar graph for “views”
• Referrers sorted by popularity, with a bar graph for “number of leads” or “revenue”

How-to

Here’s how to get those bar graphs to appear in the measures column of your choice, for a given report. 

1. Go to Web Analysis >> Report Configuration >> Report Designer >> Templates and open the template you want to work on. 
2. Find the report in which you want an inline bar graph.  Select or highlight it. 
3. The main part of the screen will change.  Toward the bottom you’ll see settings that apply to the report’s table display.  Every column from the 1st to the nth will have two choices:  radio buttons for choosing which measure should display in that column, and a check box for whether there should be an in-line graph in that column.  That’s your baby right there. 
4. Check the box under the column/measure where you want the in-line graph to appear.   Ta-dah! 

,

Beyond the how-to — Think about the sorting measure

While you’re selecting your in-line graph measure, also think about which measure you want to be in the first column.  Remember, that first column is the default sorting column for the table.  The visual variability of in-line bar graphs will be most helpful if you choose the sorting column properly.   Do you want to see how visit length varies as visits decrease, or as page views decrease?  There could be a big difference. 

This kind of choosing is where you get to be a bit of an analyst, not just a GUI jockey.

Okay, now for the gotcha

This inline bar graph thing is kinda recent, and not all WebTrends out-of-the-box (”built-in”) reports have it available!  But all custom reports do, as far as we can tell (let us know if you find exceptions). 

For the old standard built-in reports, if you look at them in the Template Designer you’ll just see a dumb little table that says “Sample Table Entry” for each row instead of the radio buttons and checkboxes we mentioned above. 

For example, the Pages report doesn’t have inline bar graphs available.  Not the built-in, out-of-the-box Pages report.   That report has been around since Log Analyzer.

Not to worry, it’s an easy fix. 

Just use the custom report function to make a modernized custom version of that report.  It can be identical in dimensions and measures to the original, but because you’re using the custom interface, you get the perk of the in-line bar graph. 

When you create the custom version of the built-in report, it’s a good idea to give it a slightly different title, like “Pages (custom)” or “Pages (cr)” so it won’t get mixed up with the fossilized one.  And — be bold, be brave — remove the old fossil from the template.

Future?

We’ve heard from an unreliable source that those built-in reports will be reprogrammed in a future release so that all reports will have this capability, even if they are the oldie-goodies that predate the custom reporting UI.  So we hope to someday come back and delete the crazy part of this posting – the part about having to convert built-ins to custom.  We hope that, at the same time, the in-line bar graphs will be added to the custom report definition interface, with the template designer being used just for overrides.  It’d be nice to have all aspects of a custom report’s design in the same place.

In the meantime, the extra bit of kludge is worth it.

Tags

bar graph, in-line bar, inline, visual

Somewhat Related Posts

Managing display of parameters: yes, no, how many

...

Tracking “Page Not Found” 404’s with SDC tags

...

Fun with the Visitor History File

...