willaustin.net

This is an example of a reporting console I built for the Scripps Interactive Newspaper Group that’s built out of Omniture reporting widgets, PHP, and JQuery.

Here’s What a Year in Fatal Car Crashes Looks Like

The most dangerous day on the roads in 2010? Saturday October 16, when 204 vehicles were involved in 90 crashes. Compare that to a low of 41 crashes on Monday 22 March—and to the rest of that year, with this illuminating visualization.

There were 45,777 vehicles involved in fatal crashes in the US during 2010, according to this clean, informative, and sobering chart from Flowing Data. It’s a rich pool of data showing exactly how many accidents happened on every day of the year.

Read more at Gizmodo...

"Here’s What a Year in Fatal Car Crashes Looks Like"

Kudos to LinkedIn for the demographic analysis they provide on their polls. Granted they have a much higher registration rate, and therefore a much more robust demographic profile on each user to pull from, but this is so very insightful. It really provides much more context in which to analyze the results and responses from the prospective respondents. Good job.

When dealing with iFrames and AJAX elements, traditional engagement is more oft than not stymied. In other words, what traditionally would have been counted as a page view, becomes lost in history somewhere between web 2.0 and prominently displayed page counters.

Think of the non-AJAX pages as your old Windows 3.1 operating system (3.11 if you’re nasty like Janet) and new RIA pages as Windows 7. The old Windows 3.1 machines allowed one program to run and that program took up your entire screen (before the dawning of alt-tab multi-tasking).

In contrast, Windows 7 machines allow you to have numerous applications open, there’s now a multitude of things refreshing and hence requesting remotely stored updated data on your desktop. Now some of these programs are simple like calculators, or even desktop display properties, while others are actually productivity vehicles like your email client, or your spreadsheet and presentation software suites. Some of these products have the ability to make money, while others are just there to change the way you’re viewing things on your desktop.

Now apply this scenario to your websites, and think of traditional webpages in terms of Windows 3.1. You have only the one page, all interactions are static, and in order to call up new content another page has to be loaded.

Now in contrast apply this scenario to a page built with RIA (in this case we’ll say AJAX) and in terms of Windows 7. You have multiple applets running interdependently on the page, each with the ability to refresh itself, and each with the ability to access scores of additional data.

Here lies one of the dilemmas of web analysts in todays complex landscape of widgets, iframes, and the insatiable thirst of our core visitation to have an infinitesimal amount of data instantly.

• When do we consider that interaction akin to the former “traditional page view”?
• What actions constitute changes in ad blocks (assuming you subscribe to the traditional rotational ad block model)?
• What actions start and stop the unit of measure we use in assuming an additional engagement opportunity?

Assuming you want to track this all with events, Macro and Micro event designation is a way to apply some method to the madness.

Macro (the broad look at anything from a very high level) events are what we would consider the equivalent of “traditional page views”. These events are the ones that if on a static page would cause the reload of data, the refresh of a view, or a request for additional information (sometimes referred to as a hit, or server call).

Micro (the study of the individual parts that make up a complex system) events are the interactions that are merely cosmetic. The changing of a color scheme, scrolling on a page, or any other actions performed on a page that would be considered form, and not necessarily function.

With this in mind, when tracking events on rich media content pages, it’s important to classify each interaction in terms of it’s true importance in terms of what actions or reactions they trigger. If an event would have triggered a page refresh, a new ad, an additional page view, or something I refer to as a “game changer” then it’s a macro event and worthy of a “simulated page view”. If it’s something that would have minimal impact and more than anything just a cosmetic change or UX/UI consideration, then it’s a micro and while important to look at when assessing the true importance of a wire-frame redesign or usability testing, it’s inconsequential when looking at the overall revenue potential for that particular page.

Recently I had the chance to go back and do some analysis on where our current SiteCatalyst implementation is now, and where it was in 2005 and before (in terms of the 4 C’s – Those being clean, clear, concise, and consistent identification and hierarchy).

I took over the show in early 2007, and completely re-implemented in March 2008 using a custom media implementation and the new Omniture version H code. I was surprised at just how much of a difference there was in what I started with, and where we are at now after a slew of customization to templates, our Django based CMS system, and/or vendor tagging. Here are some before and after shots of the section hierarchy report:

It’s a little difficult to see in the above graphics, but basically there were a couple of tweaks (among countless others) I’ve made that I believe makes our reporting more clear and concise.

1. The introduction of a site ID parameter. This is a simple 3-4 character variable that’s passed in the page templates that designates the site’s identity and directs our customized page code handler where to deliver the page data (which RSID). This can be as simple as “KNS” for the Knoxville News Sentinel, or “MCA” for the Memphis Commercial Appeal. Appending this to the first of my Hier 1, allows us more concise identification of like-labeled data in the case of multiple site IDs per suite, or in the case of master roll-up suites.

example article entry:
KNS:ews.h.knoxville:news:sports:Tennessee-Hires-New-Coach-Derrick-Dooley

example section listings:
KNS:ews.h.knoxville:combined-section:home

2. The use of colons instead of forward slashes.

One of the simplest and oft overlooked ways to make your section hierarchy report cleaner and more concise is to replace all “/” with colons. Too many times in todays web-mindset, we look at forward slashes as a way to clump things together so we can see them as a whole and not the sum of all parts. With the colons in place, it helps your mind to stop and recognize section, sub-section, and so on.

A recent Newspaper Association of America webinar I guest spoke at entitled “Web Analytics: Best Practices”.

Omniture Launches Facebook Application Analytics for Brands

Posted using ShareThis

Of the nine years I’ve been using Omniture SiteCatalyst I’ve seen some major improvements, and a few reverts (we’ll talk about that some other time). Last year with the release of version 14 it finally appeared there was a new focus on user interface design. Slowly but surely Omniture is working out some of the major issues that have plagued the platform since release. But there are still some issues that really bother me. One of which is the practice of using generic variable naming. If you look at the JavaScript file that Omniture provides its clients, you see that all props use the following structure:

s.prop1
s.prop2

This works fine if you don’t share co-branded pages with another company that uses Omniture as well. In my job, I constantly battle with vendors who use Omniture and have an out-of-the-box implementation

Most recently a vendor used s.prop3 to pass search terms as “keywords”. We pass a site ID variable in s.prop3, so my reporting ends up in this case looking like this:

Site ID

TRN
AND
ABIL
bicycle tire
GHE
4 bedroom home jenkins ave

If our JS file is looking for a different naming convention beside s.propX then it doesn’t matter what the vendor uses. We’re in the process of changing our code to a custom varible like s_ews.prop1, etc. but this is going to take a lot of testing before we ensure we’ve not borked anything in the process. Why wouldn’t Omniture make everyone’s props unique at implementation and save us all a lot of time and effort?