Aaron Gray // Greater Returns

Icon

Musings on Web Analytics, product strategy + other stuff.

Web Measurement Should be Goal Directed

I think it is well understood now by most managers that web sites should be goal directed.  That is to say, the web site should have a set of goals that are tied back the goals of the overall organization. Every organization has some kind of goals – the reasons it operates.  The web site should exist and operate in support of this set of goals.  Even if the goals are not well documented, many people will have a strong intuitive sense of what they are.  (And if intuition is all you’ve got – listen to it.  It’s better to act based on an internal understanding than to fail to act because of insufficient information.)

Goals are pretty simple, and need to be stated in simple terms.  Sure, there’s lots of complexity underneath the goals, but don’t worry about the complexity until you understand the goals in a simply stated form.  Goals are measurable things you want people to do, like buy!, join!, volunteer!, donate!  If these are your organizational goals, then they should also be reflected and enabled or furthered somehow on the site.  (If they’re not, don’t bother measuring  – go fix your site first.)

What doesn’t seem to have sunk in yet is that measurement should also be goal directed.  When you look at your analytics data, the first thing you should be looking at is your performance against the goals you have.  Don’t look at visits, or pageviews or traffic sources.  That data is contextual, but it doesn’t help you understand how the website is contributing to the goals of the organization, and it certainly won’t help your higher-ups understand the value of your contribution to the operational goals of the organization.

Of course, the analytics vendors don’t make a goal-oriented approach to measurement easy.  When you login to most analytics packages, you’re showered with overview data about things that have nothing to do with your goals and with navigation to ever deeper and deeper reports.  It’s an interface only a web analyst could love.  Therein lies the problem.  The people running the web channel are business managers, not web analysts.  If they’re not web analysts, why should they understand web data you ask?  Well, they understand balance sheets and P/L statements, yet they’re not accountants.  The reason they understand these accounting statements is because they’re organized and standardized around a key business goal – money.

Analytics reports for everyone who isn’t a web analyst (that is to say, most people) should be the same.  They should be organized to show, first and foremost, performance against goals.  And, they probably shouldn’t be in the analytics package at all.  Leave that to the analysts, and surface performance against goals, and key contextual data, for the managers to see in a format they can use.  Excel is a good option.  But with the proliferation of APIs in analytics packages, it’s becoming easier and easier to pull that data into other applications, including web-based dashboards and scorecards, which can be made widely available in the organization while keeping most people out of the weeds in the analytics package.

Now, go forth and make it happen.  Get your people out of the weeds and focused on the goals.  Eyes on the prize.

Filed under: Web Analytics

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Twitter

%d bloggers like this: