Feature Flags

Overview

Feature Flags let you control who sees a feature and when. Use them to:

• Gradually roll out changes (E.g 1% → 10% → 100%)
• Target cohorts, regions, platforms, or group accounts
• Kill-switch risky functionality instantly
• Serve variants for A/B/x tests and analyze results with Mixpanel Experiments

Flags deliver variants to users whereas Experiments measure impact with statistical rigor. Use flags to deploy and orchestrate and use experiments to decide.

Concepts & terminology

• Flag Key — unique identifier for a flag used by SDKs.
• Variant Assignment Key — the randomization bucket unit: distinct_id (user), device_id, or a group key like account_id.
• Variants — experience labels (e.g., control, A, B).
• Variant Splits — allocation across variants (e.g., 90%/10%).
• Fallback Value — variant to use when an assignment is unavailable.
• Sticky Variants — the same entity keeps the same variant over time.
• Rollout Groups - The configuration determining which users are in the rollout. This is comprised of:
  • Targeting — eligibility definition (All Users vs Cohorts; may include runtime properties).
  • Rollout % — percentage of the eligible audience that receives the flag now.
• Rollout % — percentage of the eligible Rollout Group that receives the flag now.
• Runtime Properties — request-time attributes (e.g., URL path, app version) used to target immediately.
• Assignment vs Exposure — assignment is deciding the variant; exposure is when your app uses that variant to render.
• Feature Flag API Request - is a call made to a feature flag API to retrieve the current state or configuration of one or more feature flags. This request allows an application to dynamically determine which features should be active for a particular user

Types of Feature Flags

We support the following types of Flags

1. Feature Gate : Toggle a feature on or off for targeted users or all users. Useful for phased or controlled rollouts.
2. Experiment : Deliver different variant experiences (e.g., layouts, flows, pricing) to a targeted group of users. Enables measuring and analyzing impact.
3. [Coming Soon] Dynamic Config : Configure features with flexible key-value pairs instead of just on/off. Lets you:
   • Pass JSON payloads (e.g., {"cta_text": "Buy now", "discount": 20}) to customize behavior or UI dynamically
   • Update values instantly without redeploying code

Variant Assignment Key

This is the randomization bucket unit: distinct_id (user), device_id, or a group key like account_id.

How to choose the right key?

• User distinct_id — best for logged-in experiences across device; a user sees a consistent experience across various sessions and devices

• Device device_id — best for pre-auth or acquisition flows; a device keeps a consistent variant between pre-auth and post-auth experiences.

• For projects that support (Group Analytics), you can choose one of your group keys as the Variant Assignment Key as well.

  • Group group_id — target by account/org using a group key (e.g., account_id).

Variants Management

Variants are served / allocated around the variant assignment key

Variant management includes 3 concepts -

• Variants are the experiences to serve. (e.g., control, A, B).
• Variant split % is the allocation across the variants.
  • For example, 10% of users in variant A, and 90% in variant B.
• Sticky Variants ensures continuity in the variant experience served
  • If a user is assigned to a sticky variant B, regardless of how variant splits, rollout percentagek, or cohort memberships change in the future, the user will continue to see the variant B.

Rollout Groups

Feature flags may consistent of one or more rollout groups. Users are evaluated against each rollout group in order until one is found that the user qualitifes for. They consist of two parts.

1. Cohorts
2. Rollout Percentage

Cohorts

You can optionally target rollout of your feature flags to subsets of your user base rather than to all your users with Cohorts. These are dynamic audiences of Mixpanel users based on user behavior or properties. Use these to target feature flag rollouts to specific subsets of your user base.

The configuration determining which users are in the rollout.

• Runtime Targeting
  • When building a cohort, if you add a filter, navgiate to + Create New, you’ll be able to add a new runtime property filter.
  • Runtime properties (e.g., platform, path, country) should be passed by the SDK at request time for immediate, per-request decisions.

Rollout Percentage

This is the percentage of the requests that should be targeted, according to the Variant Assignment Key.

Example: If we want to rollout to 50% of Active Users cohort, and 10% to Dormant User Cohort, we would create

• 2 rollout groups : Rollout Group 1 - Active Users, Rollout Group 2 - Dormant Users
• Rollout percentage will be applied to each Rollout Group : 50% and 10% respectively

Variant allocation happens within the roll-out group.

Example: Building on the same example above, variant allocation is 50-50 for A/B.

• Rollout Group 1 - Active users will see - 25% users in A (50% of 50%); 5% users in B (50% of 50%)
• Rollout Group 2 - Dormant users will see - 5% users in A (50% of 10%); 5% users in B (50% of 10%)

Implementation

Feature Flagging is supported on three client-side SDK’s: Web, iOS, and Android and currently on one server-side SDK, python.

See our developer guides on implementing feature flags on these platforms below:

Coming soon: React Native, Java, Ruby

QA Testers

This section allows you to override which variants specific users who will receive the experience.

Governance, approvals & audit

We recommend establish light-weight controls without slowing teams:

• Ownership — Every flag must have an owner and an expiry/intent note (release / experiment / kill-switch).
• Change management — Use a review process for potentially risky changes, such as those impacting revenue flows or have widespread impact.
• Auditability — Use the Feature Flag audit history to review changes that are made to a flag over time.

Performance, Reliability & security

• Privacy — send only the context/runtime properties you need; avoid sensitive PII.
• Regions — keep traffic within region by using the correct project & API hosts.
  • EU & IN projects must initialize SDK’s with the correct api host endpoints for their region.
• Choose the best mode for your use case
  • Remote evaluation
    • This is supported by client SDK’s.
    • Supports mixpanel cohorts targeting & sticky variants.
    • Each evaluation sends a network request so handle timeouts and network failures appropriately with
  • Local evaluation
    • In addition, server-side SDK’s support this mode, where flag settings are periodically polled.
    • Each evaluation does not require a network request so is low latency and not expected to throw errors.

Frequently Asked Questions

• How do Data Views affect feature flags?

  • Feature flags are scoped to data views.
  • If targeting your flag to specific user cohorts, only end users included in the data view where the flag is created, will be targeted.
  • Only users with access to a data-view and can view and edit the flag

• Can I target a cohort, but also include run-time targeting like device or url path? Yes, you can. You can couple run-time targeting with general cohorts. It works with an and condition across the 2 groups.

• Why is control variant always non-sticky? I want all my variants to be sticky Control variant is set to always be non-sticky to ensure this is the only group of users that can move up to other variants if allocation of other variants is increased. This is to avoid users moving from non-control variants. NOTE: If you do want all users to be sticky and do not anticipate needing to change the variant allocation, mark control variant as 0%, and allocate all the 100% to the other variants This is recommended for use-cases where you have no default or control experience, and are testing a brand new experience with 2+ variants

• Are there any limits to variants or rollout group? Yes, today you can have a maximum of 5 variants per flag, and a maximum of 5 rollout groups per flag

• We use a CDP in our company. How do we use Mixpanel Feature Flags with our CDP? When you initialize the mixpanel feature flag SDK, configure it to not track any $experiment_started events directly to Mixpanel. This way you use the mixpanel SDK to serve the feature flags, but when an end-user sees exposure, they manually use their existing method of tracking events through their CDP to mixpanel to track the$experiment_started event