There’s much to consider when choosing an experimentation platform. While there are many small players in the space with different focuses, strengths, and teams behind them, Optimizely and Adobe Target have the largest experimentation customer bases.
In the last few years, we’ve seen a big increase in customers switching from Adobe Target to Optimizely. We’ve learned that there are 7 major reasons why:
- Deeper testing capabilities
- Testing beyond web—SPAs, mobile
- Faster results
- Guidance and best practices
- Developer productivity
- Efficient experiment program management
In the next seven blogs, I’ll cover each in detail and how Optimizely differs from Adobe Target. Regardless of the solutions you are currently using or evaluating, these seven areas are important for you to consider for the overall health of your program.
Let’s take a look at the first topic—Performance.
Why Performance Matters
Adobe Target’s snippet performance is more of a one-size-fits-all. Optimizely, on the other hand, has a performance engineering team dedicated to making sure you get the solution that works best for your architecture.
The out-of-the-box Optimizely Web configuration
Optimizely partners with leading CDN provider, Akamai, to deliver our snippet across the globe. Optimizely makes sure that out of the box, your snippet is built for speed. It’s compressed and heavily cached to make sure you don’t overpay the cost of downloading it over the wire. All of these out-of-the-box optimizations are critical for having the best snippet performance.
Some Optimizely customers like Casper, have seen incredible results from self-hosting the snippet. They have seen 36% increase in site performance, simply by hosting the Optimizely snippet on casper.com. While self-hosting the snippet will require some engineering resources to set-up, we have documentation for doing this with popular CDNs like Akamai, Fastly, Cloudflare, and Cloudfront. We also offer professional services that help expedite this process and help you get back to scaling your experimentation practice.
Zero latency UI & server-side testing
If you have the technical resources you can implement experimentation programmatically from the UI down to the server. We went with an SDK-driven approach for our Full Stack product.
Full Stack uses in-memory bucketing so it already has all of the information it needs locally. This means users won’t perceive any noticeable latency. With Adobe’s API driven, server-side testing approach, a blocking API request is used to get decisions about which experiment variant to use. This adds even more load time to your current page. With Full Stack, load time is under a millisecond.
To dive deeper into Optimizely’s perspective on performance, download this whitepaper.
Stay tuned for our next blog post in this series where we will explore how Optimizely enables deeper testing capabilities allowing you to test the entire user experience from the UI down to the server-side business logic and data.