The User Experience (UX) of Feature Flag Targeting

There are two groups of people affected by feature flag targeting: the people who use your product; and, the people who manage your feature flag system. Most of this book is about the former—I'd like to take a moment and talk about the latter.

When you first experiment with feature flags, you'll almost certainly use your database's primary keys as the value to target. After all, these database keys are the inputs we use most often in our application request processing. So, it's only natural to extend that mindset into the realm of feature flag targeting.

Which means, if you wanted to target an organization (ie, a semantic container for a cohort of users), you might use the organization's database ID:

{
	variants: [ false, true ],
	distribution: [ 100, 0 ],
	rule: {
		operator: "IsOneOf",
		input: "companyID",
		values: [ 1728 ],
		distribution: [ 0, 100 ]
	}
}

In this case, we're targeting the companyID with value 1728. This will absolutely work. However, numbers have very little inherent meaning within your application. So, when a feature flag administrator goes to configure a feature flag and sees something to the effect of:

values: [ 1728, 9034, 10348 ]

... it's not immediately obvious as to which companies are being targeted within your application. Or, if the targeted companies are even still relevant. Since your feature flags administration system is likely to be a SaaS offering, drift will occur. Meaning, your feature flags system will eventually reference data that no longer exists within your production application.

If, on the other hand, an administrator went to configure a feature flag and saw subdomains instead of IDs:

values: [ "example-inc", "ben-inc", "testing" ]

... it would be obvious which users are in the intended target audience. And, it would be easier to determine, at a glance, whether or not those targeted cohorts are still relevant.

Whenever possible, I suggest that you employ a human-friendly string as your means of targeting. For users, this might be their email address. And, for organizations, this might be their subdomain.

Of course, it's all a balancing act. While a database ID is unlikely to ever change, email addresses and subdomains do change occasionally. And, when they do change, the feature flag targeting rules will have to be updated to reflect this change. That said, I would choose an intelligible value over a static value when possible.

Have questions? Let's discuss this chapter: https://bennadel.com/go/4545