Experimentation support: standardized context fields and experiment grouping

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

• Feature Flag Semantic Conventions SIG in OTel
• #276: Implement Tracking in SDKs

Start by reading the OpenFeature specification sections covering evaluation context and flag metadata, then review related issue #276 and the linked OpenTelemetry semantic conventions work. The issue currently poses design questions rather than naming files, tests, or an implementation boundary; a decision on scope and placement is needed before completion can be defined.