You can't reliably use Array#concat on the _gaq object. Once Google Analytics loads, it replaces the _gaq array with a custom object that has it's own push() method. That object doesn't have concat() on it.
So, your core coding style will only work with very particular GA implementations; anything that deviates from that could very easily break or be subject to race conditions.
You'll also get better results if you use events rather than custom variables; custom variable reporting isn't as flexible and can be very confusing (ie, visit start). It'll also mitigate the need to use concat() to cut the line, since Events can be fired at any time (whereas custom variables need to happen before the first hit of the session to be well-reported).
I also really like the idea, though. I actually pass all my Optimizely test results as Google Analytics events with this snippet:
if (window.optimmizely && optimizely.variationNamesMap) {
var optmap = optimizely.variationNamesMap;
for (var expt in optmap) {
if (optmap.hasOwnProperty(expt)) {
_gaq.push(["_trackEvent", "Optimizely", optimizely.allExperiments[expt].name, optmap[expt], 0, true]);
}
}
}
Only if everyone loads it the same way. But there are lots of different ways to load GA; the only reason _gaq.push() isn't scary and doesn't raise the specter of race conditions is because of the 'spoofing' GA does.
There are LOTS of different versions of the GA snippet floating around the internet; the assumptions this configuration makes would only work for some of them.
Ok, now I understand what the issue is. I guess a good solution would be to pass _gaq to my library initializer and push every value with a for cycle, instead of using concat. Thanks for the tip.
Checking out the source code, this isn't going to work in IE8 and earlier without some small tweaks. IE didn't support `document.getElementsByClassName(string)` until IE9. It would be a small rewrite to make it work with IDs instead of classes (or you could use a shim).
[EDIT]: . . . But I like the idea. Might even use it next time I'm working with GA.
Thanks for the warning! I initially developed this with jQuery, and only after seeing how little of it was needed decided to get rid of it - but I forgot to make all the due diligence. Later or this weekend I'll fix this - but if in the meantime anybody wants to send a fix or a pull request, I'll be glad to use it.
LOL, I had forgotten: I already use a custom getElementsByClassName if there isn't one! So the it already works in IE < 9... check out the source code :)
OP here: That was the spirit of the thing. It isn't a fully fledged solution, but it's a very easy way to start testing, and in GA you can combine this data with all the other data you have there, if you want.
Just me, or does anyone else miss Multivariate testing? It's impossible for me to use A/B testing with shopping cart software when it loads dynamic content (like the cart or checkout processes). Unless I'm doing it wrong?
Content that loads dynamically won't force you to use Multivariate Testing. In fact, most commercial services implement both A/B and Multivariate tests using client side JS.
Also, you can A/B test dynamically loading content so I think you just need to find out how to do it using your chosen software.
looks nice and this is just an initial thought, it looks like the holding content in the HTML is replaced by either case A or B from the script, will it run with the holding text being case A and swapping out only when B is picked by the script therefore avoiding a possible content flicker some of the time? of course this may not be desirable on larger content.
Yes, it would work - but I wouldn't advice doing so:
* If the flicker isn't noticeable, it doesn't matter either way
* If the flicker is noticeable and disturbing, having it only for one version could skew the results in favor of the non-flickering version
So, your core coding style will only work with very particular GA implementations; anything that deviates from that could very easily break or be subject to race conditions.
You'll also get better results if you use events rather than custom variables; custom variable reporting isn't as flexible and can be very confusing (ie, visit start). It'll also mitigate the need to use concat() to cut the line, since Events can be fired at any time (whereas custom variables need to happen before the first hit of the session to be well-reported).
I also really like the idea, though. I actually pass all my Optimizely test results as Google Analytics events with this snippet: