Skip to main content

​
Feature Flags

Feature Flags let you control who sees a feature and when, enabling gradual rollouts, targeted deployments, and instant kill-switches for risky functionality.
Feature Flags is a separately priced product add-on currently only offered to those on the Enterprise Plan. See our pricing page for more details.

​
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.

​
Key Concepts

  • 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
  • Runtime Properties — request-time attributes (e.g., URL path, app version) used to target immediately
  • Runtime Events — event-based targeting (e.g., user clicked button, completed purchase)

​
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 rollout.
  2. Experiment: Deliver different variant experiences (e.g., layouts, flows, pricing) to a targeted group of users. Enables measuring and analyzing impact.
  3. Dynamic Config (Coming Soon): Configure features with flexible key-value pairs instead of just on/off. Pass JSON payloads to customize behavior or UI dynamically.

​
Setup Instructions

1

Choose Variant Assignment Key

Select the randomization bucket unit that best fits your use case:
  • User distinct_id — best for logged-in experiences across devices; 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
  • Group group_id — target by account/org using a group key (e.g., account_id). Values for group keys will need to be supplied to the Mixpanel feature flag SDK through the context parameter
2

Configure Variants

Set up your variants and their allocation:
  • Define variant names (e.g., control, A, B)
  • Set variant split percentages (e.g., 10% of users in variant A, and 90% in variant B)
  • Enable sticky variants to ensure continuity in the variant experience
Control variant is always set to non-sticky. This ensures this is the only group of users that can move up to other variants if allocation of other variants is increased.
3

Set Up Rollout Groups

Configure targeting for your feature flag:
  • Target ‘All Users’ or specific cohorts based on user behavior or properties
  • Set rollout percentage for each group
  • Add runtime properties for immediate, per-request decisions (e.g., platform, country)
  • Add runtime events to target users when they perform specific actions
Cohorts used in feature flag targeting refresh on a periodic cadence (~every 2 hours). So once a user qualifies for a cohort, it can take up to 2 hours before they see a desired experience.
4

Test with QA Testers

Whitelist specific users who will receive the experience before rolling out broadly:
  • Select users based on the $email user profile property
  • Specify which experience each tester should receive
  • Validate eligibility and variants work as expected

​
Implementation Examples

​
JavaScript SDK

// Initialize Mixpanel with feature flags
mixpanel.init('YOUR_PROJECT_TOKEN', {
  loaded: function(mixpanel) {
    // Get feature flag value
    const variant = mixpanel.get_feature_flag('new-checkout-flow');
    
    if (variant === 'test') {
      // Show new checkout experience
      showNewCheckout();
    } else {
      // Show default checkout
      showDefaultCheckout();
    }
  }
});

​
Python SDK

from mixpanel import Mixpanel

mp = Mixpanel('YOUR_PROJECT_TOKEN')

# Get feature flag value for a user
variant = mp.get_feature_flag(
    flag_key='new-pricing-page',
    distinct_id='user_123',
    context={'device_id': 'device_456'}
)

if variant == 'variant_a':
    # Show variant A pricing
    show_pricing_a()
else:
    # Show default pricing
    show_default_pricing()

​
iOS (Swift) SDK

// Get feature flag value
let variant = mixpanel.getFeatureFlag("new-onboarding")

if variant == "enabled" {
    // Show new onboarding flow
    showNewOnboarding()
} else {
    // Show default onboarding
    showDefaultOnboarding()
}

​
Runtime Targeting

Runtime targeting enables immediate, per-request decisions using two methods:

​
Runtime Properties

Target users immediately based on device or platform properties: 
// Pass runtime properties at request time
mixpanel.get_feature_flag('mobile-banner', {
  'platform': 'Android',
  'country': 'UK',
  'app_version': '2.3.0'
});

​
Runtime Events

Target users immediately when they perform specific actions: 
// Track event and check flag
mixpanel.track('Completed Onboarding');

// User will be targeted if flag uses "Completed Onboarding" runtime event
const variant = mixpanel.get_feature_flag('welcome-offer');
Runtime events can include filters on event properties for more fine-grained control (e.g., purchase_amount > $100, page_path contains ‘/checkout’).

​
Performance & Reliability

​
Privacy

  • EU & IN projects must initialize the SDK’s with the correct api host endpoints for their regions
  • You should only send the context/runtime properties you need; avoid sensitive PII

​
Regions

Keep traffic within region by using the correct project & API hosts.

​
Reliability

Mixpanel analytics downtime will result in suspended cohort membership refreshes, though feature flag variants will continue to be served.
  • When using sticky variants, the last available variant per user will be served
  • In case of Feature flagging service downtime, your fallback variant will be served by the SDKs

​
Performance

The latency of Feature flags API responses is usually on the order of milliseconds.
Cohort membership is refreshed every 2 hours when targeting anything aside from ‘All Users’ or ‘Run Time Properties’. Therefore, new users entering cohorts may not be reflected in Feature flags API responses for up to that 2 hour period.

​
Testing Environment Best Practices

Use separate Mixpanel projects, which are connected to your different environments, to reduce risk and promote safety:
  1. Dev Project — rapid iteration; permissive targeting
  2. Staging Project — mirrors prod cohorts; dry runs for promotion
  3. Prod Project — customer-facing
1

Create in Dev

Create the flag in dev with a consistent Flag Key. Validate eligibility, variants, etc.
2

Test in Staging

Create the same flag in staging using the same Flag Key. QA Test in this mode.
3

Deploy to Production

Create the same flag in prod using the same Flag Key. Ensure the right edit permissions are provided, and the right rollout % is set.

​
Governance & Permissions

​
Permissions

  • Project Role — you need to have at least an “analyst” role to create and edit feature flags. “Consumer” roles can only view feature flags
  • Feature Flag Permissions — You can manage share settings per flag. Only editors for a flag will have access to modify a flag generally

​
Audit Trail

This shows the history of changes related to the flag. This allows you to know the change history (who, what, when) of all the updates.

​
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. Can I target a cohort and include run-time targeting like device or url path? Yes. 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? 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. Are there any limits to variants or rollout groups? Yes, today you can have a maximum of 5 variants per flag, and a maximum of 5 rollout groups per flag. How do we avoid overlapping target audiences across 2 different feature flags? In feature flag B, create Rollout Group 1 targeting users who were exposed to feature flag A, serve control 100% at 100% rollout. Then create Rollout Group 2 for your actual flag B targeting.

​
Pricing FAQ

Feature Flags is a separately priced product offered to organizations on the Enterprise Plan. Please contact us for more details.

​
Pricing Unit

Feature Flags are priced based on Feature Flag API Requests and number of ‘active’ feature flags at any time. What is a Feature Flag API Request? A feature flag API request is a call made by your application to determine which features should be enabled or disabled for a user. All the active flags in the system are evaluated as part of this API request. How can I estimate Feature Flag API requests? In general, you can expect every user session to have 1 API request. So monthly API requests is at minimum equivalent to the total user sessions that month. General rule of thumb: would consider API requests to be 1.5 x User Sessions considering implementation challenges. What happens if I go over my purchased Feature Flag API Request bucket? You can continue using Mixpanel Feature Flags, but you will be charged a higher rate for the overages. Is there a limit on number of feature flags per API request? Yes, there is a limit depending on the plan you purchase. You can choose from 3 plans: to have up to 50, 200 or 1000 ‘active flags’ per API request.

Build docs developers (and LLMs) love

Get started for freeTalk to us