Latest Tweets:

*36
Behavioural targetting in Google Analytics
There’s a great video where they talk about a lot of stuff including behavoural targetting in google analytics here:
http://analytics.blogspot.com/2011/03/web-analytics-tv-17.html

First of all, I’d just like to say how much I <3 google for actually taking the time to answer questions that people ask.
Basically what they have to say about behavoural targetting though, is that at it’s core, website optimizer and google analytics don’t offer that feature. However, they point out that the guys at btbuckets have got a great google analytics integration that supports this. Link here:
http://btbuckets.com/

The image above is from the btbuckets website; I love their intro video.
Just goes to show, you don’t have to spend a fortune on Omniture to get really great data analytics and targeting tools. :)

Behavioural targetting in Google Analytics

There’s a great video where they talk about a lot of stuff including behavoural targetting in google analytics here:

http://analytics.blogspot.com/2011/03/web-analytics-tv-17.html

First of all, I’d just like to say how much I <3 google for actually taking the time to answer questions that people ask.

Basically what they have to say about behavoural targetting though, is that at it’s core, website optimizer and google analytics don’t offer that feature. However, they point out that the guys at btbuckets have got a great google analytics integration that supports this. Link here:

http://btbuckets.com/

The image above is from the btbuckets website; I love their intro video.

Just goes to show, you don’t have to spend a fortune on Omniture to get really great data analytics and targeting tools. :)

AB Testings vs. Analytics
I&#8217;ve just been reading &#8216;Web Analytics 2.0&#8217; by Avinash Kaushik, and it basically confirms my oppinion of the web analytics world in general at the moment. That is, basically, in a 445 page book, 17 pages are devoted to A/B &amp; multivariate tests and the remainder, broadly speaking to analytics.
It really clued my in when I read this: &#8220;Without a doubt, A/B testing is the best technique to start your testing journey. Because of its inherant simplicity, you can get going quickly, and you can engergize your organization while having some fun. In addition, the results are easy to communicate. You don&#8217;t have to worry about multivariate tests, regressions, or other such (lovely) things&#8221; (Web Analytics 2.0 by Avinash Kaushik, Wiley Publishing, Canada, 2010, p198)
Is the analytics world really so self-absorbed it thinks that generatic metrics is more important than testing? It seems so.
I can only speak from my own experience, but broadly, as I see it, web analytics falls into two categories:
1) I want to improve my website conversion rate.
2) I am spending $X on online / DM / TV / etc marketing, which is most effective for cost per acquisition?
Over whelmingly the metrics that people seem to be interested in generating are either from (2), or for (1) with no real understanding of why they are gathering them.
Let&#8217;s collect bounce rates for our website!
Why?
Erm&#8230; because&#8230; we&#8230; should, write a report about that. Ok, how about we collect first touch / last touch information for our various online marketing strategies so we can see which one gives us the best cpa.
How?
Ah&#8230; we&#8217;ll um, tag them all and then when they arrive at the website we&#8217;ll compare the conversion rate of the different incoming items and then rank them.
So, basically an A&#8230;N test where the traffic source is different but the content served is the same default content each time?
Ah&#8230; well, yes.
Analytics should follow testing
I couldn&#8217;t be more opposed to the approach in the example above. Analytic metrics should always be either to track conversions for a test, or to discover new areas on the website that require attention and testing.
Collecting data for its own sake is pointless, and I feel that is widely accepted.
So why is so much focus given to collecting metrics?
Surely the core focus should be on testing, and have to derive and implement the metrics required for that testing. An A/N test doesn&#8217;t have to literally be two visually distinct pages. It&#8217;s still an AB test when you are comparing the conversion rate of two seperate pages.
Calling it a test formalizes the process of hypothesizing, testing and comparing two sets of data. You can do that in a spreadsheet, in the web analytics tool of your choice, or what ever you choose.
The key though, is making sure that:
1) The data you gather is statistically relevant.
2) You document and accumulate the learnings from various tests.
3) Over time, improve the conversion rate of your website.
It really amazes me that so little attention is given to the praxis of web analytic testing, and so much to the process of setting up and understanding metrics which have no practical application.

AB Testings vs. Analytics

I’ve just been reading ‘Web Analytics 2.0’ by Avinash Kaushik, and it basically confirms my oppinion of the web analytics world in general at the moment. That is, basically, in a 445 page book, 17 pages are devoted to A/B & multivariate tests and the remainder, broadly speaking to analytics.

It really clued my in when I read this: “Without a doubt, A/B testing is the best technique to start your testing journey. Because of its inherant simplicity, you can get going quickly, and you can engergize your organization while having some fun. In addition, the results are easy to communicate. You don’t have to worry about multivariate tests, regressions, or other such (lovely) things” (Web Analytics 2.0 by Avinash Kaushik, Wiley Publishing, Canada, 2010, p198)

