Using client side experimentation, engineers can quickly create and publish tests without waiting for an application release cycle. This is convenient in some situations, but can also have an impact on or even inconvenience your users. Instead, your development team can deploy tests by using server side experimentation.
Server side experimentation refers to any type of testing that’s conducted on the web server and not in a user’s browser. This type of testing can include A/B testing, multivariate testing, or multi-armed bandit testing. It expands your capability for deep experimentation and multi-channel experimentation with minimal impact on your software’s performance.
In this article, you will learn about server side experimentation in agile environments and how it benefits developer teams.
Why Server Side Experimentation Is Important
For years, organizations have leaned into client side experimentation as a way to run feature experiments on the frontend. This method allows teams to test their application’s user experience and frontend features, then use the results to better optimize their offerings.
As technology has advanced and software applications have become more complex, the need has also grown for more complex experimentation. On its own, client side experimentation can be limited. Organizations need to run more sophisticated experiments, including those focused on backend infrastructure. Server side experimentation solves this problem by rendering all tests on the server, which broadens the testing options.
Along with the ability to test substantial changes, server side experimentation also allows you to go deeper with your experiments. Because it’s conducted on the web server, you can access and test your backend algorithms, infrastructure, third-party integrations, and databases. This gives your team more data and capabilities to constantly measure and improve your products.
Server side experimentation also enables feature test selection, so your team can test not only product features but different versions of the same feature to choose the one that provides the most value for users. A feature experiment can be set up on the server side, for instance, displaying different versions of the same feature to different users. Data on each version is tracked over time to measure user value and impact. When your team determines which option is the best, it’s presented as the only version.
As an example, an e-commerce site can experiment with different delivery charges (calculated via experiments on the server side) based on the total order amount in the buyer’s cart. Once that team identifies the optimum delivery charge, they can roll it out as the only option.
Server side experimentation allows your team to run staged feature rollouts for new features as well. With staged rollouts (or canary releases), your team tests a new feature with a smaller group of users before releasing it to everyone. This lowers the risks of new feature releases, because you can measure the impact of the feature and check for issues or bugs while it is only accessible to a subset of users. If any issues are identified with a feature it can be rolled back and fixed, but the impact of those issues will be smaller since not all users can access it yet.
How to Set Up Server Side Experimentation
Now that you know more about server side experimentation, here are some best practices for using it effectively in your software.
Use feature flags
Feature flags allow you to selectively turn a feature on or off during runtime. With feature flags implemented, you can make changes to your product features without needing to push new code or create a new deployment. This way, you can rapidly experiment with features in a controlled manner.
With feature flags, you choose which features should be on or off. You can switch on new features, test them out, measure their impact, and switch them off again to try the next options before deciding which works best. All feature variations can be fully implemented and hidden behind feature flags until they are tested. Switching experimentation options on and off is as simple as a single click.
When you enable features for a subset of users, you can learn what works before releasing the features more broadly; you can also combine feature flags and user segments. If a bug is identified, feature flags make it easy to temporarily switch off the feature, fix it, then switch the feature back on so its impact can continue to be measured.
Use agile testing practices
Feature flags make it possible for your teams to apply agile release planning, in which you work on and release a product in short planned sprints. You can build those increments in small batches hidden behind feature flags and test them out.
Once the new products or features are working as expected, you can roll out a full product release. Agile release planning helps you plan which product increments get released to the market and when, because you’ve tested and adapted those new versions first.
How to shorten the testing cycle
The server side experimentation cycle is most effective when experiments are short but yield significant results that can be used to improve the product. You have a few options for reducing the time and workload of this cycle:
- Map feature releases with user segments
If your team experiments with a small subset of users, they can more quickly complete testing, make needed changes, and apply those changes to all users. If there are bugs in your application or in the testing, fewer users will be affected. - Control the scope of releases
Break down your releases into smaller pieces that can be more manageably tested. This enables smaller, cheaper experiments that your team can finish more quickly. If you need to change direction or ideas, you won’t feel like you’ve made a massive shift. - Measure feedback from controlled releases
The goal of server side experimentation is to test out feature hypotheses and build confidence in those features before releasing them to all users. You should track and measure all experiments in order to assess their results. With each test, determine what’s being measured, what the expectations are, and what desired outcome will enable you to release the feature. Keeping these criteria in mind will also help you keep the testing cycle short, since you can immediately stop an experiment once you have the results you need.
Conclusion
Switching from client side experimentation to server side experimentation increases the testing possibilities for your application, helping you ensure that new releases or updates are deployed to users as successfully as possible. You should now have a better sense of what server side experimentation can bring to agile environments.
If you're looking for a tool to help with experimentation, LaunchDarkly can help. Dive into our docs to get a better feel for our experimentation capabilities, and check out our latest announcement around the topic.
.webp)
