That’s the first question to answer when determining strategy for using online metrics.  You should be able to answer in 10 seconds.  If you don’t know, or if key stakeholders can’t agree on your site’s purpose, then you are unable to use online metrics efficiently.  And, worse yet, you are missing chances for improving your business performance. 

Your web site exists for a purpose, perhaps multiple purposes, such as:

• Providing information or data.  Many sites entice people to visit for access to valuable, differentiated information or data.  Traffic is then monetized primarily through site advertising.  Many internal and external analytics packages will tell you where visitors come from and what they do onsite, which, when combined with demographic information, can be used to qualify a specific audience to an advertiser.
• Generating leads.  A content asset is placed on a site and gated using a form.  People fill out the form and download the asset.  The information captured in the form is stored and used by the company that generated the leads or profitably sold to another company.
• Selling products.  The typical ecommerce model involves acquiring customers via some method or offer, providing a product catalog or landing page, and creating a strong call to action and funnel that persuades people to purchase a product.
• Connecting people.  The explosion of social networking sites where people connect to other people, interact with each other, and use widgets, apps, and data services is a modern phenomenon in which many of us participate. 

Understanding why your site exists enables you to effectively use online metrics.  Once you’ve defined your site’s purpose, you are positioned to examine web data in way that helps you determine whether your site delivers on its purpose – does it effectively exist? 

Metrics and ratios that help you assess if you site fulfills its purpose are called Key Performance Indicators (KPI’s) – see Eric Peterson’s Big Book of KPI’s for a detailed review of the topic:

• For information or data driven sites, you may want to look at KPI’s that measure goal or task completion and conversion rates.  For example, if your site’s purpose is to expose video content to an audience, then a relevant KPI would be the percentage of all visitors that streamed a video or the number of streams per visit. 
• For lead generation sites, a key KPI you will track is the lead conversion rate.  In other words, of all the visitors that came to your site, what percentage of visitors successfully filled out a form and generated a lead. 
• For ecommerce sites, a key KPI that you might track is average order value, which is how much money the average visitor who purchases a product spends on a single transaction.
• For social networking sites, you may want to measure the average time between visits (latency) and the repeat visitor rate. 

But here’s the challenge with KPI’s: they are all academic, unless you have business goals for KPI’s.  KPI’s help you track progress toward predefined business goals.  What are the business goals associated with your site’s purpose?  For your informational site, what’s the goal for video streams per visit or time spent?  For your lead generation site, what’s the goal for the lead conversion rate?  By comparing business goals for KPI’s to actual KPI’s, you can begin to answer the question: “is my site successfully existing and fulfilling its purpose?”

You will continue to answer that question by segmenting your KPI’s, investigating distributions beyond averages, and using other techniques for data analysis.  You may ask: do certain referring sites, have a lead generation conversion rate higher than other referring sites, and why?  Do certain audience segments spend more time on site?  If so, where do they go on the site and what do they do?  If my goal for average time between visits (latency) to my site is five days, and certain customer segments haven’t visited in ten days (recency), what does that indicate about current business performance?

By defining why your site exists, creating KPI’s based on your site’s purpose, establishing business goals for KPI’s, and investigating what’s driving those KPI’s, you can enhance your online business performance in a way that increases bottom-line profit – from optimizing user experience and landing pages, to more efficiently allocating your marketing budget, to improving your product mix, and much more.

In Part 1, I mentioned that the Web Analytics team will look very different depending on company and business goals.  I identified three elemental constituents (business strategy, analytics, and technology) necessary to select a web analytics tool, and I divided them up into three different folks who fill those roles when you’re selecting an analytics technology.

Once the tool is selected, companies will want to create a structured team framework with defined roles and responsibilities in order to successfully deploy the tool.  What I’m describing is a suitable team-structure that enables you to successfully deploy a tool in your organization that finally gets you to a point where you are able to do web analysis. The team structure I describe below lets you get to the hub-and-spoke model that my good friend, Eric Peterson, described in these Part 1 and Part 2 of “what’s your web analytics communication strategy?”   What Eric excellently describes takes the team to the next level of actually doing Web Analytics.  It’s excellent stuff that I encourage you to read.

A formalized team structure for rolling out a web analytics tool may have the following constituents: 

• Executive Advisory Board.  Beyond the Executive Sponsor mentioned in Part 1, these board members are the ones who really control the budget and strategy at the highest level.  They may be your boss, your bosses’ boss, or board members at your company. Regardless, they are the analytics project champions at the highest level in your organization – often C-level executives.  They support the project structure and analytics strategy, confirm the scope of the project, and approve any budget allocation.

