Feature flagging, or feature toggling, is a strategy to reduce risk during major production updates. It enables you to partially deploy new code and then test it with a subset of traffic before full rollout. This is especially useful for integrating changes after successful A/B testing. For example, after validating a hypothesis and adjusting the code, you can run a trial of a new checkout flow with 5% of users before deploying the new flow to all your users. This isn't about testing a hypothesis, it's a way to manage a controlled release of verified changes. You can use the Dynamic Yield server-side API to control feature flags and to attach additional values to the "on" state of a feature flag.
Manage feature flags using Experience APIs
Step 1: Set up the feature flag in the campaign
- Go to Web Personalization or App Personalization, depending on where you want the feature flag to run: On your site or your mobile app, respectively.
- Create an API custom code campaign.
- Name the campaign and the selector based on your feature flag.
- Add a label called “Feature Flags” to the campaign. This enables you to filter campaigns using feature flags in the campaigns list.
- Add a selector group called “feature_flags”. This will enable you to have a single API call for all feature flags campaigns later.
- Click Next.
Step 2: Create a variation with the feature flag template
- Click New Variation, and select the Feature Flag template.
- Edit the variables:
- flagid: Enter the feature flag selector name. You must use the same name in your site or app code to reference the change in the logic and functionality of the code.
- Status: In most cases, the default "true” should remain.
-
Use custom properties as needed.
For example, let's say you developed the new checkout flow with a wizard, but it has multiple options you want to roll out gradually. You can manage the number of wizard steps to roll out in this variation. In this case, set the property name and value you want to manage. - Click Save Variation.
Step 3: Set targeting and activate
- In the Variations tab, set the percentage of users to roll out the feature to. For example, in this case, because it's a sensitive change, you might limit it to 5% of the traffic, keeping 95% as the control group.
- Click Next to configure the targeting. You can limit the enablement of this feature flag to a specific audience, specific days, users who visited a specific page earlier in their session, and more.
- Click Next to go to the Status tab. Set the status to Active and then click Save Experience.
- Optional: You can now set additional experiences with different traffic or property values per targeting group.
- Save and then publish the campaign.
Calling the API
In your app code, use the standard server-side API implementation, with the following differences:
- Upon the first pageview of the session, call the “feature_flags” campaign selector to fetch the status of all of the relevant campaigns at once.
- Because the feature flag status should remain static throughout the session, you can cache the response for the remainder of the session. This enables you to not fire an API call for every pageview.
- Make sure that your app assigns the right behavior for users who receive the control variation (usually, this means that the feature flag is off).
- Optional: By nature, feature flagging is a limited-time process. As it's mostly for functionality testing, you can set the timeout lower for this response, for example, 30ms. This ensures that for this specific case you can serve a small fraction of traffic to the control, if for some reason the response is delayed.
Tips
- To view all feature flags and their status, go to Web Personalization and filter campaigns by the label "Feature Flags".
- If you want to bundle feature flags, you can create multiple variations using the Feature Flag template, each for a different feature flag. In the campaign's advanced settings, set multiple variations per decision, as illustrated in the following image: