How to Ship a Feature Behind a Flag and Measure Its Impact in PostHog

Feature flags are available in plenty of tools as a simple on/off switch, but PostHog's actual differentiator is that flags, analytics, session replay, and experimentation all live on the same event pipeline. That only pays off if a rollout is set up to use that connection deliberately, rather than treating the flag as a lighter-weight deploy mechanism with no measurement plan attached. Here's the version that uses the whole platform, not just the switch.

For background on what PostHog is, its usage-based pricing, and how it compares to Amplitude or Mixpanel, see our full PostHog profile.

Step 1: Define the Metric the Feature Is Supposed to Move Before Writing the Flag

Before creating anything in PostHog, decide specifically what success looks like for this feature, activation rate, a specific conversion step, retention at a defined interval, and how you'll measure it using events already being tracked or new ones worth adding. A flag rolled out with no predefined metric turns into a feature that ships and then gets evaluated by vibes and support ticket volume, which is exactly the kind of ambiguous outcome PostHog's bundled analytics is built to prevent, if the metric gets decided before rollout rather than reverse-engineered from whatever data happens to be available afterward.

Step 2: Create the Flag With a Kill-Switch Mindset

Build the feature flag with a clear key and a description documenting what it controls and what phases the rollout will move through, and write the code so it checks the flag rather than assuming the feature is always on. This isn't just a rollout mechanism, it's a kill switch: if something goes wrong at any rollout percentage, turning the flag off should be an instant, code-free action rather than requiring a new deploy. Treat that instant-rollback capability as the actual point of using a flag at all, not just a convenient way to stage a launch.

This distinction matters more than it might seem to a team used to feature flags purely as a deployment convenience. A flag that only exists to stage a code release is solving a deployment problem. A flag connected to a defined metric and, eventually, a formal experiment is solving a measurement problem at the same time, using the same mechanism, which is the entire reason to reach for a platform that bundles both rather than a lighter-weight flagging tool with no analytics attached.

Step 3: Start the Rollout at a Small Percentage, Not a Coin-Flip Split

Set the flag's release condition to a small percentage, commonly starting around 1%, rather than jumping straight to a 50/50 split. For an internal team or beta cohort, target the flag by a specific property or group first, dogfooding it internally before it reaches any real percentage of external users. This early, narrow exposure is where the most expensive bugs get caught cheaply, before they've touched a meaningful share of real traffic.

Step 4: Watch Session Replay and Error Tracking Specifically on the Early Cohort

While the flag sits at a low percentage, use PostHog's session replay and error tracking, filtered specifically to users who have the flag enabled, rather than relying on aggregate metrics alone to judge whether the feature is working. Aggregate numbers at 1% of traffic are too small a sample to be statistically meaningful yet, but watching a handful of actual sessions and checking for new errors tied to the flag catches usability problems and outright bugs that a metrics dashboard won't surface until much more traffic has been exposed to them.

Step 5: Convert the Rollout Into a Formal Experiment Once the Feature Is Stable

Once the early cohort shows no major issues, create a formal experiment tied to the same underlying flag, setting the flag's variants to match the experiment's control and treatment groups, and defining the primary metric from Step 1 as what the experiment actually measures. This is the step that turns a rollout into an actual test of impact rather than just a staged deployment, and it's the specific capability that separates PostHog's approach from a simpler flagging tool with no attached experimentation layer.

It's worth being explicit about why the flag-based experiment differs from a standalone A/B testing tool bolted onto a marketing site: the population being tested is your actual product's real users, segmented by the exact same properties and events already flowing through your analytics, rather than an external testing tool trying to reconstruct a similar picture from a separate, thinner data source. That shared data model is what makes the experiment's results directly comparable to the rest of your product analytics, cohort behavior, retention curves, funnel data, without needing to stitch two different tools' definitions of a "user" together after the fact.

Step 6: Ramp the Percentage Gradually, Watching the Metric at Each Step

Move the release condition up in stages, a common pattern is roughly 1% to 10% to 50% to 100%, checking the defined success metric and error rate at each step before advancing further rather than on a fixed calendar schedule regardless of what the data shows. A metric that degrades at 10% is far cheaper to catch and roll back than the same problem discovered only after reaching 100%, and gradual ramping is specifically what preserves that cheap early exit at every stage of the rollout.

Step 7: Clean Up the Flag Once It Reaches Full Rollout

Once a feature is fully and permanently rolled out, remove the flag check from the codebase and archive the flag rather than leaving it in place indefinitely. A codebase that accumulates old, fully-rolled-out flags as permanent conditional branches becomes harder to reason about over time, and the discipline of retiring flags once they've served their purpose keeps the flag list itself a genuine record of active rollouts rather than a growing pile of dead switches nobody remembers the purpose of.

A Few Mistakes That Undo This Workflow

A handful of habits reliably turn a well-instrumented rollout process into a wasted one. Jumping straight to a large rollout percentage because the feature "seems fine" in local testing skips the exact stage, a small, real-traffic cohort, where genuinely unpredictable issues actually surface. Treating the flag purely as a deployment mechanism and skipping the tied experiment means shipping something and never actually knowing whether it moved the metric it was built to move, which quietly defeats the entire point of bundling flags and experimentation on the same platform. And leaving fully-rolled-out flags in the codebase indefinitely, rather than cleaning them up once they're no longer serving a rollout purpose, is how a codebase slowly fills with permanent conditional branches that make every future change harder to reason about, for a purpose that stopped existing months earlier.

What This Workflow Actually Produces

Done this way, a PostHog rollout produces something meaningfully more useful than a feature that's simply live: a documented decision about what success meant going in, an early warning system through the low-percentage cohort and its session replays, a formal measurement of actual impact through the tied experiment, and a codebase that isn't accumulating permanent debt from flags nobody cleaned up. That's a different outcome than using PostHog's feature flags as a fancier on/off toggle, and it's the difference between a platform that bundles analytics, flags, and experimentation for a reason and one where those capabilities sit unused next to each other.

None of this requires every product surface to be flagged and experimented on to be worthwhile. Reserving this level of process for genuinely uncertain, meaningful changes, and shipping smaller, obviously safe changes without the full ceremony, keeps the discipline sustainable rather than turning every minor tweak into an overbuilt rollout process nobody has the bandwidth to maintain consistently.

If you're still deciding whether PostHog's all-in-one, usage-based approach fits your team better than Amplitude or Mixpanel, our PostHog tool profile covers the pricing and feature tradeoffs in more detail.