• Steering Committee.  You may be on the steering committee, Mr Web Analyst, or it may consist of very senior representatives of all the internal teams that the project touches.  These people work to define the strategic direction of the project, decide on how to resolve critical issues that come up during the rollout, and generally handle any escalations.

• Web Analytics Expert.  That’s probably you, fine reader.  You will provide analytics-based strategy and informed decision making across all aspects of the project. You’re obviously critical to the success of this project, and will ensure technical, tactical, procedural, functional, and financial adherence across the entire analytics program.   You are the chief evangelist, and will define the overall reporting and KPI structure.  In addition, you will be responsible for the overseeing the partnership with your vendor. Other things you may do will include managing costs, coordinating schedules, risks and resources, and reporting overall project status and important communications (often with the help of a project manager) to the steering committee and advisory board.

• Web Analytics Team.  If you are lucky enough to have a team, these folks will gather and document project and technology requirements, liason with business stakeholders, lead training, build awareness of and evangelize web analytics, and in general work with those who receive reporting and leverage the tool.  In many companies the solo web analytics expert will do all this stuff (and drink a lot of coffee or green tea too!).

• Project Manager.  A web analytics rollout can be complicated. While the solo web analytics team member may be expected to project manage, it may make sense to give that role to a formal project manager (y’know a PMP) who works with the Web Analytics Expert to manage the schedule, risks, resources, communications, change, and quality management plans.

• Business Partners.  Since web analytics will touch many different groups, you will need to ensure your analytics team communicates with them.  Business partner are critical stakeholders.  They can’t be neglected.  They will provide business requirements, test the technology, and work with analytics team to ensure the technology, reporting, KPI’s, and analysis you rollout helps drive business performance.

• Subject Matter Experts (SME).  Similar to business partners, these folks will probably be more technical in nature.  The Technology Expert you worked with when selecting the project will transition into a roll as a SME.  You may have one SME who oversees the overall technology architecture, another who coordinates BI resources, another who QA’s the system, another who creates interfaces to your data warehouse, and perhaps another who acts an IT contact covering issues across the operating system, database, security, and networks (especially if you are running an in-house tool).

• Vendor Professional Services Team Members.  Last, but certainly not least, are the folks sent from your vendor to do what you want them to do.  From installing the application (in a in-house environment), functional training, to advanced configuration, these people are critical to ensuring that you don’t make simple, avoidable mistakes that can thwart your efforts and delay the successful rollout, golive, and extension of the project.

In reality, you may not be able to effectively isolate all of these groups to support your analytics rollout.  To some degree I’ve presented big company structure above.  In smaller companies, one or only a few people may do all of the interlaced activities necessary to rollout a web analytics tool.  Regardless, I think the groupings I’ve presented above define the primary roles and responsibilities necessary for success when rolling out a web analytics tool (in fact I presented things in a general way to apply to other rollouts as well).  The next challenge comes once your up and running (make sure to read Eric’s posts)… You need to use the data to improve business performance and guide strategy, decision making, and online tactics that reduce expense and yield profitable revenue.


Image by Jim Sterne, from Emetrics 07 San Fran.

I’ll get back to talking about the web analytics team soon, but I’ve been getting a few emails from folks just starting out who are a bit confused about data collection.  So I figured I’d blog about it…

When web analysts talk about data collection, they are referring to the method by which counts and measures of things, like page views and durations, are captured by a web analytics tool.  If you’re new to web analytics, data collection can be slightly confusing.  There are three “generally-accepted” methods for data collection in the web analytics industry: 

• Page tags.  Client-side data collection involves using little snippets of HTML code that reference a JS file and communicate via a beacon to a “page tag server” - the machine that collects the data so it can be sessionized by the web analytics tool (it may not be called that by your vendor).  As a web analyst, if you are using page tags you will have lots of fun tagging every page on your web site and instrumenting the tags with custom variables and campaign codes.  Reasons why people like page tags are numerous, and include the fact that they are fairly efficient in filtering out non-human traffic (as long as the robot doesn’t execute javascript) and can count proxy cached pages (improving accuracy). Page tags are probably the most ubiquitous method for collecting web data today.
• Log files. Server-side data collection involves parsing text-based log files generated by Web servers.  The server, when instructed to do so, logs every request received by clients in a file called the “log file.”  There are many formats for log files.   Each line in a log file is called a “hit” and contains lots of different stuff - from the ip address, a request date/time stamp, the item requested, user agent, referrer, and more.  Many “hits” make up a single page view - that’s why it’s incorrect to use the term “hits” to refer to “page views.”  As a web analyst you will be defining the format of the log file within your tool and moving and synchronizing log files so that they can be processed by your tool.  Some people will claim log file analysis is dated (historic may be more appropriate), or less accurate than page tags (due to caching issues).  Other people like logs because they can reprocess their data. 
• Packet sniffers.  Network data collection involves deploying either software or hardware that intercepts and logs traffic coming over a network.  Every packet is captured and decoded according to a configuration you define.  Your web analytics tool can be configured to process the data captured and decoded by the sniffer.  Packet sniffers are a less common approach for data collection by web analytics vendors.  

