Watch the webinar all about the wrinkles in measuring what happens when Paypal is used
Hello and welcome along to our analytics half-hour.
This afternoon we’re going to tackle measuring Paypal purchases in Google Analytics. Why there are problems and what to do about it.
So you have a website on which the visitor “starts” the purchase process…
These technical problems come from 2 main sources :
Google Analytics is based on cookies – which are tied to your “domain”
You may not be able to control or even influence the code on the other site
Sometimes you do (at least enough to sort this out) – and it’s a hosted system from a CRM or other provider. In which case you can get your analytics code onto the other site. And accept that accept that this pain is worth solving to make sure the overall measurement process doesn’t get destroyed by the movement from one site to the other.
Now 3rd party providers vary:
Clickbank is quite good – it allows you to put your analytics code onto it’s site.
Leadpages does the same.
In these cases you want someone skilled in analytics to follow the instructions of the 3rd party and then to be able to run tests. Note that in many cases the documentation is still primarily aimed at the older (ga.js) version of Google Analytics (so not universal analytics). They’ll need to deal with the cookie issues and test the whole system.
Paypal and other merchant gateways DON’T allow code onto their sites.
So the best you can do here may be to watch for the returning visitor. And exclude the gateway as a referral source.
With the advent of universal analytics you may be able to capture “signals” from the payment gateway and use these to “artificially push” the data into Google Analytics. For instance Sagepay – a payment provider I know well – that integrates well into websites sends a good number of “hidden messages” back to you whilst the payment process is underway that could be used.