Google's E-Commerce Analytics tools are absolutely invaluable to anyone conducting business on the web. But because they're designed for transactions that start and end on your website it would seem that sales generated on the web not confirmed or closed until later would get missed out of your analysis.
In this post we're going to show a quick and simple solution to make sure those all-important sales that you follow up off-line can easily be included in your E-Commerce analysis.
We're going to take for granted that you understand the basic principals of Google Analytics (GA) Goal Tracking and you've at least had a play about with the E-Commerce engine. Don't worry if you don't but it might be an idea to have a quick look at this article first.
The example: Health-Spa Reservations Enquiries
We came to this problem setting up an Online Reservations System for Grayshott Spa in Surrey. The bookings are complex and professionally tailored to the individual guest so although the guests are able to run through an online booking system, choosing their dates, spa-breaks and so on, their booking is only finally confirmed by a member of Grayshott's reservations department over the phone.
It's these confirmed bookings that we're interested in for our e-commerce analysis not un-confirmed enquiries.
The system: How the booking engine works
- A guest arrives at the site ( from a search-engine, another site, an email-newsletter etc. )
- They browse around and find something they like
- They compile a reservation for their party
- They submit their reservation
- An email, including all the details of their reservation is sent to Grayshott Reservations
- A member of the reservations team calls the guest, goes through all the details and takes a deposit
- That member of reservations clicks a link in the enquiry-email we've sent them which takes them to a panel of Spirit where they can confirm the details and close the enquiry
The problem: By the time we confirm the sale the customer's offline
The data collation part of GA is client-side, cookie based system designed to be light-weight for Google to run. Google's servers aren't doing any real work to create and collect the data, the real work is in the analysis later on. GA's farms just serve a little javascript file to do the work in your browser and all the tracking & session management is done using a cookie ( a small text file stored in your browser ) containing all the important data.
Every time you view a page on a website that's running GA this little bit of Javascript picks up your cookie belonging to that site, does a little work on it and sends a single request to Google's servers. These little requests are then logged and analysed a few hours later.
The problem we have is with Step 7.
Although we've known for some time the details of the reservation; the spa-breaks, number of nights, rate etc. critically only at Step 7 do we know for sure that the enquiry made by the guest has resulted in a confirmed booking.
But Step 7 is carried out in the browser belonging to the member of the reservations team. If we feed the data to GA here Google will forever think that it's only the people on the reservations team who are booking rooms because it will always be using the reservations team's cookies to track the e-commerce transactions.
We'd loose all that lovely information that shows us that people searching for 'health spas' on Google tend to book for 3 nights or fewer, or that September's newsletter or that article in Conde Nast has generated $n of revenue and this is precisely the data we're after.
The solution: Cross domain tracking.
The solutions, as luck would have it, has already been provided to us! It's based on the cross-domain feature designed to ensure continuity of GA information across third party shopping carts.
As a fundamental security feature of all modern browsers cookies, these tiny nuggets of text-data in your browser, should never cross the divide between one site and another.
When someone leaves http://myshop.com and visits https://secure.checkout.com to provide their credit-card details GA has to provide a method for sharing the GA tracking data between the two sites. This is GA's cross-domain feature.
The cross domain methods ( particularly _link() and _linkByPost() ) lift the cookie data out of the cookie and this data is then added to the destination web-address. The setAllowLinker() method on the desination page then tells GA to re-absorb the information about the consumer from this data in the web-address, rather than look for data in a cookie.
The finesse: Tracking the right cookie when the deal closes
At Step 4 in our list above we make sure to run the _link() method to get the tracking data somewhere where we can see it.
At Step 5 when we send the email through to reservations you'll remember that we provide them with a link to click that takes them to their back-office panel where they can confirm the reservation.
So all we do is ensure that this link also carries with it all the data the the _link() method added to the URL during the enquiry.
When we reach Step 7 - so when the reservations team member clicks the link in their email - all the data that _link() produced is still in the web address. All we do is ensure that we call _setAllowLinker() which tells GA to ignore the reservations team-member's cookie and instead use the data from the URL.
Finally the reservations team member submits the booking as "Booked" (hopefully!*) and on the subsequent "Thank You" page we feed all the data about the reservation - rooms, breaks, rates, nights etc - through to Google.
When Google runs its analysis of its logs later that day all of this e-commerce data will quietly join up with all the previous data for that cookie... where the visitor came from, how many days & visits to book and so on.
* we've actually added this first page to our Goal Path so that the booking getting to this stage show up in the funnel analysis even if the reservations team member clicks "Failed" as apposed to "Booked".
Results: Was it all worth it?
Definately. We've only had the system running a few weeks but already we're starting to gain an incredible insight into the distiction between traffic & business... which is ultimately the motivation for doing this analysis.
Through careful tracking of landing pages from offline (ie. magazine) referral, through tracking of email-traffic (something Spirit provides by default) and through Google's native tracking of search engine and website referral we're now able to truly understand which search-terms, which referrals and which offers and incentives drive people to book.
We're also getting some very interesting information about the correlation of breaks, room-types and length-of-stay as a product of GA's great ability to allow you to visualise your data.
Hector
_setAllowLinker before _trackPageview
Hi!
This great guide was the key for us to track offline sales at www.buscalibre.com.
However, we didn't get everything right until we realized that the _setAllowLinker instruction must go before _trackPageview (and probably before any other instruction) in order to google code actually read the url parameters instead of browser cookies.
Now we are getting the traffic sources of every transaction!
Greetings!,
Hector.
Emixion
per pageview stats
This works great, thanks! Except the per-pageview stats (like browser, country, os, resolution etc) for a goal conversion are taken from that actual pageview. So those stats come from the browser belonging to the member of the administration team. I don't think there's anything you can do about that, besides recording all those stats when they were sent on the last pageview from the actual visitor, and reuse them in a fake utm request. Or would you have another idea for this perhaps?
emixion
session expiration
I wonder what in your case is the time between the last pageview of the actual customer and the pageview of the reservations team member. Because in my experiments, it turns out that within a short time, say a couple of hours, this works perfectly. But when continueing the session a few days later, it seems that the previous session is not extended. The utm campaign info is preserved, because it is in the utmz cookie. But the path to the goal is unfortunately lost. The reverse goal path shows "(entrance)" as the step before the conversion.