Lesson 4: Evaluation Context and Targeting
You can give users flag values conditioned on their context. By sending in context with the flag resolve call, the feature flag resolver can use this context and have conditional rules. For example, only users in the US gets a certain experience.
What is the evaluation context?
Context is data relevant to your users that you are interested in targeting your experiments on. It can be as generic as their country or as granular as the amount of times they refresh the landing page. You have the power to collect as much or as little data you want - but what is the suggested approach?
The following video provides a quick overview of how the evaluation context is related to targeting.
The current evaluation context is an integral component in the system and is part of many SDK calls - so be aware that including too much data in a context could potentially lead to increased latency. Work with generic structures that can be reused for targeting across different experiments to minimize the size of your context.
Automatic data collection
Some SDKs allow you to automatically collect certain device data:
- Device manufacturer and model
- Application version
- Custom data that you configure to be automatically collected in your application
Confidence SDKs support automatic collection of device data (manufacturer, model, application version, and custom data you configure) out of the box.
Targeting with context
When you're done setting up your context, you're ready to use it for targeting. In your A/B test or rollout, you can find the relevant data for targeting, such as country, visitor_id, etc. Keep in mind that to mix and match contexts from different systems (mobile, web, backend), you need to ensure that the context is available for all parts of your application where the flag in your experiment is resolved.
Frontend vs. backend context
Frontend apps often have a single user that uses the application. For this reason, a 'static context' paradigm is often applied to frontend SDKs. This means that the contextual data collected in the SDK is static and will stay in memory throughout the application lifecycle until actively being changed or removed through the SDK API.
Backend apps/services on the other hand can serve thousands of different end users during the same second, so in this case, a 'dynamic context' paradigm fits better. The dynamic context paradigm favors volatile context values that will only be used for that split second in which your backend service caters to the end user's request.
In the Confidence SDKs, frontend clients use a static context paradigm and backend SDKs use a dynamic context paradigm. Backend SDKs also have support for longer-living context data that is contextual to the actual backend application (for example, in which geographic region it exists).
Context updates and flag re-evaluation
Frontend clients automatically fetch new flag values when a context value is added, removed or changed. This is because flag values may depend on that specific context value in its rules setup. For example, targeting criteria for an experiment may include user information which is only available after the user has been logged in. The act of logging in would then enable the application to add user information to the context and the SDK will then fetch new flag values.
Certain care should be taken when working in frontend environments and adding values that are volatile (likely to change very often). Since every context change triggers a fetch, we recommend against having volatile values in the context for performance reasons. An extreme example of this would be to continuously add the mouse location to the context.
Context and data integrity
The context is data maintained by the client, and it should at all times reflect truths about the user and/or its device. Which country is the user registered in, but also which country is the user's device currently accessing your app from. Which locale has the user selected.