Setting the Right Contexts With LaunchDarkly

Earlier this year in February, we expanded the targeting capabilities in LaunchDarkly by introducing the concept of “contexts”. Contexts replace our existing "user" targeting capabilities, giving teams more granular control over the application experience, by exposing additional targeting options in a first-class way. What exactly does that mean and why is it such a big deal for our customers? One of the core use cases that the LaunchDarkly platform enables is the ability to deliver targeted experiences to your audience—and contexts make this capability a first-class reality in the LaunchDarkly platform.

In the past, that audience was most commonly defined as the users who consume an application, but sometimes a user isn’t just a user. And even when the audience is a user, we sometimes want to serve multiple variations depending on that user’s circumstances. The reality is that targeting means not only controlling who experiences your application, but how, when, and what they experience. In this article, we’ll step outside the user box to explore other methods of targeting.

We were somewhere around Barstow, on the edge of the desert  

We’ve all gotten that pop-up in our browser asking us to allow a website to access our location data. This is necessary for a variety of reasons: serving information that is relevant to a specific region, inventory availability within a certain country, etc. Using location information is a way to make end users feel more connected to the website they’re visiting, but it can have other practical implications as well. 

Suppose you’re planning to migrate to a cloud-based database solution and rather than switching everything over all at once, you plan on taking a region-by-region approach to your migration. Do you really want your users in Europe retrieving data from a datacenter located in the western United States? Probably not. Latency issues aside, you also risk things like GDPR violations if those users are storing data within your application. 

One solution for this is to have users manually provide you with their location information as part of their user profile or their login. With that data, you could use user targeting to differentiate which database they have access to. The biggest problem here is that you are relying on your customers to provide accurate and up to date information. Why settle for that level of risk when you could capture that information and provide it to LaunchDarkly through the context instead? 

Contexts allow us to target based on whatever we want. Here are couple of options how we could solve for the situation listed above:

In this scenario, we use a context attribute to identify the location. This is a good approach if we are already grouping by users, say like in a profile, and we only need a general region. But what if we want to get more granular in this information? Rather than using just an attribute, we could create a whole new kind:

This whole JSON block is called a multi-context and now we have two independent sets of attributes to target off of, `user` and `location`. Within `location` we could target at the `region`, `state`, or `city` level! All this information can be gathered from our applications and sent to LaunchDarkly for targeting purposes. Now you may be wondering why we would choose to create these multi-contexts instead of grouping everything all together in a single kind. There’s a couple of situations we can explore there, let’s start with creating more complex targeting rules.

You’ll have to be more specific 

We know now that we can create multiple collections of attributes using a multi-context, but the question is, “why would we?” In our earlier example, we outlined a very simple targeting scenario, a database located in a specific cloud region and only letting users of that region access that database. But we can actually get further into that. First, let’s think about what happens prior to that regional release. 

Most likely, we have internal testers validating that not only is the new database reachable, but everything is rendering correctly and the data looks accurate. It may be the case that even with these internal testers, we only want them to be able to access the new database from the region that we plan to roll it out in. Or maybe, we only want them accessing it from their laptops because we haven’t optimized it for mobile usage yet. Without a multi-context, this could get tricky to manage. What happens if they’re traveling or have their mobile device configured with their work account? 

By using a multi-context, we can avoid these challenges. Here’s an example of a context instance where we are capture attributes for the `user`, `location`, and `device`:

When testing our new database, we could create a rule for our feature flag that says we only serve the new database when the user is on a certain `team`, in a specific `region`, and `isMobile` is currently false. With this logic, we’ve enabled John here to travel freely and use his mobile device without compromising our testing process.

An important note here, in these circumstances where we are collecting context information, the information listed above represents the attributes at a given time, say initial login. As our users continue to access the application and attributes change, that information is fed to LaunchDarkly and any targeting rules are re-assessed. So using the example above, say that John tried to access the new database from Europe on his mobile device, he wouldn’t be able to because it wouldn’t conform to the targeting rule we have in place. Way easier than manually updating the rules every time he takes a trip! Now the last question you might have about these contexts, involves the one field they all share: the `key`. Well this plays into a very important capability, experimentation!

Blinding me with science!

You’re probably aware that LaunchDarkly supports experimentation capabilities, but you might not know how you can leverage multi-contexts with regards to experiments. Organizations use LaunchDarkly experiments to test different flag variations to prove or disprove a certain hypothesis. In the past, we’d just use user data to build test and control groups. By using multi-contexts we can actually create more targeted segments for experiments. 

Building off our database example, let’s say that the testing has been done and we are ready to start rolling out access to the new database to our end users. Now let’s say that there are some folks with the organization that are actually skeptical that this change will benefit users and would like to see some additional data. We could use customer feedback and surveys as a validation mechanism, but a more scientific approach is using an experiment.

Similar to our testing group, maybe we don’t want to open up the new database to mobile users and we only want to target the specific region. This is where that `key` field in our contexts becomes so important! LaunchDarkly experiments utilize those `key` values to build the audience for the experiment. Since each context within the context kind has its own `key` field, each is eligible to be used in an experiment, we call these randomization units and it’s what you use to create a metric. For this database experiment, we may want to measure the latency or number of calls to the new database compared to the old system within the given region. We would use the `location` context kind for our metric and randomize which version a user sees each time they interact with the application. 

But what does that have to do with multi-contexts? Well remember earlier, we stated that we wanted to restrict access to the database to only non-mobile devices. We could still have that rule in place if we feel that the users will not have a good experience with the mobile version and are concerned that those interactions will bias our experiment. Using a multi-context we can run an experiment off one context kind while simultaneously targeting based on a separate kind! 

Getting what you’re entitled to

So far, we’ve centered around this premise of using contexts to manage a migration or roll out new capabilities to specific targets, but we’re still staying semi-user centric in that example. After all, our example focused on John traveling earlier and we were using targeting to ensure that John had the correct experience with our application. To unlock the true power of contexts, we have to think about other scenarios where we would want to enforce segmentation or create customized experiences.

One such area is familiar to all of us, the freemium model. I think it’s safe to assume that the majority of us have experienced applications that follow the basic freemium model, usually something like free with ads and limited features vs. premium with no ads and all the features. We can use contexts for this use case! Here is what a context kind could look like for this:

Using a context like this, we could set code that would serve ads or restrict features to Jane because she is on the `free` tier of the subscription service that we are offering. Going a step further, we could utilize these contexts to ensure that our promotional content is only served to `free` tier users and our banners aren’t displayed for those on the `premium` plans. 

This type of usage can extend to other similar programs: early access programs, loyalty programs, internal permission structures, etc. The benefit here is that it enables developers to code as they normally would and add gates within that code vs. having to serve different applications for different users.   

Conclusion 

We’ve only scratched the surface on what contexts and multi-contexts can do for your organization. User targeting has long been a major benefit of the LaunchDarkly platform and the introduction of contexts has brought that capability to a whole new level. If you’re interested in learning more or would like to know how to get started with contexts, make sure you read our documentation.