In a post from June – 5 key takeaways from the Google Analytics User Conference – we mentioned the use of GA’s enhanced ecommerce report for content (credits for the idea go to Simo Ahava). And more importantly, told your, our reader, that we were going to implement it on GEEK. So a month ago we did, and after our first full month of measuring, we’d like to share our results.

Use shopping behaviour to track reading behaviour####

Enhanced ecommerce has some nice reports. The first one is Shopping behaviour. This shows the your shop performance in five steps:

• All sessions;
• Product views: sessions where a visitor sees a product detail page;
• Add to carts: sessions where a product is added to the shopping cart;
• Checkout: sessions that enter the checkout; and
• Transactions: sessions that have a successful transaction.

For e-commerce, this is really handy, but for content not so much. Luckily, following the guide of Simo Ahava, it translates to content easily:

• All sessions;
• Product views > Article views: sessions where a visitor opens an article page;
• Add to carts > Start scrolling: sessions where users have a scroll on an article page;
• Checkout > percentage read: sessions where users have scrolled at least 25%;
• Transactions > full reads: sessions where users have a full read.

We’ve set the full reads to a scroll reach of at least 75% and a time on article of at least 60 seconds. We use a 75% scroll to ignore the comments and suggested posts part of the article. The time limit is used to ignore scanners that don’t actually read the full article.

For GEEK, this resulted in the following graph:

This shows us that for GEEK, content consumption is pretty well, and that about 40% of visitors read an article.

Use checkout behaviour to track scroll behaviour####

Besides the shop behaviour flow, enhanced ecommerce allows you to set up a custom checkout report. With this report, you can drill down into checkout behaviour. Normally, this would contain all the steps between add to cart and transaction, for example:

• Personal details;
• Payment details; and
• Order overview.

For reading behaviour, we’ll use this te measure scroll reach on article pages:

• 25% read;
• 50% read;
• 75% read; and
• 100% read.

With this, we can easily see what’s the main dropoff point of our articles. If, for example, a lot of sessions leave the page after a 50% read, our articles might be too long. Let’s take a look at the actual example from GEEK:

As you can see, our main dropoff point is at the 100% read mark. This tells us that 75% of sessions leave an article between the 75% and 100% read mark. We even have an increase to transactions after that.

As mentioned before, we ignore the comments and suggested reads part for the full read, though the 75% mark might not be accurate for the longer articles. If you want to make it more accurate, you’ll want measure the scroll reach for just the article part of a page.

Use revenue to measure word count####

Another clever use of the report for content, setting the word count as revenue. This gives you insights in:

• How many words do people read?
• How many words do people read on average?
• How many read words does an article generate?
• What’s the best performing article looking the amount of reads?

To clarify tings, here’s an example of product, or rather article, performance report of GEEK:

First of all, you can instantly tell how many words were read on your blog. For GEEK, september generated over 1.000.000 read words (Booyah!). To answer the questions above with this report, try the following:

• 1: How many words do people read? Easy, just look at the product revenue on the top left of the table.
• 2: How many words do people read on average? Again, easy. Use the average price on top of the table.
• 3: How many read words does an article generate? Filter the table on revenue and the articles are listed on total words read.
• 4: What’s the best performing article looking the amount of reads? All you have to do is filter on quantity.

This way you can see which content works. For example: a large post with a few reads may generate quite some read words. This might indicate that it’s a good post for small audience. If a short article generates a lot of reads, it might be an quick snack that’s easy to ready for a lot of readers.

Bring in the authors####

An extra option when using enhanced ecommerce is the use of custom product dimensions. For content, these translate to custom article dimensions.

We’ve currently set this up for authors. Although we think writing for GEEK isn’t a competition, it’s nice to see how authors are performing.

Let’s look at a custom report for authors:

First things first: props to Siebe for being the most read author of September.

Secondly: what’s interesting for us is the number two spot of Erwin. He wrote just one post at the time of writing this post and is at the number 2 spot of authors. Compare that to my rank, it’s at the 6th spot. I write quite some shorter articles. What does this tell us? It could be a number of things:

• Long articles work better than short ones;
• Google OAuth 2 is a more popular topic than analytics;
• Erwin has a better style of writing that I do.

What’s certain is that this data helps you understand content performance, and find ways to make it better.

Next steps####

The next step is to add more custom data to the report. One thing we’re adding is a size treshhold:

• 0-500 words : small article;
• 500-1000 words: medium article;
• 1000+ words: large article.

This will make it easier for us to tell if long posts work better than short ones. The change is live starting today. We’ll write short update on our findings next month.

What would you add to this data set if you had the chance? Let us know in the comments and we might actually test it on GEEK.

UPDATE: on November 2, 2015 we’ve published a post on article size. Read it here.