Feature Flags and Privacy: Evaluation Models Compared

Apr 20, 2026
4 min read
TL;DR

Compare remote flag evaluation, local SDK rules, caching and exposure tracking, with verified documentation and a practical privacy review checklist.

Feature Flags and Privacy: Evaluation Models Compared

Featured Image

Feature flags and analytics can work together, but privacy depends on the evaluation requests, storage and events your configuration uses. A cached flag value is not the same as local rule evaluation, and a randomly generated identifier is not automatically anonymous.

This guide compares evaluation architectures and the evidence to request before choosing one. Databuddy publishes it and is included below. For an implementation checklist, use the rollout verification guide.

Separate evaluation, storage and measurement

Evaluation decides which value or variant an application receives. Caching stores a result or ruleset for reuse. Measurement records an evaluation, a rendered exposure or an outcome. These stages can use different services and identifiers, so inspect each one rather than assuming that an integrated product keeps every stage local.

ArchitectureWhat happensWhat to inspect
Remote evaluationThe application sends context to a service and receives flag results.Request fields, destination, processing arrangements and failure defaults.
Local rule evaluationAn SDK evaluates downloaded definitions in the application runtime.Ruleset access, refresh behavior, telemetry and any remote fallback.
Cached resultsThe application reuses an earlier result until it refreshes.Storage keys, identity changes and stale-result behavior.
Exposure and outcome trackingEvents describe what was shown and what happened afterward.Event properties, identifiers, deduplication and reporting coverage.

Databuddy: remote evaluation with cached results

Databuddy's SDK sends flag evaluation requests to its bulk flags endpoint and caches returned values. Its request context can include a user ID, email, organization ID, team ID and custom properties when supplied. This is not a guarantee that user context stays in the browser.

The feature flags reference documents provider configuration, targeting, environments, loading states and defaults. Check the SDK version you deploy, inspect its network requests and pass only the context your rollout requires. Browser caching and analytics collection should be reviewed separately.

Do not promise automatic experiment conclusions from a flag assignment. The documentation distinguishes observed evaluations from actual feature use and notes that there is no built-in experiment results view. Record the exposure and confirmed outcome you need, then verify how you will compare variants.

Unleash: distinguish backend and frontend evaluation

Unleash's SDK overview distinguishes backend SDKs that evaluate locally from frontend SDKs that fetch evaluated results through Unleash Edge or the Frontend API. Its browser SDK documentation explains that supplied context is sent for evaluation.

Choose the exact SDK and deployment path before describing its data flow. A backend SDK's local evaluation does not establish that a browser integration uses the same architecture or that analytics telemetry stays local.

PostHog: server-side local evaluation has specific requirements

PostHog's local evaluation guide describes supported server SDKs, downloading flag definitions and restrictions. It requires a secret API key that must stay out of frontend code. Review cold starts, refreshes and fallback behavior in the runtime you use.

Evaluate analytics collection and replay separately from the flag decision. Choosing local flag evaluation does not configure every other product in the platform.

GrowthBook: inspect evaluation and tracking together

GrowthBook's JavaScript SDK supports feature evaluation in the browser and documents experiment tracking callbacks and optional tracking plugins. Decide which event destination and attributes you will use before enabling them.

Separating assignment from event collection can give a team control over its measurement design, but it also creates an integration to maintain. Test that the exposure record describes the variant actually presented and can be compared with the intended outcome.

Review storage and identifiers without relying on labels

The UK's ICO guidance covers storage and access technologies including local storage. Moving a value from a cookie to localStorage does not by itself settle the applicable requirements. The European Commission also explains that pseudonymised data can remain personal data when a person can be re-identified.

Record the actual context, storage, event properties, retention and processing locations with the responsible owner. Verify current contractual and certification evidence directly when required; an integration guide is not evidence of a vendor certification or a legal exemption.

Choose the architecture you can verify

Before a rollout, test the fallback, identity changes, stale results, an unavailable evaluation service and the exposure-to-outcome report. Keep an owner and removal date for temporary flags. Use the custom event measurement guide to define outcomes and the rollout checklist to verify the release.

Screenshot of https://www.databuddy.cc

Screenshot of https://www.getunleash.io/feature-flag-service

Screenshot of https://www.growthbook.io/platform/warehouse-native