Interestingly some vendors offer “hybrid” data collection, which combines multiple data collection methods.  This mode could be considered a “fourth type” of data collection.  Most commonly hybrid data collection means using logs and page tags to collect different data elements, but other combinations are possible as well. 

As you investigate the best data collection method for your implementation ensure you deeply consider the pros and cons of each method.   For example page tags capture information about the browser (like screen resolution) that logs just can’t.  But what about if you need to measure non-javascript executing clients, like some mobile devices?  Log files capture information about crawlers (i.e. robotic traffic) that page tags just can’t.  But can you adequately filter robotic traffic and maintain host exclusions?  Packet sniffers capture pretty much everything, but can be challenging to customize to your exact data needs (and you’ll need a fair amount of IT support). 

Which one is correct for your implementation?  It depends on your business goals defining what you need to measure…  

The best answer to that question is that “it depends.” The members of the Web Analytics team vary widely by company based on a number of factors, such as the company size, where you are in your rollout, capability maturity for analytics, established corporate processes, the number of sites to implement and maintain, the granularity of the implementation, the technology used, the number of people to which you give access, support requirements, and many more company-specific factors.

For many companies, the number of web analysts can be counted on one finger of one hand.  The lone cowboy is expected to champion the effort, and pretty much do everything under the sun - from orchestrating the tagging to reading the data to being a project manager.  Sure, that can work.  It just means empowering one individual to get the entire job done and giving them the budget, resources, authority, and clearance to make all the decisions - and communicate up the chain.  In reality though, few companies can find the right person who can do it all. Does it take a village to do web analytics?  We’ll not quite, but it does take many different people to select, implement, extend, and maintain a web analytics platform.

Over the next two (or maybe more) posts I’m going to cover my take on what skill sets, roles, and responsibilities are necessary on for doing web analytics - from when you start thinking (and believing) that you need a web analytics tool, to when you implement, to the ongoing day-to-day operations of the web analytics department and maintenance of the tool.

When you are just beginning you web analytics selection, prior to implementation, you want a small, focused web analytics team (watch out for too many cooks!):

• An Executive Sponsor.  This person is usually the HIPPO (highest paid person in the room) - until their boss gets involved ;).  For some companies this could be a C-level executive, VP, or Director.  The Executive Sponsor is in charge of setting the broad-based strategic vision for the analytics roll-out.  They may have hired you!  They help to set the overall scope of the rollout, remove obstacles, and set and control the budget. They are who you go to “escalate.”
• A Web Analytics Expert.  This person is most likely you. You may be an MBA, a techie, a marketer, an IT person, or someone who was promoted into the position.  Lucky you!  You will be in charge in identifying a vendor consideration set, writing an RFP (if you do one), identifying business requirements, collaborating with internal stakeholders, doing the due diligence with the vendor, determining the features and components needed in the web analytics product, figuring out the appropriate financial model, championing for the budget, communicating with internal stakeholders, debating the merits of the technology with your internal team, and generally supervising and stewarding the whole selection process along so that the job gets done (and your executive sponsor looks good).
• A Technology Expert.  This person could be you too, Ms. Web Analyst. Or it could be a systems architect, a data warehousing expert, a dba, an application engineer, or another tech-savvy colleague with a computer science degree (or maybe not - a degree from the school of hard knocks). This person will vet the underlying technology provided by the vendor.  You want this person to ask deep, hard questions about the innards of the technology offering to ensure the technology will match and scale to your internal technical requirements.  Say you want to integrate internal data with your web analytics tool.  This person should know all about your corporate systems, what data your company has, where/how it’s stored, other technology projects, and so on.  They’ll help you ensure technology you are leaning toward fits into the technology ecosystem at your company at a very deep level.

