Context
At KubeCon EU 2026, we held an in-person discussion on experimentation support in OpenFeature (recap). Two related gaps were identified around how the SDK and spec support experimentation use cases.
Problem
1. Standardized context fields
Today, the evaluation context only defines targetingKey as a well-known field. For experimentation, analytics systems need consistent metadata to segment users, things like browser, geo, device type, session ID, etc. Without standard field names, every provider and analytics integration ends up defining their own conventions, making interoperability harder.
This is similar to how OpenTelemetry defines semantic conventions for well-known attributes. We should consider defining a set of well-known evaluation context keys for common experimentation use cases.
2. Experiment grouping
Several participants described production models where experimentation is a separate concept from feature flags, with a 1-to-N mapping between experiments and flags. A single experiment can control multiple flags that share targeting (e.g. a treatment group gets a specific combination of foreground color + background color).
There's currently no standard way in OpenFeature to:
- Associate a flag with an experiment ID
- Group multiple flags under shared targeting
- Indicate that a flag's experiment assignment may change over time
Flag metadata could carry experiment associations, but this isn't standardized.
Questions
- Should we define well-known context keys in the spec, or as a separate "conventions" document?
- Is experiment grouping something the SDK API needs to be aware of, or is flag metadata sufficient?
- How do we avoid over-specifying while still enabling interoperability across providers?
Related
Context
At KubeCon EU 2026, we held an in-person discussion on experimentation support in OpenFeature (recap). Two related gaps were identified around how the SDK and spec support experimentation use cases.
Problem
1. Standardized context fields
Today, the evaluation context only defines
targetingKeyas a well-known field. For experimentation, analytics systems need consistent metadata to segment users, things like browser, geo, device type, session ID, etc. Without standard field names, every provider and analytics integration ends up defining their own conventions, making interoperability harder.This is similar to how OpenTelemetry defines semantic conventions for well-known attributes. We should consider defining a set of well-known evaluation context keys for common experimentation use cases.
2. Experiment grouping
Several participants described production models where experimentation is a separate concept from feature flags, with a 1-to-N mapping between experiments and flags. A single experiment can control multiple flags that share targeting (e.g. a treatment group gets a specific combination of foreground color + background color).
There's currently no standard way in OpenFeature to:
Flag metadata could carry experiment associations, but this isn't standardized.
Questions
Related