Google Analytics Content Experiments API
Content Experiments API
We’ve been using Content Experiments for over a year now and we’ve seen some great tests. We’ve passed on a lot of learning to clients and through blogs based on our experience:
We’re really excited to see Content Experiments growing and expanding with the recent announcement of the new Google Analytics Content Experiments API:
The API can be split into 2.5 parts….
1. Management API
You can provision experiments using the API – no need to use the front end. If you have large numbers of experiments that are run frequently or you want to run the same experiment across multiple accounts/profiles with less risk of ‘finger trouble’ then this is a powerful solution. You also get to set up an experiment in Content Experiments (CE) but decide on the variation to serve based on your logic – not using the multi-armed bandit.
This is a fundamental and major change to how CE can be used. You may choose to set up a VWO or Optimizely (to name only two testing platforms) experiment and let the third party decide on the variation to show but you use the measurement protocol to put the test data into GA through CE. So, you can have your testing cake and eat the fully frosted GA data generated by the test if you so choose. Powerful stuff. Expect testing vendors to offer more than just custom variable based GA integration soon.
2. Server Side API
You can serve experiment variations using a server side API. For example, based on a DB lookup. This means you can use the multi-armed bandit and render a template based on the test variation decision made by CE or not. You decide. You don’t have any redirection either.
2.5. Client Side API
You can serve experiment variations using a client side API. This also means you don’t have to do any redirection. Neat.
Client Side Example
I think the new client side API is very tidy. I’ve crafted a simple working example based on the example provided in the Google documentation linked above. My demo is available here: http://tagify.co.uk/ce/ceapi.html
You’ll see it’s a trivial H1 text change. Nothing earth shattering. My script could be tidier but it’s just a test of a test….
Look how tidy the experiment scripting is:
Event the var headlines bit is extra. Compared to the old CE script it’s a lot easier to handle. It’s easier for clients to handle too. Compare and contrast with an equivalent CE code block:
Can you spot where we’ve fixed the bug in the standard CE code? Yup, the utmx and utmxx extraction is brittle in the standard CE code. You have been warned! Another good reason to go with the client side API.
What’s interesting is how the __utm.gif request changes when the client side API is used:
GET /__utm.gif?utmwv=5.4.2&utms=1&utmn=1501726454&utmhn=tagify.co.uk&utmcs=UTF-8&utmsr=1440×900&utmvp=1436×694&utmsc=24-bit&utmul=en-us&utmje=1&utmfl=11.7%20r700&utmhid=627148364&utmr=-&utmp=%2Fce%2Fceapi.html&utmht=1371032995315&utmac=UA-5824143-1&utmxkey=8gCuM2oDTDGBY12R25JARw&utmcc=__utma%3D88450846.292118432.1371032995.1371032995.1371032995.1%3B%2B__utmz%3D88450846.1371032995.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B%2B__utmx%3D88450846.8gCuM2oDTDGBY12R25JARw%240%3A1%3B&utmu=q~ HTTP/1.1
Of course, as there is no redirect the utmp is cleaner. No extra parameter cruft. The utmxkey contains all the treasure.
That’s all for now. We’re going to exercise the new server side and client side APIs for a bit and see how hard we can work them. We’ll report back soon.