When people think about feature flags, they think software switches to hide or activate features, or in other words, on or off, true or false. These are called boolean flags, and they have only two states. However, there are other types of flags, known as multivariate flags, with a potentially unlimited number of states.
In this post, we’ll take a look at what multivariate flags are and how to use them.
A boolean flag is relatively easy to understand, although there are tons of potential use cases beyond the obvious ones. There is a true state and a false state, essentially a default and a change. In simpler terms, an on and off.
Multivariate flags, by contrast, have an unlimited number of states.
The benefit is that you can expand the way you use flags to cover a wide range of scenarios. The most obvious is referred to as A/B testing (even though it says A/B, it’s usually more than 2 options). But beyond that, there are lots of other ways to think about multivariate flags.
Before digging into specific sample use cases, it’s worth noting that in Harness, multivariate flags contain different data types. This is because no matter what the value of a boolean flag is, the actual evaluation is the single data type of boolean. Multivariate flags, on the other hand, need a data type and a value since they are more open-ended.
We allow for strings, JSON, and integers, and likely will allow for more in the future based on your feedback. By allowing for additional data types, there are more powerful use cases that can be engineered into your product.
A/B testing is usually focused on user behavior. It most often is about determining statistical significance of a behavior-modifying change. For example: Does a red, green, or blue ‘cancel’ button reduce churn the most?
A/B testing leverages multivariate flags by allowing you to test many options at once. Test your trial lengths (3 days vs 7 days vs 30 days), or test your wording (“exciting” vs “advanced” vs “innovative”).
A/B testing combines feature flags with behavior analytics tools such as Amplitude to let you see what users are doing and learn as you adjust.
One of the benefits of the string and JSON data types can be using multivariates as permanent configurations, or for testing, in the backend of your application.
Here’s a real-world example. Let’s say you have an archiving system that needs to fetch user data from cache and put it in cold storage. 98% of the time, this service needs to run every 5 minutes. But occasionally, with load issues or due to other engineering changes, you may want to change that.
By using a multivariate flag, you could easily key in longer and shorter term intervals - or even a full pause - available at the click of a button. All this without the need for core application changes when you need to delay or pause your archiver.
These potential use cases live in the heads and runbooks of your Ops, SREs, and Architecture teams. Go have a conversation with all of them. See where wiring up these types of behaviors to multivariate flags may save time and increase resiliency.
For folks working in regulated industries, or in countries with differing consumer regulation, you may have common prompts where text needs to change.
A multivariate flag is a great way to adapt user experience and requirements based on geography. If you’re in a logistics business, show different tax rates to different states with a single flag. Or, if you handle data, show California, the rest of the US, the EU, and the UK different privacy messages as required by law. All centrally controlled under a single multivariate flag.
Frequently, teams wire this logic up in an application similar to a flag, but with the application deciding automatically. This seems great on the surface, but the reality is that you lose the visibility, easy auditing, and controls that you get by using a feature flag management solution instead.
Are you using multivariate flags in novel ways? If so, we want to hear from you!
Multivariate flags are more powerful than “just” A/B testing, although A/B testing is a critical capability they provide for. The scenarios above are a few common examples, but there are a lot more out there. As you mature with flags, you will uncover new ways to use them to bring control and visibility to your app.
As you go into your feature flagging journey, discuss with your team how to go beyond the simple yes or no flag. Additionally, discuss where you may want to learn from multiple options (and sidestep a debate in the process. Why argue over which choice is best when you can ship them all with a flag and settle it with real data?), or connect your application ops task to flags for more control.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.