Analytics can be like a kid in a candy store…when a company sets off to put a new analytics system into place, they get so excited about all the things they’ll be able to measure that they forget many vital elements they need to think about before ever deploying the platform.  Here are five common pitfalls that I see companies fall into again and again. Avoiding them can make for much smoother sailing as you go about your implementation and ensure you can get your candy and eat it too!
Pitfall #1. Neglecting key stakeholders

It often happens that the person who plans for and oversees the implementation wants to own it and be sole keeper of the data. Whether this stems from a misplaced desire to shield others from any extra work that might come up around the implementation or from a wish to be ruler of the data kingdom, it will cause major problems.Websites touch all facets of an organization, so a web analytics deployment should reflect all facets of the organization. Everyone needs to be involved. This is no longer 1997, when a website was run as a closet initiative.  Not getting requirements nailed down at the outset, from all concerned, can lead to big problems.

Pitfall #2. Focusing on tactical requirements

When deploying an analytics package like Omniture, you must understand your strategic business requirements – that is, what you, as a business owner or stakeholder, will need from the analytics.  What strategic questions do you want to answer? And by strategic I do not mean how popular a link may be on a page…that is tactical.  Strategic questions are directly linked to your company’s strategic initiatives. So start with your company’s 3 or 5 key priorities – as outlined by your CEO – and then determine what questions you need to answer to support those.  Every company I have work at or worked with has had 1000 different things they want to do with their website, but it’s amazing when you apply a lens of strategic CEO goals to these initiatives, how few are actually relevant.  It’s a powerful yet simple approach to prioritizing. For each project, just ask yourself – “how does this support the goal outlined by my CEO?”.  If you can’t clearly answer that question, you’re probably dealing with a tactical requirement and something that is secondary to your deployment.

Pitfall #3 – Believing “data” equals “requirements”

As you go through the strategic requirements gathering process, bear in mind that your requirements are not the same as data.  When asked what your requirements are, your instinct might be to say, “I need hits, I need time spent on page, I need number of visitors…” Those are all metrics, and quite frankly, all three of those are questionable in their strategic value.A requirement is a business question you want to answer.  The metric is the gauge by which you answer that question (aka your Key Performance Indicator).  For example, if you are driving a car, the business question may be “how fast am I driving?”  The implementation of a speedometer (report) allows you to answer this question. And the metric of miles per hour (or kilometers per hour) allows you to determine how fast you are actually going. But just saying you need a miles per hour report doesn’t help because you haven’t established the business question.

So to summarize, understand your mandate at a high level, and then articulate the steps you are taking to hit that goal. If your goal is to improve conversions, there are a number of things you’ll try in order to achieve that: you may redesign your navigation or improve your registration process or make registration optional.  The data you need will fall out naturally from knowing your requirements.

Pitfall #4. Not focusing on KPIs that are specifically tied to the goal.

If you think you have 20 or 30 key performance indicators, then you don’t understand the concept of KPIs.  Think of the dashboard of your car.  There are many data points you can gain by looking at the dashboard, but there are only three or four that really matter.  If you come up with dozens of metrics that you absolutely must have, you’re not focusing on your true business goal. I can guarantee you that.This doesn’t mean that you can’t measure other things that are secondary KPIs – but it does mean you don’t want to focus on them right away.

When implementing an analytics package, above all else you want to ensure that your KPIs are measured.  Don’t waste time on non-strategic measures.  Ask yourself this: if your CEO was stuck on an island and you could tell him only three things about your business so he would know the business was healthy, what would you tell him? If you said the average time spent on a page was 1 minute 30 seconds, that tells him nothing. If you tell him your average revenue per visit was $2.00 and you had 2 million visits, that is something he will understand as a true measure of business success.  There is so much opportunity to measure initiatives and improve on them based on four or five metrics that you can keep yourself busy for months and even years.  Don’t fret about measuring every little last detail. You’ll make yourself crazy and you won’t be supporting your business goals.

My next post will address three more pitfalls. Stay tuned!


I've just paraphrased your fourth point in an email to a client. They seem to be believing that because their analytics package can tell them so many things that they're all KPI. I'm hoping I've managed to get them to start thinking of their KPI in terms of their business goals - and if they ask one more time what the average is for their industry for every stat their analytics package can churn out - they currently want to increase the number of users who visit their site with Firefox as this browser has the highest conversion to email sign up! Hopefully have talked them out of having browser use stats as a 'KPI' in their web marketing. Cheers for the help Michael

Avinash Kaushik
Avinash Kaushik

"This is no longer 1997, when a website was run as a closet initiative." Priceless!! : ) This is a great post Matt, but do you think that #1 and #2 are in conflict with each other? Whenever I asked all the stakeholders a bunch of, let me just politely call it, "stuff" gets added and it is usually non value add and tactical. Yet, and you are right, tactical is so distracting. How do you resolve that inherent conflict? My path usually was: Just talk to the senior most people (say VP or higher) in the company to get "requirements". They have a inherent dislike of the tactical and that meant both that strategic questions were received but without the tactical (get me time on site). What do you think? -Avinash.