diff --git a/pages/docs/_meta.tsx b/pages/docs/_meta.tsx
index d4de939167..c7be37d072 100644
--- a/pages/docs/_meta.tsx
+++ b/pages/docs/_meta.tsx
@@ -43,6 +43,7 @@ export default {
},
reports: "Reports",
boards: "Boards",
+ featureflags: "Feature Flags",
experiments: "Experiments",
metric_tree: "Metric Trees",
users: "Users",
diff --git a/pages/docs/featureflags.mdx b/pages/docs/featureflags.mdx
new file mode 100644
index 0000000000..0e7b92f59a
--- /dev/null
+++ b/pages/docs/featureflags.mdx
@@ -0,0 +1,185 @@
+import { Cards, Callout } from 'nextra/components'
+
+# Feature Flags
+
+
+ Feature Flags is coming soon for customers with an Enterprise subscription plan.
+
+
+## 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 rollout.
+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
+
+## Targeting & Identity Management
+
+### 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](/docs/data-structure/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 percentage, or cohort memberships change in the future, the user will continue to see the variant B.
+
+
+Control variant by is always set to non-sticky. This is to ensure this is the only group of users that can move up to other variants if allocation of other variants is increased.
+
+
+### 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 qualifies for.
+
+You can target 'All Users', or optionally target rollout of your feature flags to subsets of your user base rather than to all your users with [Cohorts](https://docs.mixpanel.com/docs/cohorts).
+These are dynamic audiences of Mixpanel users based on user behavior or properties. Use these to target feature flags to specific subsets of your user base. For example, target only users who did 5 purchases in the last week.
+
+
+ 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.
+ If you want users to continue seeing the same variant even if they disqualify from the cohort in the future, couple this with **Sticky Variants.** This will ensure a user continues to see the new experience until he flag is turned off.
+
+
+**Runtime Targeting** enabled targeting users immediately based on device or platform properties. For example, only users who are on android device and in the UK
+- When building a cohort, if you add a filter, navigate 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%)
+
+
+## Governance, permissions & audit trail
+
+We recommend establish light-weight controls without slowing teams:
+- **Project Role** — you need to have at least an “analyst” role to create and edit feature flags. “Consumer” roles can only view feature flags.
+ [coming soon] Overall Feature Flag permissions - this setting allows you to give users or teams access to all feature flags. It overrides the permissions set at a per-flag level. For example, you might want your ops-lead team to have edit access to all flags for emergencies.
+- **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** — Shows the history of changes related to the flag. This allows you to know the change history (who, what, when) of all the updates.
+
+### QA Testers
+
+This section allows you to whitelist users who will receive the experience, vs rolling out more broadly. You can select users based on the $email user profile property. Once selected, you can specify which experience you would like each user to get.
+
+### Testing Environment
+
+Use separate Mixpanel projects, which are connected to your different environments, to reduce risk and promote safety. You might have just 1 or 2 of these, which is also fine -
+1. **Dev** **Project** — rapid iteration; permissive targeting
+2. **Staging Project** — mirrors prod cohorts; dry runs for promotion.
+3. **Prod Project** — customer-facing
+
+Recommended workflow:
+- Create the flag in **dev** with a consistent **Flag Key**. Validate eligibility, variants, etc.
+- Create the same flag in **staging.** Use the same **Flag Key.** QA Test in this mode
+- Lastly, create the same flag in **prod.** Use the same **Flag Key.** Ensure the right edit permissions are provided, and the right rollout % is set.
+
+
+## Performance, Reliability & security
+
+- **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.
+
+## 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
+
+
+If you'd like to see Feature Flags availability in other SDKs, please [reach out to the Support team](https://mixpanel.com/get-support).
+
+
+## Frequently Asked Questions
+
+**How do [Data Views](/docs/data-governance/data-views-and-classification) 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 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
+
+**How do we avoid overlapping target audiences across 2 different feature flags?**
+Let’s say we have 2 features: feature A and feature B, and we want these to be non-overlapping in audience targeting.
+In the feature flag B page, in the target audience -
+- Create Rollout Group 1: any user who was exposed to feature flag A
+ - Variant served: control 100% (no new experience, revert to default)
+ - Rollout % : 100%
+- Create Rollout Group 2: All users, or any specific users you want for flag B
+
+**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
diff --git a/pages/docs/tracking-methods/sdks/android/_meta.ts b/pages/docs/tracking-methods/sdks/android/_meta.ts
index 3ab8f090a1..5ee586c759 100644
--- a/pages/docs/tracking-methods/sdks/android/_meta.ts
+++ b/pages/docs/tracking-methods/sdks/android/_meta.ts
@@ -1,3 +1,4 @@
export default {
- "android-replay": "Session Replay (Android)"
+ "android-replay": "Session Replay (Android)",
+ "android-flags": "Feature Flags (Android)"
}
diff --git a/pages/docs/tracking-methods/sdks/android/android-flags.mdx b/pages/docs/tracking-methods/sdks/android/android-flags.mdx
new file mode 100644
index 0000000000..52b65bd99e
--- /dev/null
+++ b/pages/docs/tracking-methods/sdks/android/android-flags.mdx
@@ -0,0 +1,183 @@
+import { Callout } from 'nextra/components'
+
+# Implement Feature Flags (Android)
+
+## Overview
+
+This developer guide will assist you in configuring your Android platform for Feature Flags using the [Mixpanel Android SDK](/docs/tracking-methods/sdks/android). Feature Flags allow you to control the rollout of your features, conduct A/B testing, and manage application behavior without deploying new code.
+
+For complete Android SDK documentation, see the [Android SDK guide](/docs/tracking-methods/sdks/android).
+
+## Prerequisites
+
+Before implementing Feature Flags, ensure:
+
+- You are on an Enterprise subscription plan and have the latest version of the SDK installed (minimum supported version is [`v8.2.4`](https://github.com/mixpanel/mixpanel-android/releases/tag/v8.2.4)). If not, please follow [this doc](/docs/quickstart/install-mixpanel) to install the SDK.
+- You have your Project Token from your [Mixpanel Project Settings](/docs/orgs-and-projects/managing-projects#find-your-project-tokens)
+
+## Flag Initialization
+
+Initializing the SDK with feature flags enabled requires setting the `featureFlagsEnabled` option to `true` in `MixpanelOptions`. This enables making an outbound request to Mixpanel servers with the current user context.
+The server will assign the user context to a variant for each feature flag according to how they are configured in the Mixpanel UX.
+
+The response will include an assigned variant for each flag that the user context is in a rollout group for. If a flag is not returned, it most likely signifies that the user was either not in the rollout percentage for a flag or in the configured targeting cohort.
+
+**Example Usage**
+
+```java Java
+MixpanelOptions options = new MixpanelOptions();
+options.featureFlagsEnabled = true;
+
+MixpanelAPI mixpanel = MixpanelAPI.getInstance(context, "YOUR_PROJECT_TOKEN", options);
+```
+
+If your flag is configured with a Variant Assignment Key other than `distinct_id` for any of the feature flags in your project, then the call to initialize feature flags must include those keys.
+
+For example, for a Variant Assignment Key, `company_id`, you would setup the SDK as follows:
+
+```java Java
+JSONObject context = new JSONObject();
+context.put("company_id", "X");
+
+MixpanelOptions options = new MixpanelOptions();
+options.featureFlagsEnabled = true;
+options.featureFlagsContext = context;
+
+MixpanelAPI mixpanel = MixpanelAPI.getInstance(getApplicationContext(), "YOUR_PROJECT_TOKEN", options);
+```
+
+If you are using Runtime Targeting in any of the feature flags in your project, then any properties that you use in targeting should be included in a `customProperties` node within the context:
+
+```java
+JSONObject customProperties = new JSONObject();
+customProperties.put("platform", "android");
+
+JSONObject context = new JSONObject();
+context.put("company_id", "X");
+context.put("customProperties", customProperties);
+
+MixpanelOptions options = new MixpanelOptions();
+options.featureFlagsEnabled = true;
+options.featureFlagsContext = context;
+
+MixpanelAPI mixpanel = MixpanelAPI.getInstance(getApplicationContext(), "YOUR_PROJECT_TOKEN", options);
+```
+
+## Flag Reload
+
+Following initialization, you can reload feature flag assignments in a couple of ways:
+
+1) After a user logs in or out of your application and you call `identify`, a feature flag reload will be triggered.
+
+```java
+String updatedDistinctId = "";
+mixpanel.identify(updatedDistinctId);
+```
+
+2) If variant assignment keys or properties used in Runtime Targeting change during the lifetime of your application, you can manually reload flags by updating the context:
+
+```java
+JSONObject newCustomProperties = new JSONObject();
+newCustomProperties.put("platform", "android");
+
+JSONObject newContext = new JSONObject();
+newContext.put("company_id", "Y");
+newContext.put("customProperties", newCustomProperties);
+
+// Update the context and reload flags
+mixpanel.getOptions().featureFlagsContext = newContext;
+mixpanel.getFlags().loadFlags();
+```
+## Flag Evaluation
+
+Lookup the assigned value for a feature flag.
+This action triggers tracking an exposure event, `$experiment_started` to your Mixpanel project *if* the user context is in a rollout group for the feature flag.
+
+### Asynchronous Flag Variant Retrieval
+
+**Experiment Flags: Get Variant Value**
+
+```java
+// Get just the flag value asynchronously
+mixpanel.getFlags().getVariantValue("my-feature-flag", "control", new FlagCompletionCallback