One reason to consider keeping your experimentation on the server side is that the browser is an untrusted computing environment and can be easily manipulated by hostile agents.
This is a general problem with client-side code, I'm surprised it doesn't come up more often.
For example, I once knew a site was using A/B/C/D testing to derive a demand curve for their product and just kept wiping my cookies until I got the product for 1/3 the cost.
AdBlockers are blocking more trackers and third party js than ever before. I've seen multiple pricing tables, call to actions and forms be entirely screwed up by an ad blocker trashing VWO, Optimizely or similar.
Server side tests obviously sidestep this and are likely both more performant and more accurate.
Why not just write it yourself? The api has been stable for a while, so it should only take you a couple hours to get something basic for your internal needs.
Question, why use Optimizely for server side testing, you're going to pay a lot of money for something that has a ton of open source alternatives, and really isn't rocket science.
Their client side stuff was revolutionary, marketing can run tests by themselves FTW. The grid in this article goes into that.
On the server side, you're going to need to add triggers for goals etc in your development environment, just feels like shoehorning Optimizely in their non core competency is a mistake.
6 comments
[ 2.4 ms ] story [ 20.8 ms ] threadThis is a general problem with client-side code, I'm surprised it doesn't come up more often.
Server side tests obviously sidestep this and are likely both more performant and more accurate.
Their client side stuff was revolutionary, marketing can run tests by themselves FTW. The grid in this article goes into that.
On the server side, you're going to need to add triggers for goals etc in your development environment, just feels like shoehorning Optimizely in their non core competency is a mistake.