Here is how kuteo do it themselves
LaunchDarkly is a feature management and experimentation for banking, payments, insurance, and wealth management firms.
Application -------- request w/ --------> LaunchDarkly
user data & environment |
|
pre-configured logic
|
|
Feature A or B <--------- respond w/ <---------- pick value A or B
in App the feature value
We’d like to understand user behaviors when the feature A is replaced by a new one, B.
A feature flag is to control whether we should show feature A (usually the current behavior) or feature B (the new behavior) during the testing period. Using a feature flag, we could isolate the logic controlling the switch that may depend on different criteria like user type, characteristics, and environment.
User Context ----> Feature Flag 1 ----> Rule 1 ----> A
| |
| |--------> B
|
|--------------> Rule 2 ----> A
| |
| |--------> B
|
|--------> Default Rule ----> A
A segment is to build groups for the A/B testing. The groups could be determined by rules or by listing out member contexts. Segments will be referenced by the feature flag as the A/B testing targets.
User Context ----> Segment 1 ----> Rule 1 ----> Included
| |
| |--------> Excluded
|
|---------> Rule 2 ----> Included
|
|--------> Excluded
Metrics refer to the data and insights collected regarding the performance and usage of feature flags within an application. LaunchDarkly provides a set of metrics and analytics tools to monitor the impact of feature changes align with the business goals.
App Event ----> Metric 1 ----> event key ----> recorded (count)
| |
| |----------> ignored (no count)
|
|----------> refresh data and insights
count per userId where higher is better