Functionalism and Web Analytics: The Basics
This is the second part in a series on Functionalism and Web Analytics.
You can read the first part here.
(You may want to visit http://www.semphonic.com/resources/whitepapers.asp and download the White Paper on Functionalism as a detailed technical companion piece to this series).
The idea behind Functionalism is simple and rooted in common everyday practice of most analysts – there are different types of web pages and they do somewhat different things. Since this is a truism, it is also something of a truism that pages designed to perform different functions will need to be measured differently. This, in a nutshell, is the guiding principle behind Functional analysis.
But it should be almost immediately apparent that to be a real method, Functionalism must be more than this simple principle. A principle – even a collection of principles – is not a method. There are certainly a very large – probably infinite – number of different conceptual schemes that could be evolved to describe what pages on a web site are designed to do. And for each of those schemes, there are certain to be a very large – probably infinite – number of possible measurements that could be evolved.
It is for the same reason that a simple idea like “web analytics must be driven by an understanding of customer goals” is not a methodology just another principle (and, probably, just as true and correct as the fundamental principle behind Functionalism). But there are an infinite number of ways to map customer segments ranging from simple to incredibly complex and from useful to useless.
So a method must provide direction about how, when and why specific measurements can be identified and should be used.
So the real heart of Functionalism is the conceptual scheme for categorizing pages (what they do) and the richness and practicality of the KPI’s attached to understanding the performance of each type of page.
A much more complete list of page types is given in the White Paper, but here are a few sample ones that provide some flavor to the conceptual approach:
Routers: Pages whose function is to move visitors into specific places on the site.
Explainers: Pages whose job is to help the visitor understand some aspect of a product or service but not necessarily drive to a sale.
Closers: Pages that are supposed to get visitors to enter a conversion process.
Re-Assurers: Pages built to re-assure the visitor about some potentially problematic issue or concern (privacy policies are a common example).
Completers: Thank-you pages – designed to signal the completion of a process and – in some cases – drive to additional engagement.
These pages are particularly applicable to a traditional e-commerce site – especially for a larger company. However, the Functionalist library of Page Types extends to many other types of pages and sites (like Billboard Pages on publishing sites). One of the strengths of the basic approach and the library as built is that it can address the needs of a significant number of sites and site cases – it isn’t limited to one type of site; even one type of site as widely used as basic e-commerce.
A second aspect that emerges from this list is that the methodology is designed to provide viable measurement systems for nearly every page on a site. Many analysts have grown accustomed to only measuring the success of pages that have a strong relationship to an easily established success metric (like conversion). This results in a kind of myopia where many site functions drop-off the optimization table – as if it isn’t possible to have better or worse Explainer pages just because they aren’t meant to sell a product. Even worse, it means that many pages that should be doing something more (like Completers) are left un-attended because they don’t obviously have a function in the sales process.
Part of our goal in specifying the Functionalist methodology was to build a system in which the analyst could reasonably measure the performance of almost any kind of page that marketers and designers believe is worth building.
In this respect, there is a fair amount of substantive page classification work that we’ve done but not included in the White Paper; though what is in the White Paper is more than adequate for many, many sites. This isn’t because we meant to be stingy – but many page types we’ve run across and thought about aren’t very common – and others we are still struggling to define a really good set of KPI’s for.
Which brings me to the second part of what I take to be the meat of Functionalism – the page type specific KPI’s. In thinking about the KPI’s for page types, we had several important rules that we wanted to follow. The first, of course, was the basic Functionalist Principle – we wanted KPI’s that measured in some respect the success of the page vs. specific functions. Second, we believed that the KPI had to be producible in at least one of the common measurement systems used by our clients (HBX, SiteCatalyst, Webtrends, Google Analytics) – and we gave preference to KPI’s that could be produced in all or several of these systems. Finally, we wanted KPI’s that could be understood in language relevant to marketers and web site designers.
In most cases, page types will have more than one KPI. That probably isn’t ideal, but it is inevitable. It’s very rare that a single measure can capture everything you need to know about a page’s performance. Let’s look at one set of KPI’s – the suggested measurements for Router Pages:
- % Body Routes
- % Routes by group (body, top, back)
- Exit Rate
- Exit Propensity
- % Re-surface (% of visitors who drill-down then come back up to the Router Page)
- %Re-surface Body Routes
- %Re-surface Routes by group
- %Re-surface Exits
In the White Paper, we typically show the most essential KPI first in bold – here, it’s the % of Body Routes. The White Paper provides a detailed description of what is meant by Body Routes – but for our purposes lets just consider Body Routes as the links within the main content page that the Router was designed to drive to.
So the essential Functional Measure of a Router Page is the % of links that it drives to its intended targets – hey, that’s why it’s called functionalism – the KPI’s are specifically built to measure the page’s real purpose! This is simple, easy to calculate and yet is a type of analysis that is frequently missed. The most novel aspect of the analysis is that it characterizes many links (such as other Top Nav or Home Page links) as “bad” (i.e. lying outside the function of the page).
The next two measures are just elaborations on the same theme. In addition to knowing how many visitors went in the intended direction, it’s useful to know how many went in three different un-intended directions (back, top – or lateral, and exit). Each of these outcomes is sub-optimal, but in most cases a top is better than a back and a back is better than an Exit. Again, these are all simple to calculate and form the basic measurement for this page type.
The Exit Propensity is just a technical elaboration on Exit Rate. It is slightly more elaborate to calculate (I’ll be providing KPI calculation details in coming blogs) but provides essentially the same information as Exits.
The next set of behaviors repeat the original set but focus on Re-Surface behaviors – cases where a visitor comes to a Router Page, drills down and then comes back up again. Why do we have these metrics? Quite simply because our real-world experience measuring this page type had been that some Router Type pages perform much better on Re-Surface than others and that there were personalization and ad serving strategies that could sometimes take advantage of re-surface behaviors. So the fact that these metrics are there is really a claim about the real-world of web site behavior – namely, that of all the kinds of things you might measure about a page like this, re-surface is among the more interesting for this type of page (we rarely look at re-surface rates for any other type of page).
As in some other cases, the secondary metrics are rather more complex to actually do than the primary metrics. However, re-surface metrics are obtainable in both SiteCatalyst and HBX (I’ve include an extract from my post on the WA Forum on calculating this metric) and meet, therefore, our basic requirements.
I think the Router Page KPI’s are a reasonable illustration of what emerges from Functionalism – a highly specified way to think about the success of almost every page type on your site. And while no methodology can or will ever replace sound thinking, common-sense and business knowledge, it’s our belief that even high-quality, experienced analysts can greatly leverage their work by applying many of the basic concepts in Functionalism.
Like most formal methods, Functionalism is simple in concept – almost surprisingly so. And, like most formal methods, it embodies a great deal of what many practitioners will consider normal everyday practice. This can easily lead to it being wrongly dismissed as “just a pretty gloss on what we already all know and do.” By supporting “what we all know and do” with a very formal, clear and well-articulated structure, it can – we believe – make “what we all do” quite a bit better!
Extracted from the WA Forum – Calculating the Re-Surface Rates in HBX
You have to create a visit based active segment with the criteria being that the page in question was viewed once. Then you create an active segment (visit) with the criteria being that the page in question was viewed more than once. Now, you have a % re-surface by dividing the two visit counts from each segment. Even cooler, by subtracting the one-visit “next pages” counts from the all visits (no active segment)”next pages”, you get the difference between initial view next steps and subsequent view next steps. That’s a great way to find out if visitors use a page differently on re-surface.
Gary Angel is the author of the “SEMAngel blog – Web Analytics and Search Engine Marketing practices and perspectives from a 10-year experienced guru.