Category: Web


Metrics: Time on site

Average time on site is flawed. TOTAL time on site (TTS) is more robust. It’s the total time spent on the site by all (target) users.

With this metric: some users spending more time on the site is always good; more users is always good.

Other issues are detailed here. For example, “bounces” count as zero seconds on site. (Some people may argue that penalising bounces is a good thing).

If your web analytics don’t support TTS then you can calculate an approximation: (Average Time on Site) x (Unique Users)

As for all metrics, it’s good to focus on your target audience. If you use Ucom or comScore then you could calculate a multiplier. For example, if you reach 25% more of your target audience then multiply TTS by 1.25

The Scientist

You are measuring traffic, right? Number of hits. Unique users. Good, just checking.

Do you measure the impact of each feature? Metro don’t (watch this space). Here’s an example.

We recently redesigned our masthead – the header, logo, background, navigation, search tool and banner space. It took us quite a while.

Some people thought this was a big step forward. Some people thought it was a big mistake. You can compare the before and after here.

So who was right?

We don’t know. Seriously, we are completely in the dark.

Overall, traffic has gone up. Maybe this is due to the masthead. Maybe traffic would have gone up more without the new masthead. There are many factors: The News of the World shutting down, other changes to our site, what popular shows are on TV and even the weather.

We are in the dark, but thankfully there is a light switch. It’s called AB testing. Google have a free, easy-to-use service for it. Thanks Google!

AB testing splits users into two random groups. One group gets the new feature, one group doesn’t. You can compare the behavior of the two groups to see what impact the feature has. It’s a controlled experiment.

AB testing can give some surprising results. Here is an example from the killer book Super Crunchers (chapter 2). The credit card company Capital One used AB testing on their mailouts for loans. They found that putting a picture of a smiling woman on the mailout had as big an impact as reducing the interest rate on the loan by 4.5%.

Discovering AB testing is like when the cops in The Wire discover phone taps.

AB testing has some caveats. Firstly, you need enough traffic for the randomness to even out (no problem for Metro). Secondly, the approach isn’t very mature for mobile apps.

And it’s actually called multivariant testing but AB sounds cool so i’ll stick with that for now.

AB testing gives product owners the empirical data they need to make decisions. Empirical data based on controlled experiments. Do not underestimate the power of this. It is the foundation of science. It has made possible our technological wonderland.

The alternative is to base product decisions on assumptions, and you know what they say about assumptions :-)

I’m going to show you how to use the Metro API.

This post is aimed at javascript beginners but i recommend you try out this fun interactive introduction first - http://www.codecademy.com/

Step One. Create a  file on your computer. Call it something like “metro.html”.

Step Two. Copy the HTML below into it. Open the file in a browser and it should say “My metro articles”. (Not very exciting yet, i know).

<html>
<body>
<div id="myElement">My metro articles</div>
</body>
</html>

Step Three. Use the Metro API. You can see what the API looks like here.

Copy the following code before the </body> tag…

<script>
// This function will process the data
function init(apiData) {
  // Init variables
  var myHtml = '';
  var article;

  // Loop through each article in the feed, generating html as we go
  for (var i = 0; i < apiData.entries.length; i++) {
    article = apiData.entries[i]; // Get the relevant article
    myHtml  = myHtml  + "<a href=" + article.alternateLink + ">" + article.title + "</a></br>";
  }

  // Insert our html into the page
  document.getElementById('myElement').innerHTML = myHtml;
}
</script>

<script type="text/javascript" src="http://www.metro.co.uk/api/articles/?page=news&callback=init"></script>

That’s it!

Refresh your browser and you should see a list of metro links. If you have any problems (and there usually are)…  just shout. To experiment more try our API Explorer (beta).

Form tools

It’s often useful for non-techies to be able to embed forms in a page. Here are a few tools which might help…

Enjoy!

Atom on JSON

Atom is a widely used XML format for syndicating content. But what if you want to use JSON? You can use Google Data Protocol, but the format carries a lot of XML baggage with it. It doesn’t really play to the strengths of JSON. IMO, JSON’s strengths are:

  • Simplicity. No namespaces. (The flip side of this is that JSON isn’t as extensible as XML).
  • Lightweight (in terms of file sizes)
  • Readability
  • Easy to navigate the object graph in javascript

One excellent use case for JSON is syndicating content for mobile HTML+JS apps (using PhoneGap, for example).

Here are some JS-friendly Atom examples (and their XML equivalents). A few things to note:

  • In addition to Atom, the structure borrows from MRSS and OpenSearch
  • Atom allows for several content types. To keep the structure simple, i’ve assumed a type of “xhtml”. This makes sense for HTML+JS apps.
  • Because this is JSON, XHTML content can be a fragment (without a parent node). This avoids additional nesting of data.
  • Atom supports many types of link but there are two which play a pivotal role – i think the 80/20 rule applies. They are promoted to first class citizens.
    • rel=”self” is crucial for providing detailed data for each feed entry. In our case, “application/json” makes sense.
    • rel=”alternate” is useful for providing an RSS style link to an HTML page. In our case, “text/html” makes sense.

I think this would have value as a JSON microformat/schema (AtomJS?).

It would increase portability of feeds, apps, tools and services. It would mean less documentation of proprietary feeds. It could act as an “anchor” for feed formats (changing formats is painful for servers and clients). In short, it can make everyone’s life easier.

The format is as extensible as any other (non-namespaced) JSON format.

What do you think? Add a comment below!

Follow

Get every new post delivered to your Inbox.