A flag's evaluation context is the data you pass in so the system can decide who gets a feature. Send a stable pseudonymous ID and a few coarse attributes such as plan or region. Keep emails, names, tokens and anything sensitive out, because the context often travels to a third party and into logs.
What the context is
The OpenFeature documentation defines the evaluation context as a container for arbitrary contextual data used as the basis for dynamic evaluation. Static data, such as the host or an application identifier, can be set globally. Dynamic data, such as a client IP address in a web app, can be passed during evaluation and merged with the static values.
Flags are context-aware because a decision usually depends on which user is making the request. Canary releases and experiments need it.
Where the context goes
That depends on your provider. OpenFeature describes providers as the translation layer between the evaluation API and the flag management system, and says a provider might wrap a vendor SDK, call a REST API or read a local file.
So your context may be sent over the network to a flag service, held in its logs, or shown in its dashboard. Read your provider's documentation to learn which. Until you know, assume it leaves your boundary.
A safe default set
Send the minimum that targeting needs:
- A stable user or account ID that is not an email address or phone number.
- A coarse segment such as plan tier, or a customer cohort name.
- Region or country at a level you truly use for rollout.
- Application version and environment.
Leave out names, email addresses, session tokens, raw IP addresses unless you need them, and any health, financial or other sensitive attribute.
Hooks can leak too
OpenFeature hooks let you add behavior around flag evaluation, such as logging and telemetry. A hook that logs the full context on every evaluation can quietly write personal data to your log store at high volume.
If you log evaluations, log the flag key, the result and a reason, plus the pseudonymous ID if your retention rules allow it. Do not log the whole context object by default.
Targeting rules are policy
A rule such as "enable for plan equals enterprise" is a business decision encoded in a flag system. A rule such as "enable for users whose email ends in a domain" depends on personal data and is harder to defend. Prefer rules built on IDs and segments that your own system computes.
Compute the segment on your side and send the result. That way the flag service never needs the raw attributes.
Review checklist
- List every attribute in the context and the reason for each.
- Confirm where your provider stores or logs context.
- Check hooks and telemetry for context dumps.
- Document retention for flag evaluation logs.
- Re-check when you add a new attribute, since each addition widens what a third party holds.
Quick check
Should I put the user's email in the flag context?
Avoid it. Use a stable pseudonymous ID and coarse segments. Email is personal data that may reach a third party and your logs.
Where does the evaluation context end up?
It depends on the provider. OpenFeature says providers may call a vendor SDK, a REST API or a local file, so check yours.
Sources
Last reviewed: 19 October 2026.
