Friday 20 November 2009

First/last click campaign attribution and onsite purchase trigger analysis techniques.

Overview
Understanding which traffic sources contribute to successful outcomes on your website is crucial to maximising Return On Investment. By default Google Analytics supports last click attribution. This means a customer who starts a session with a click on the Adwords Campaign 1 (see below) and then starts a new session with a click on Referrer 1 and ends in the purchase of four products will result in Referrer 1 being attributed with the 'credit' for all four sales.



See the Google Conversion University for more details.

We can add the utm_nooverride=1 parameter to the links in our campaigns to ensure the first campaign that is clicked is credited for sales and goal outcomes:



So, we can measure which marketing initiatives incentivise users to visit our sites but we can't so easily see what motivated a user to complete a goal or purchase while on the site – what is driving positive outcomes from user journeys during their visit? We can't easily see this with default techniques.

You can have your cake or eat it...but not both.

Moneyspyder has developed a technique that couples first or last click attribution data to measure brand engagement with last-click-before-purchase triggers on a 'per basket item' basis to reveal purchase or goal completion triggers.

We say you should have your cake, eat it and have extra sprinkles too!

Technique
We modified the Moneyspyder ecommerce engine such that the purchase trigger (last click before adding to basket/cart) is recorded in the Google Analytics clickstream data as well as being recorded against each order item in the basket such that the value can be used in the 'Category' field on the Google Analytics ecommerce tracking code.

Purchase triggers may include clicking on a feature product on the homepage, clicking on products in on-site search results, related product clicks, products in category listings, product clicks in email campaigns, organic search results and of course 'direct' visits from bookmarks. The limit here is your imagination!

Recording product clicks from on-site or external search engine results generates great purchase trigger data. Using the search term to supplement the data is a golden opportunity not to be missed. Likewise, related product clicks should record the product that was related to the purchased product and category list clicks should record the category.

This modification to our ecommerce engine was straightforward – it should simple be on your software too.

By now you will get a clear picture as to what extra data is being recorded. Now, what can you do with it?

Insights
First of all, let's take a look at the pure clickstream data:



From the standard content report in analytics we can see how clicks on the 'sky-lantern' product came from a multitude of different sources:


  • search for lights

  • email campaign

  • linked from other products

  • category links

  • direct



We can see unique page views required for conversion metrics, average time on page, bounce rate, exit % and the super insightful $index. If the scope of this technique stopped here, we'd be pretty happy already with the extra insight we have on customer journeys. The extra sprinkles arrive when we consider the magical 'outcomes'.

As described above, of vital importance to getting maximum value from this technique is to record the last click before 'add to basket' in the clickstream data AND the transaction 'category' data. These sets of related data enable amazingly fine grained conversion metrics to be retrieved. For example, we can dig into the search listed above for 'lights' (the bottom row in the table). That's a pretty handy $index! Looking deeper we can see this search generated some pretty handy revenue over a short period of time:



Applying classic analytical techniques yields further insight:



If you're not convinced as to the merits of this technique by now, and indeed, you can get a lot of this data from the onsite search report then we shall take a mighty leap and look at category conversion metrics for the 'Best Sellers' category based on the landing page.

In the Google Analytics report below (Ecommerce → Product Performance → Categories), it looks at first glance that using the homepage as a landing page work pretty well. Sure, lots of revenue but that's not all!



When we take unique pageviews into account we can see the conversion rate for the best Sellers category when the homepage is the landing page is a respectable 4.8%. However, the Sale and Festive Season (Christmas) categories both out perform the homepage as landing pages at 5.4% conversion and the Best Seller category page as a landing page converts at 5.6%.

It's worth bearing in mind at this point exactly what this data means. A customer entered the site on a particular landing page, found their way to the Best Sellers category and put a product in their basket that they bought – the Best Sellers category page was a trigger to purchase. They liked the page and the products so much that they bought – just what site owners want to see and hear.

Conclusion
Through simple modification to our ecommerce engine, Moneyspyder has revealed finer grained, segmentable insights into the aspects of customer journeys that trigger positive outcomes – goal completions or purchases that include first and last click attribution.

This functionality is a great facility for conversion professionals to identify optimal customer journey paths and focus optimisation efforts with greater accuracy and effectiveness.

The modifications required for this technique are entirely portable and are in no way specific to the Moneyspyder ecommerce platform – we really encourage you to explore this technique.

Moneyspyder Biog:
We are a Google Conversion Professional and develop and host state-of-the-art ecommerce solutions using Ruby on Rails. We continuously improve customer experience using web analytics, split-testing and regular site enhancements based on web analytics data.

Monday 2 November 2009

Google Analytics: Expanded Mobile Tracking for Mobile Rails sites

Expanded Mobile Reporting - Introduction
Google recently announced expanded tracking for mobile apps using server side code. PHP, Perl, ASPX and JSP are supported as standard. As a dedicated 'Rails house' Moneyspyder has published a sample application for Mobile sites using Rails to broaden the usage of the product.

The need for this sample app is driven by the current use of javascript for tracking clickstream data. There are still a fair number of mobile devices out there that do not support client side javascript which can leave a sizable hole in your clickstream data. Using serverside code to reproduce the behaviour caters for these devices.

Preamble and cavets
The sample app is available for download. This is just a skeletal sample app and requires more thorough testing if deployed in the wild. We'd be keen to hear feedback of course as this is just a starting point....it ain't production ready!

Moneyspyder accepts no responsibility for loss or harm to data caused by using this sample app yadda yadda...

With that out of the way, some details.

Details

Download the app

Files

  • routes.rb

  • environment.rb

  • ga_helper.rb

  • ga_controller.rb

  • index.html



Two routes are used, only one is really required. The utm_gif action (served by the ga_controller.rb controller) is responsible for sending basic request info to the action and the action builds the remainder of the request details and sends them to ga, returning a 1px transparent gif.

The GA Account idientifer is saved in environment.rb. You might want to store it in a configuration yml file, the db or whatever your favourite place is...

The utm_gif_url helper method builds the utm_gif request. This is used in index.html for demonstration purposes.

ga_controller.rb rquires cgi, digest and open-uri. CGI is used for urlencoding strings. digest is used for the MD5 stuff. open-uri is used to send the request to Google analytics.

utm_gif is the only public method needed. response headers are set appropriately and send_data is used to return the transparent gif image. Requesting the gif through the private track_pageview method is where the magic happens.

In summary, all the usual name value pairs that are appended to the _utm.gif request to Google Analytics by ga.js are collected and then sent to Google Analytics using the private send_request_to_ga method. open-uri allows us to send this request programmatically. This might well be a nice plave to build in some error handling...

Once the request is done, the gif data is returned and the page is rendered - sweet.

You should be able to spin upthis little rails app easily enough using webrick on your local machine i the standard rails way and hit http://localhost:3000. (no support is offered by Moneyspyder for this setup - it's pretty standard stuff)

You'll see something like:



Gotcha and thoughts
If bots are hitting your mobile site or you use this tracking code technique insteaqd of ga.js (Hmmm?!) then you'll likely get a lot of traffic from bots - better filter the requests that get tracked.