Is the analytics world really so self-absorbed it thinks that generatic metrics is more important than testing? It seems so.

I can only speak from my own experience, but broadly, as I see it, web analytics falls into two categories:

1) I want to improve my website conversion rate.

2) I am spending $X on online / DM / TV / etc marketing, which is most effective for cost per acquisition?

Over whelmingly the metrics that people seem to be interested in generating are either from (2), or for (1) with no real understanding of why they are gathering them.

Let’s collect bounce rates for our website!

Why?

Erm… because… we… should, write a report about that. Ok, how about we collect first touch / last touch information for our various online marketing strategies so we can see which one gives us the best cpa.

How?

Ah… we’ll um, tag them all and then when they arrive at the website we’ll compare the conversion rate of the different incoming items and then rank them.

So, basically an A…N test where the traffic source is different but the content served is the same default content each time?

Ah… well, yes.

Analytics should follow testing

I couldn’t be more opposed to the approach in the example above. Analytic metrics should always be either to track conversions for a test, or to discover new areas on the website that require attention and testing.

Collecting data for its own sake is pointless, and I feel that is widely accepted.

So why is so much focus given to collecting metrics?

Surely the core focus should be on testing, and have to derive and implement the metrics required for that testing. An A/N test doesn’t have to literally be two visually distinct pages. It’s still an AB test when you are comparing the conversion rate of two seperate pages.

Calling it a test formalizes the process of hypothesizing, testing and comparing two sets of data. You can do that in a spreadsheet, in the web analytics tool of your choice, or what ever you choose.

The key though, is making sure that:

1) The data you gather is statistically relevant.

2) You document and accumulate the learnings from various tests.

3) Over time, improve the conversion rate of your website.

It really amazes me that so little attention is given to the praxis of web analytic testing, and so much to the process of setting up and understanding metrics which have no practical application.

*2

T&T Campaigns: Two mistakes.

So, we were having an issue were no conversions were being recorded in T&T. Two weeks and two epic workshop sessions debugging the problem and it turns out we were doing two things wrong.

Test and Target Mistake Number 1: Not invoking the SiteCat plugin.

Despite the various things we were told at different stages, unless an mbox is manually specified on a page, or the SiteCat T&T plugin (mboxLoadSCPlugins; its in the mbox config in T&T) is invoked, T&T cannot target conversions on a page.

Test and Target Mistake Number 2: Not targeting the right mbox.

When you a conversion mbox, the mbox must be targettied in the campaign, or the conversions will not be recorded. This is not targetting the mbox in the conversion metric list (although you have to do that too), it’s at the very top where you target the mboxes for the entire campaign.

…and yes, that does mean each of your campaign offers has multiple mboxes associated, some of which (conversion mboxes) show the default content in all cases.

Hopefully that helps anyone else who’s having the dreaded ‘no conversion’ problem with T&T.



*1

Omniture site sections.

The mysteriously named Omniture variables continue to amaze me.

The ‘site sections’ report uses the s.channel variable to populate the content.

Why?

I mean, is there really any difference between this and having a configuration option that allows you to pick your ‘SiteSection’ eVar and set that as the data source for the site section reports?

Weird.

Apple’s Three Laws of Developers

yourhead:

  1. A developer may not injure Apple or, through inaction, allow Apple to come to harm.
  2. A developer must obey any orders given to it by Apple, except where such orders would conflict with the First Law.
  3. A developer must protect its own existence as long as such protection does not conflict with the First or Second Law.

— I. Developer

+1

Reading~

Just picked up a copy of “Web Analytics 2.0” by Avinash Kaushik, and “Advanced Web Metrics with Google Analytics” by Brian Clifton.

Quite looking forward to seeing what these books have to say about analytics.

On a side note, always make sure your Omniture conversion metrics are set right. Nothing quite as annoying as running a campaign for a week in T&T and then finding you’ve set the conversion metric to ‘equals’ “sccheckout”, instead of ‘contains’ “sccheckout”… :|

Tracking the effectiveness of rotating banners
Often, as with the image above (via steampowered.com) you have a single page will multiple banners on it, and you want to track the effectiveness of individual banners.
Certainly you can run an A/B test and optimise for more effective banners, but just as a general health check and baseline conversion rate, its nice to be able to see how various banners perform, to target under performing banners for testing and optimization.
The problem is that the type of banner events we might typically collect (click tracking) can&#8217;t easily be correlated against important metrics like sales, revenue, cart adds, etc.
Omniture Implementation
In Omniture one way to do this is to select a particular eVar, and assign it a value on the campaign landing page for each banner. A little bit of work is needed on the site to accurately determine the referring url, and then set the campaign:
  var prev = s.getAndPersistValue(s.prop10,'s_pv10',0);
  if(prev == "home:landingx")
    s.eVar10 = "BannerXXXX";

