PostHog / PostHog/posthog

Feature flags: Multivariate flag UI causes confusion between variant splits and release conditions

Open
#47,702 0 comments 0 reactions 1 assignee View on GitHub

@dmarticus is already working on this.

Since Feb 12, 2026.

feature/feature-flags team/feature-flags
Dominant language
Python
Stars
39.9k
Forks
3.4k
Avg merge
6h 51m
Merged PRs (30d)
232

Description

Problem

The new feature flag UI for multivariate flags is confusing users. The core issue is that variant percentage splits and release condition rollout percentages are conceptually different but the UI doesn't make this distinction clear.

Example of the confusion

A user set up a multivariate flag with:

  • Variants: control (50%) and test (50%)
  • Two release conditions, each targeting "All Users" at 50% rollout, with variant overrides

This resulted in:

  • Condition 1: "For 100% of users, send 50% to test"
  • Condition 2: Ignored because 100% matched the first condition

The edit view showed something that "looked sorta right" but wasn't configured as intended.

Proposed Solutions

Short-term: Add a condition summary

Add a full condition summary at the end of the release conditions that explains in plain language what the flag will actually do. This helps users verify their configuration matches their intent.

Long-term: Move variant splits to belong to rollout rules

Instead of having global variant percentages separate from release conditions, allow different variant splits for different sets of users within each rollout rule.

Benefits:

  • Easier to read top-to-bottom
  • Unlocks new functionality: different splits for different user segments
  • Aligns with how other feature flag products work
  • Fits nicely with the goal of running multiple experiments for the same flag

Context

The fundamental confusion is:

  • Variant splits: How to distribute users among variants (e.g., 50/50 between control and test)
  • Release condition rollout: What percentage of users matching the condition should get the flag at all

These are different concepts but the current UI conflates them, leading to configurations that "look right" but don't behave as expected.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.