Targeting is becoming increasingly complex. It used to be the case that all end users were people, but now companies need to reliably deploy updates to groups and “things” beyond these traditional users. This could mean connected devices or unique user groups like buildings, vehicles, or stores – the options are somewhat endless.

Simultaneously, as audiences grow and expect tailored experiences, there’s a greater need to diversify and specify end users. Businesses today must deliver targeted experiences to compete and unfortunately, building adequate targeting capabilities requires heavy development work. Now more than ever, developers need the ability to target any customer segment with ease.

To improve targeting capabilities and gain better control of unique user bases, custom contexts are a game-changer. They provide product managers with the ability to pilot and release new features safely and serve features to any audience without burdening engineers. 

Custom contexts explained

Custom contexts are part of feature management delivery systems that help you deliver targeted product experiences to as many “things” as you want at once, increasing the power and control you have over feature releases while reducing risk and technical debt. 

With custom contexts, developers can move beyond user targeting and instead define their own kinds of contexts that can be personalized to their business language, release process, and data models. No matter who or what you’re delivering to, whether it’s a device, specific account, or individual user, custom contexts drop second-class workarounds and define, experiment, and target on your terms.

Most enterprises operate not on one feature delivery a day, but hundreds of complex deliveries with painful targeting limits. To keep up, organizations can use custom contexts to progressively deliver many different kinds of things and personalize experiences to users without draining valuable engineering time. Custom contexts have the capacity to define targeting rules and evaluate flag variations, which turns a formerly one-dimensional targeting process into a multidimensional targeting powerhouse. Instead of targeting and evaluating flags based on one attribute, such as individual users, you can test the user, device, and organization altogether to ensure the correct variation is served and that you target based on everything you know about your audience.

For the past year, we’ve worked with feature management platform LaunchDarkly to employ custom contexts to clearly target different entities, control customer experiences, and allow more freedom for our product, developers, and engineers to use any attribute they need for any entity or context targeting. Custom contexts deliver targeted experiences to any audience without the psychological burden of a risky release. 

Saving time and money on delivery and deployment

Before adopting custom contexts, my team was taking up developer time on more tedious processes. And in a field like development, teeming with burnout and stress, this time is incredibly valuable for any organization. We used to lean heavily on automatic generating segments, attempting to keep them in sync via Kafka topic consumers. This process meant locking down what attributes could be used for targeting since they all went into the “user” context. Since adopting custom contexts, we’ve been able to loosen restrictions while still providing guidelines around PPI and replacing those automated segments with new contexts and simple targeting rules.

To save time and money, our team is able to test features with subsets of users, securely leverage predefined user groups, and easily run beta tests. Before a larger deployment, we vet features with small audiences in production before releasing to an entire user base, making it easier to control who gets which features when for faster feedback and shorter time-to-value. 

Our process of adopting custom contexts is all about devising efficient flag-targeting strategies. Since we began this process, we’ve removed a few hundred lines of code that we used to write in our internal wrappers to produce namespacing attributes; reduced the time to support a new context from four hours to mere minutes; and reduced the time to allow new attributes in targeting rules from one hour to zero. For my team, this has saved countless developer hours so we can focus more energy on advancing our software in other areas. 

Building software for a diverse end user

Custom contexts have become a huge asset for my team and can benefit any company regardless of the diversity and specific needs of their end users, even if those end users aren’t people at all. Now, if developers want to target attributes beyond IDs, they can. Custom contexts can help teams map features to unique business needs and help teams govern critical parts of the user experience, tailoring them to each audience segment and adapting them to changing conditions, without requiring custom code.

With flexible contexts and feature flags, product managers, developers, engineers, and their teams have the time and space to produce timesaving targeting strategies and product delivery, while allowing for innovative experimentation.