I’ve been excited to recently get the opportunity to work with the Optimizely Experimentation platform for the first time. My goal has been to analyse the platform technically and demonstrate to clients how experimentation is a game changer in proving what generates results.
Rollouts was the plan I started the journey on. At that stage we wanted to demonstrate the potential through running some simple experiments. The results would speak for themselves and open the door to move to a Full Stack plan.
Rollouts allows you to run an experiment on the free plan but you don’t get everything understandably. However what’s available for free is more than enough to start demonstrating results.
Be aware of the following free plan limitations:
The Rollouts limit is 1 active experiment at a time in each environment including Production. This is fair on a free plan!
Bot Filtering is not available in the free plan. This could skew the reporting metrics somewhat.
Experiments Rest API
The Experiments Rest API endpoint does not work in Rollouts which may limit some clever integrations. However if your going to start pushing the boundaries of a platform integration, you’re probably going to be investing in a paid plan!
Let’s Get Started
Sign Up for a free Rollouts account here.
After that you need to extend your Commerce code base to integrate with Optimizely Experiments through the C# SDK.
This series of posts by David Knipe is a great place to start if you are integrating with the Optimizely CMS or Commerce platforms.
Integrating Optimizely Full Stack with Episerver | david-tec.com
His Foundation Experiments branch on GitHub can easily be added to your solution. It provides some really neat integrations out of the box such as with Optimizely Projects and Visitor Groups. His blog series will bring you through all this.
episerver/foundation-experiments: Foundation Experiments offers a starting point for integrating Optimizely Full Stack into an Episerver project (github.com)
Some Minor Code Base Updates
My project was an Optimizely Commerce application without Visitor Intelligence so I made the following updates to make the Optimizely Tracking and Decision integration seamless.
Added Commerce Core Library
I extended the code to integrate directly with EPiServer Commerce core library. This simplified the integration with my Commerce code base so I could pass classes like IOrderGroup for tracking.
Extended IUserRetriver to include a method that will return an object with the User Id and Attributes stored in one object.
I also added an extra reserved attribute to the user context which would enable bot filtering in reporting tools on a paid version.
Added a Tracking Service class that can be called directly from the main Web Application to track various events.
Added an Experimentation Service class that can be called directly from the main Web Application to get experiment decisions and variables.
In the next post I will link to my GitHub repository where I have pushed these changes and will talk through specifics of integrating into your Optimizely Commerce application.
6 thoughts on “My Experience with Optimizely Fullstack (via Rollouts) – 1 of 4”
Hey thanks for sharing your experience, I look forward to reading more 🙂
Thank David. Your Experiments Project is great! Picked up on some really nice techniques going through the code. The Projects integration is going to be very useful 🙂