Implement wins on your production site
- Optimizely Web Experimentation
- Optimizely Personalization
- Optimizely Performance Edge
Note
This article is part of The Optimization Methodology series.
At the end of your testing cycle, decide which changes to implement permanently on your site. Work with a developer to integrate these changes permanently into your site's codebase.
If the optimization team has not prepared the developer for implementation, the project may be de-prioritized. For example, a new feature may test well but take a month of your developer's time to build. Inform your developers early to implement permanent changes from testing more smoothly and build a stronger optimization culture.
Materials to prepare
- Code from Optimizely variations
- Documented changes from your roadmap
- New functionality of the variation
- Regression test cases where changes may break functionality on your site
- Upcoming site changes
People and resources
- Developers
- QA team
- Stakeholders
Actions to perform
- Verify that new code functions correctly.
- Verify changes for regression testing.
- Update production environment.
- Update staging environment.
- Notify QA team, Marketing, Support, and Engineering.
Deliverables
- Updated versions of pages on the developer environment
- Updated version of pages on the production environment
Watch out for
- Not sharing about the new site changes that might affect other experiments with the entire team
What the developer should know
To implement your changes, your developer will translate Optimizely Web Experimentation's jQuery variation code into your site's framework. Adding Optimizely Web Experimentation's variation code directly to your site is not sustainable when you implement changes from multiple experiments over time.
This process requires familiarity with your site’s codebase and Optimizely Web Experimentation. It may also require the developer to translate some of Optimizely Web Experimentation's client-side script into a server-side script. Provide context around the experiment you ran.
A few things your developer should know about Optimizely Web Experimentation:
- The order of execution in Optimizely Web Experimentation's snippetOptimizely Web Experimentation's snippet
- How Optimizely Web Experimentation evaluates variation codevariation code
- Documentation for developers
Share your results document with the developer. A detailed plan provides context for the changes.
Your results document also creates a quick proof-of-concept before fully dedicating developer resources. The development team only receives tested and validated site changes.
Integrate your communications about the site build with your developer's communication systems, such as JIRA or Trello. Create a unified record so potential communication gaps—such as the overlapping deployment of live features and experiments—do not cause conflicts that break the site.
The workflow might look something like this:
- You create a test based on your experiment plan with your developer’s input.
- You analyze the results of a test and make decisions based on your results.
- You duplicate the successful experiment and set traffic allocation to 100% to show all visitors.
- You share results with stakeholders, including the developer.
- The developer enters the experiment and reviews the variation code with the project manager.
- The developer abstracts the code, builds a permanent feature in the production environment, and verifies that the feature works correctly.
- The developer notifies you when the feature goes live.
- You turn the experiment off and archive it.
Integrate your implementation process with your developer's systems to track projects and execute the handoff smoothly.
Get a developer involved early
As your optimization program matures, start incorporating your testing program with your developer’s sprint cadence. Involve the developer in the testing cycle.
This may decrease the time it takes to translate successful changes to your live site, but the effort to set up a test may increase. These shifts are good signs: your developer is more deeply involved in testing, and you can run more complex experiments.
Optimizing your live site is easier when you involve your developer early. A developer can help you design more dynamic experiments. Changes you make with the Visual Editor generate code executed in the browser after your site loads. Inefficient changes can become hundreds of lines of variation code.
For example, you use Move and Resize a few times to edit the color of a button to make it more prominent. Every change generates a new line of code. Too many code lines can cause performance issues such as flashing.
You can follow a few best practices, but a developer can optimize the variation code for the best performance. They can hand-code part or all of the variation and reference the codebase with JavaScript to create a dynamic experiment, such as replacing a module on the page or changing the experience as a visitor clicks around.
A developer can also think about abstracting variation code into the code base. When you deploy changes to the live site, they can build new or altered features more efficiently.