Content as Ecommerce

In December, Simo Ahava posted an article where he explained how using concepts from ecommerce and implementing those on his blog helped him gain new insight. A brilliant article which I suggest you read. I’ll wait.

Read it? Looks good, doesn’t it?! I especially like the distinction skimmer versus reader.

Simo implemented everything he did using Google Analytics, so how about I show you how to do it using Adobe Analytics instead? And maybe I could throw in some DTM, too.

Blog Commerce

Simo mapped things that happen on his blog to the ecommerce capabilities of Google Analytics. That should be even easier with Adobe Analytics, given that we have a bunch of Success Events and flexible eVars.

His favourite report is the “Shopping Behaviour” report, a nice funnel with 5 steps:

1. Overall Visits
2. Visits that included loading an article
3. Visits that included some scrolling on an article
4. Visits that included scrolling to at least one third of an article
5. Visits that included scrolling to the end of an article and staying on it for at least 60 seconds

If you have read this blog for some time, you’ll be able to define the tracking for this yourself. All we need is some Javascript and 4 Success Events to capture the steps of the funnel.

I would go further and just include the two additional events that Simo mentions in the context of his “Checkout Funnel”: scrolling to at least two thirds of the page, and scrolling to the bottom.

So we end up with a 7-step funnel that will look somewhat like this:

You can choose, of course, what the metrics should be, exactly. If you want to count every time someone scrolls an article, use a normal event. If, however, you want “Visits that included scrolling”, serialise the events that you are using. (I’ll write about that at some point.)

How?

Let me walk you through the implementation. I modified Justin Cutroni’s code quite a bit to make it work with my blog, then added the Javascript straight to my template to see whether it worked.

To track the individual steps, I used Direct Call Rules in DTM. I just called _satellite.track() straight from my code.

This is not ideal.

It creates an additional dependency between my page code and DTM, which means that if I ever want or have to change Tag Management Systems, there’d be more things to change than necessary. We want to limit the use of Direct Call Rules as much as possible.

I’ll get back to that later.

For now, this is my code:

I guess so far, nothing is really different from what Simo did. Yes, I use a different TMS, but the principles really are the same.

One cosmetic difference: I used console.log for debugging rather than alert. This way, I won’t get into trouble for letting debug stuff slip into production.

Money, or rather Cost

Take note of another thing: I am actually tracking the steps of the “funnel” as they happen.

Remember a couple of weeks ago when I wrote about tracking forms without wasting money? Back then you learned that each call to Adobe Analytics costs a small amount of money, because that is how Analytics is billed. So sending out a tracking request on each step does increase the “server call volume”, which in turn means you’ll be paying more.

I can see two ways of minimising that:

1. Delayed tracking — just like I showed for forms, you could collect all the information in a cookie, then track it on the next page
2. Reduced Granularity — go from 5 or 7 funnel steps to 3 and you’ll have a lot less server calls

Both of those solutions have their pros and cons, of course.

Delayed tracking will mean that people who only ever read one article slip through the net. There is no subsequent page on which you can track what they did. But it will give you the full set of data for those who do load more pages on your site.

Reduced granularity is straight-forward to implement and test. You’ll get less insight, of course.

It is ultimately up to your friendly marketer to decide, how much the insight is worth to her.

DTM

Back to the Direct Call Rules.

I said they create a dependency I didn’t like. So how do we handle that?

An idea would be to actually inject the whole block of Javascript via DTM rather than putting it into the blog article template.

If you did that, removing DTM would also remove everything I’ve done here, including the calls to the Direct Call Rules. The whole thing would be neatly contained.

Downside: I would have to re-import it all into the next TMS if ever I changed TMS.

Another way would be to only inject the actual call of the Direct Call Rules using DTM.

How about we define a helper function that by default does nothing, then re-define that same function using DTM, overwriting it so it does call Direct Rules?

That sounds better.

Or, what if we just simply defined that helper funtion to check for the _satellite object before it called _satellite.track(). Removing DTM would cause the check to fail and the browser would just do nothing.

I actually started out with the third option, because it was easy.

I played around with option 2 as well, using DTM to overwrite a (dummy) mytrack function. There can be a race condition, though, when someone reloads a page half way down. In my naïve implementation, the Event Based Rules could sometimes fire before the Page Load Rule that would overwrite the function, leading to lost event tracking. Not a big issue, I guess.

The real solution is of course option 1, which I will at some point build, I’m sure. If I do then I’ll write about it.

Going Further: Reader Type

I mentioned that I liked the “reader type” tracking. Out of the box, we can run reports separately for readers and skimmers, which is nice.

Here is something we could do beyond segmenting: pathing reports. The question is whether it’s always the same people who read versus skim, or if readers do both. Pathing will answer that question.

But there’s a problem.

We’re talking about a blog. In my case, people come to the site once or twice a month, then read (or skim) one single article.

The problem is that pathing only works within a Visit (unless you’re using Discover Ad Hoc Analytics). Hm…

How about we change the scope of the Data Element to “Visitor”?

Say you read this article, so when you reach the bottom, the tracking code puts you down as a “reader”. The Data Element stores this. Next time you come to the site, when loading the article, I can track reader type (it’s still in the Data Element). If you now go to the end of the article, a new reader type value will be written. If it is different (“skimmer”), pathing will see a change.

Bingo!

So thank you, Simo, for the original idea, and I’m curious where this’ll lead to over time.

Feel free to ask me for the JS code if you want to implement something similar!