Measuring Your Site’s Analytics Velocity
Posted by Gary Angel
For many types of systems and measurements, the rate of change is more important than the actual measure. In physics, g-force is a function of acceleration not speed – no matter how fast you are traveling, you feel at rest as long as your speed doesn’t change. In the world of business, stock traders often focus on “momentum” – how rapidly a stock or market price is moving up or down.
And in web analytics, we often care more about whether traffic is going up more than its true absolute level. But this focus on rates of change, though something of a truism, hasn’t been consistently applied in many types of online reporting. In this short series, I’m going to discuss some areas of online measurement where concepts of rates-of-change and velocity haven’t been widely adapted but are, nevertheless, extremely useful.
Content Evaluation / Editorial Reporting
Nowhere is the concept of rate-of-change/velocity more important than when it comes to creating media metrics for editorial reporting. Raw numbers about article consumption are almost meaningless except when understood in the context of how long the article has been in circulation and what position it has been given during that time. If you’re providing your editorial staff with a daily report on content page views, you are forcing them to put each article in that context: mentally doing the arithmetic of when an article was pushed, what position’s it’s held, and, given those two facts, how that compares to previous content performance. That’s a lot to hold in your head and it makes using those reports much more difficult than it ought to be.
Using concepts of velocity, you have the ability to deliver crisper, far more informative editorial reporting.

This type of report uses an average of previous stories velocity curves (by time & position) to create a predicted interest line (in blue) for each article. It then maps the actual usage velocity (in red). This gives a simple, precise, and accurate depiction of how well a story is performing relative to proper expectations; it shows not only whether the story is more popular than average but what legs it has and how long it should probably stay in rotation.
To me, this is another example of what we at Semphonic call Analytic Reporting – reports that answer questions instead of just raising them.
Of course, a straightforward velocity report isn’t available out of the box in pretty much any web analytics solution – you have to do some work.
First, you need to create some metadata about the article in the web analytics solution. There are typically two ways of doing this. You can push basic information (like publish-date and position) as variables to be captured by the tag in real-time. Alternatively, you can push a content-id as a variable (or as part of the page name) and then transfer the metadata to the web analytics system (for example in Omniture this would be a SAINT file, in NetInsight a DataConduit).
Keep in mind that constructs like SAINT work pretty well for most article meta-data (e.g. push-date, author, service, length) but can be problematic for something like position. SAINT changes all of the data being viewed – regardless of whether it’s past or present. So you can’t capture the fact that an article may have been position 1 on the 24th of July and position 4 on the 25th using a SAINT table for metadata. This means that variables like position that change over time must be captured by the tag in real-time.
Having the push-date and positions for an article makes it easier to understand its performance, but it isn’t enough to make editorial reporting as easy and powerful as it should be. Web Analytics solutions don’t give you much flexibility in report generation and variable calculation – so getting to the data you really want – traffic by position and time since push date is still very difficult even when you’ve captured the push-date and the position in the data stream.
To make reporting easier, I recommend doing a little more pre-processing on the records. In Omniture, for example, you do this using Vista Rules. By combining two Vista Rules, you can get to the information you really need into a report without a lot of complex segmentation or correlation. The first Vista Rule is the TimeStamp Rule. This simple, very common rule, just places the time stamp in a variable for every server call. The second Vista Rule you need is custom; it calculates the difference in hours between the time stamp and the push-date variable and saves this difference in another variable. You can really make your reporting easier by concatenating that difference and the position together in a single variable.
Keep in mind that while I’ve described all this as happening with Vista Rules, it can be done in other solutions as well (with DataConduits and processing rules in NetInsight for example) and it can be done in ANY tag-based solution using coding in the tag. So no matter what solution you are using: from Google Analytics to DoP, it’s possible to derive this simple but powerful metric of content activity by time from push-date and position.
What you get when you do all this work is a variable with content id and a variable with the number of views (and visits) by position by time since push-date. You can correlate this variable with the basic TimeStamp to get the actual day of week and the hour of day – that’s important since content pushed after midnight (for example) is going to have a different velocity curve than content pushed at 8AM.
That’s pretty much all the secret sauce there is to delivering a report just like the one I started this post with.
Actual Content Velocity vs. Predicted Content Velocity is the sort of Media Metric that I think adds real value to editorial understanding and it’s a great illustration of how useful concepts of velocity really are. It’s also the kind of metric that I’d like to see discussed at X Change in our first ever industry-specific Huddle – Media Metrics (led by Turner’s Tom Cattapan). There’s so much more to measuring media than page views and time-on-site and the vast majority of really useful metrics never seem to see the light of day!
About the Author: Gary Angel is the author of the "SEMAngel blog - Web Analytics and Search Engine Marketing practices and perspectives from a 10-year experienced guru.
iEntry 10th Anniversary
SEO
Leave a Reply