Where some effort has been done to record the pagename on a previous page:
  s.prop10 = s.pageName;
  s.getAndPersistValue(s.prop10,'s_pv10',0);

(If you&#8217;re using GA, a cookie serves just as well to record the previous page).
Then your reports are nicely populated with per-campaign information. Be aware though that you should use a different id depending on the value of the referring page, otherwise you&#8217;ll be aggregating values from multiple sources.

Tracking the effectiveness of rotating banners

Often, as with the image above (via steampowered.com) you have a single page will multiple banners on it, and you want to track the effectiveness of individual banners.

Certainly you can run an A/B test and optimise for more effective banners, but just as a general health check and baseline conversion rate, its nice to be able to see how various banners perform, to target under performing banners for testing and optimization.

The problem is that the type of banner events we might typically collect (click tracking) can’t easily be correlated against important metrics like sales, revenue, cart adds, etc.

Omniture Implementation

In Omniture one way to do this is to select a particular eVar, and assign it a value on the campaign landing page for each banner. A little bit of work is needed on the site to accurately determine the referring url, and then set the campaign:

  var prev = s.getAndPersistValue(s.prop10,'s_pv10',0);
  if(prev == "home:landingx")
    s.eVar10 = "BannerXXXX";

Where some effort has been done to record the pagename on a previous page:

  s.prop10 = s.pageName;
  s.getAndPersistValue(s.prop10,'s_pv10',0);

(If you’re using GA, a cookie serves just as well to record the previous page).

Then your reports are nicely populated with per-campaign information. Be aware though that you should use a different id depending on the value of the referring page, otherwise you’ll be aggregating values from multiple sources.

*3
Conversion Reports and Additional Metrics
One of the lovely things about Omniture&#8217;s eVars is that you can use the &#8216;add metric&#8217; function on the conversion reports to add additional metrics to track events against a particular eVar.
However, this can be confusing when you look at some reports, for example, &#8216;Site Section&#8217; and see no events bound against a particular value.
The reason for this is that setting the value of an eVar replaces the existing value, obviously, but more importantly, only the current value of the eVar is used when creating event correlations.
So for example, if your site sets the site section on each page, and your user goes through a series of pages, the folow would look like this:
Landing page - Site section set to &#8216;Landing&#8217;
Cart page - Site section set to &#8216;Cart&#8217;, cart add event tied to &#8216;Cart&#8217; section.
Checkout page - Site section set to &#8216;Checkout&#8217; checkout event tied to &#8216;Checkout&#8217; section.
Thus, when you look at the site section conversion report and filter by &#8216;Landing page&#8217; you&#8217;ll see exactly zero events for cart add or checkout, despite the landing page having been involved in generating these events.
What you really need is an additional eVar that is set ONLY on the landing page, that sets say, the landing page id or type, and is never touched again. That will result in the eVar being preserved all the way through until the checkout stage, and orders, revenue, etc. can be correlated against each specific landing page.
A lot of stuff is said about having a generic s_code.js file that simply sits on each page and always does the same thing, but lots of sub pages will require their own custom code blocks to enable this type of insight.

Conversion Reports and Additional Metrics

One of the lovely things about Omniture’s eVars is that you can use the ‘add metric’ function on the conversion reports to add additional metrics to track events against a particular eVar.

However, this can be confusing when you look at some reports, for example, ‘Site Section’ and see no events bound against a particular value.

The reason for this is that setting the value of an eVar replaces the existing value, obviously, but more importantly, only the current value of the eVar is used when creating event correlations.

So for example, if your site sets the site section on each page, and your user goes through a series of pages, the folow would look like this:

    Landing page - Site section set to ‘Landing’

    Cart page - Site section set to ‘Cart’, cart add event tied to ‘Cart’ section.

    Checkout page - Site section set to ‘Checkout’ checkout event tied to ‘Checkout’ section.

Thus, when you look at the site section conversion report and filter by ‘Landing page’ you’ll see exactly zero events for cart add or checkout, despite the landing page having been involved in generating these events.

What you really need is an additional eVar that is set ONLY on the landing page, that sets say, the landing page id or type, and is never touched again. That will result in the eVar being preserved all the way through until the checkout stage, and orders, revenue, etc. can be correlated against each specific landing page.

A lot of stuff is said about having a generic s_code.js file that simply sits on each page and always does the same thing, but lots of sub pages will require their own custom code blocks to enable this type of insight.

*1

Today’s Site Catalyst Insight

Wow, it just goes to show. You think you understand something and then it gets blow away.

So you know eVars, those magical site catalyst properties that persist over user sessions according to the documentation? Well, it turns out they only persist on the server side, ie. on the analytics server.

If you want to actually get a value on the client side you need to save it in a cookie locally or use the getAndPersistValue plugin.

ie. This does not work:

  
  var p = s.eVar2;  
  if (p == "Old")
    s.eVar2 = "Older";
  else
    s.eVar2 = "Old";

…and this does:

  s.getAndPersistValue(s.eVar2,"s_ev2",30);
  var p = s.eVar2;
  if (p == "Old")
    s.eVar2 = "Older";
  else
    s.eVar2 = "Old";
  s.getAndPersistValue(s.eVar2,"s_ev2",30);

The getAndPersistValue plugin is available under:

Help -> Product Documentation -> Implementation -> Plug-ins.

Or you can just use a cookie.

*30
Persistent Tracking Properties in Google Analytics
In the Omniture tracking world we have two types of tracking variables; counters and persistent counters, referred to as &#8216;props&#8217; and &#8216;eVars&#8217;.
Interested in know what sort of blog posts are read more?
Add a property &#8216;tags&#8217; and record the tags associated with a page on each page view. In your reporting you can then go and breakdown your page views by the tags variable and find out which sort of blog posts are the most popular.
However, this is really just a counter and you can get basically the same information just be having your site structure right and looking at your page name reports.
Much more interesting are the &#8216;evars&#8217; that persist across a user session. That means as a user moves from page to page, the &#8216;evars&#8217; are retained, and that means you can use them for behaviour specific targeting, testing and refining conversion rate.
Great&#8230; but what about people who use google analytics?
Oddly enough google actually supports this functionality in analytics as well, using _getVisitorCustomerVar() and _setCustomVar():
  
      var pageTracker = _gat._createTacker(['UA-XXXX-1']);
      var value = pageTracker._getVisitorCustomVar(1);
      if (!value)
        pageTracker._setCustomVar(1, "NewRepeat", "New");
      else if (value == "New")
        pageTracker._setCustomVar(1, "NewRepeat", "Repeat");
      else if (value == "Repeat") {
        // Run targeted campaign...
      }   

Unfortunately google limits the key value to 1-5, meaning you can only have five of these properties.
What about cookies?
So, evars sound a lot like cookies right? Basically all they are is cookies that are stored on the analytics server instead of the local browser. So, why would you go to all this effort when you could just use a cookie?
Custom variables are not domain locked.
If you have your GA code set to run on multiple domains you can set a custom variable one site, and get it back on another. If you compare that to the hassles of trying to setup a cross domain cookie, it&#8217;s definitely a win.
The limit to at most 5 variables in google&#8217;s implementation does resistrict you a bit, but there are ways around it (more on that in a later post I think), but the really interesting thing about this is you can combine it with Website Optimizer to do targetted A/B tests, just like you can in Omniture!

Persistent Tracking Properties in Google Analytics

In the Omniture tracking world we have two types of tracking variables; counters and persistent counters, referred to as ‘props’ and ‘eVars’.

Interested in know what sort of blog posts are read more?

Add a property ‘tags’ and record the tags associated with a page on each page view. In your reporting you can then go and breakdown your page views by the tags variable and find out which sort of blog posts are the most popular.

However, this is really just a counter and you can get basically the same information just be having your site structure right and looking at your page name reports.

Much more interesting are the ‘evars’ that persist across a user session. That means as a user moves from page to page, the ‘evars’ are retained, and that means you can use them for behaviour specific targeting, testing and refining conversion rate.

Great… but what about people who use google analytics?

Oddly enough google actually supports this functionality in analytics as well, using _getVisitorCustomerVar() and _setCustomVar():

  
      var pageTracker = _gat._createTacker(['UA-XXXX-1']);
      var value = pageTracker._getVisitorCustomVar(1);
      if (!value)
        pageTracker._setCustomVar(1, "NewRepeat", "New");
      else if (value == "New")
        pageTracker._setCustomVar(1, "NewRepeat", "Repeat");
      else if (value == "Repeat") {
        // Run targeted campaign...
      }   

Unfortunately google limits the key value to 1-5, meaning you can only have five of these properties.

What about cookies?

So, evars sound a lot like cookies right? Basically all they are is cookies that are stored on the analytics server instead of the local browser. So, why would you go to all this effort when you could just use a cookie?

Custom variables are not domain locked.

If you have your GA code set to run on multiple domains you can set a custom variable one site, and get it back on another. If you compare that to the hassles of trying to setup a cross domain cookie, it’s definitely a win.

The limit to at most 5 variables in google’s implementation does resistrict you a bit, but there are ways around it (more on that in a later post I think), but the really interesting thing about this is you can combine it with Website Optimizer to do targetted A/B tests, just like you can in Omniture!