After short-listing vendors, doing the due diligence, pilot/proof of concept(s), you’ll finally make a decision about what tool to buy (or perhaps you’ll determine a free tool meets your requirements now (but will it in the future is the question you should be asking… LOL!).

At the “buy” decision is made, the Web Analytics team will grow to include a more people with different skill sets, roles, and responsibilities.  I’ll cover that in my next blog post.

Every month I write a column for MediaPost’s Metrics Insider.  This month I wanted tackle my evolving take on Internet video measurement.  Very few companies offer solutions in this space.  Only a few are really differentiated.  Check out Visible Measures, NedStat, TubeMogul, Divinity Metrics, and the usual suspects, Omniture, Unica, WebTrends, ComScore, and Neilsen NetRatings. 

Here’s my column:

IN LATE 2007, THE DIGITAL Video Barometer Executive Survey indicated that more than 80% of media and entertainment executives believe tracking, measuring, and monitoring Internet video content is critical to bottom-line profit.  That’s not surprising. Accurate measurement informs decision-making and improves business performance, and Internet video is more mainstream and popular than ever before.  What may be surprising to those executives is that technology for measuring Internet video generally focuses on video content served on-site, not off-site.  It’s fairly straightforward for a Web analytics tool to tell you how people are consuming and interacting with on-site video, but consumption and interaction of videos distributed across multiple sites, perhaps virally or via social media campaigning, aren’t directly measurable by Web analytics tools.  Panel-based technologies can approximate certain off-site measures of video consumption and distribution, but don’t provide very deep on-site metrics. Measurements of Internet video consumption, interaction, and distribution may be categorized as follows:

• Instream measurement.  Refers to measuring the video itself and the various events and behaviors that occur during a video viewing experience, such as time-based duration metrics and interaction and behavioral metrics (for example, the number of stops, plays, pauses, rewinds, fast-forwards, sites that posted or syndicated the video, clicks on hotspots and social media features).
• Outstream measurement.  Refers to measuring the content environment and user experience surrounding the video on the site or in the skin, such as the conversion metrics (percentage of visitors downloading or viewing a video), source metrics (refers to the video page, players used), and content metrics (percentage videos viewed by topic, percent videos viewed by file type). 

Those categories form a framework for Key Performance Indicators (KPI’s) that help to identify how people interact with videos, how videos perform when compared to other videos, and against pre-defined business goals.  Analysis of KPIs enables video content to be tailored to maximize performance.  Example KPI’s include:

Instream KPI’s:

• Percent high, medium, and low duration video views
• Average viewing time per video
• Percent visitors who complete the video
• Percent visitors that stop the video within 10 seconds
• Percent visits when this video was the last video viewed
• Percent visits when this video was the first video viewed

Outstream KPI’s:

• Conversion rates by video, topic, channel, taxonomy node, referrer, geography, keyword, and so on
• Average video views per visit
• Percent visits/views from different channels (such as email/rss, organic search, paid search, direct)
• Average time between visits that include a video view
• Repeat visit rate for visits involving a video view or download

These KPIs are measurable using a Web analytics tool, and perhaps a few of them are possible using traditional panel-based measurement.  But if off-site video distribution creates a whole new set of challenges to using current analytics and audience measurement tools to track instream and outstream metrics and KPIs, what are publishers and advertisers to do?  It’s a business problem that demands a new technology solution for understanding audience behavior, consumption, and distribution patterns of off-site syndicated or viral video content.

So what would a new technology solution for measuring Internet video and audience behavior do?  First it would have to fill the gap between panel and census-based measurement systems in a way that helps both publishers and advertisers  – not just one or the other — understand audience reach, frequency, and behavior.  The technology must enable tracking and actionable reporting and dashboarding of key metrics and KPIs, distribution patterns, behaviors, and interactions regardless of where the video “goes” on the Internet.  Audience characteristics from external databases (like OpenID for example) and internal company databases (like subscription and registration dbs) should be able to be integrated with data collected about behavior, video metadata, and instream and outstream metrics. 

If measuring digital video is as important as eight out of 10 media and entertainment executives believe it to be, there are some huge money-making opportunities on the horizon — for companies that are already providing technology for tackling this emerging business need, for advertisers using Internet video to drive awareness and response, and for measurement professionals who can help make sense of the Internet video ecosystem, solve measurement challenges, identify significant business opportunities, and use video metrics to improve business performance.  We’re certainly at the beginning of the J-curve for Internet video measurement for both publishers and advertisers.  After all, Forrester predicts Internet video advertising spend to increase from $471 million last year to $7.1 billion in 2012.