How to run Experiments without Feature Flags

You can run Experiments without using PostHog's Feature Flags if you're using a different feature flag library and want to track your experiment results in PostHog.

This doc walks you through how to set up an experiment without using PostHog's Feature Flags.

Step 1: Create your experiment in PostHog

Create a new experiment in the Experiments tab and follow the same steps as you would when creating a regular experiment.

Note: Although you won't be using PostHog's Feature Flags directly, you still need to name your feature flag key. This key is used to identify which events belong to your experiment when PostHog calculates results.

You can name variants whatever you like. The results baseline is the variant named 'control' when one exists, otherwise the first variant.

Step 2: Display the variant using your own feature flag system

Your feature flag system handles the variant assignment. PostHog only needs to know which variant was shown to each user through the events you send.

Step 3: Configure a custom exposure event

In your experiment settings, set a custom exposure event instead of using the default $feature_flag_called event. Choose an event that fires when users encounter your experiment.

For example:

• $pageview - if users are exposed when they load a page
• button_clicked - if users are exposed when they interact with a feature
• Any custom event from your application

Note: The exposure event tells PostHog when a user enters the experiment. This is separate from your metric events (which measure the experiment's impact).

Step 4: Add the variant property to your exposure event

To attribute users to the correct experiment variant, include a $feature/<experiment-flag-key> property with the variant name when capturing your exposure event (the event you configured in Step 3).

The property key format is $feature/ followed by your experiment's feature flag key. For example, if your experiment's flag key is new-checkout-flow, use $feature/new-checkout-flow as the property key.

Note: Metric events don't need this property. PostHog attributes metric events by matching them to the user's exposure, so any metric event the user sends after exposure counts, with or without the property. When using PostHog's Feature Flags with our SDKs, the property is added automatically.

If your experiment's flag key is new-checkout-flow and you use $pageview as your exposure event:

// Get variant from your feature flag system
const variant = yourFlagSystem.getVariant('new-checkout-flow')

// Send exposure event
posthog.capture('$pageview', {
    "$feature/new-checkout-flow": variant  // "control" or "test"
})

// Later, send metric events as usual - no variant property needed
posthog.capture('purchase_completed', {
    "revenue": 99.99
})

// Get variant from your feature flag system
const variant = yourFlagSystem.getVariant('new-checkout-flow')

// Send exposure event
posthog.capture('$pageview', {
    "$feature/new-checkout-flow": variant
})

// Later, send metric events as usual - no variant property needed
posthog.capture('purchase_completed', {
    "revenue": 99.99
})

// Get variant from your feature flag system
const variant = yourFlagSystem.getVariant('new-checkout-flow')

// Send exposure event
client.capture({
    distinctId: 'user_id',
    event: '$pageview',
    properties: {
        '$feature/new-checkout-flow': variant
    }
})

// Later, send metric events as usual - no variant property needed
client.capture({
    distinctId: 'user_id',
    event: 'purchase_completed',
    properties: {
        'revenue': 99.99
    }
})

# Get variant from your feature flag system
variant = your_flag_system.get_variant('new-checkout-flow')

# Send exposure event
posthog.capture(
    '$pageview',
    distinct_id='user_id',
    properties={
        '$feature/new-checkout-flow': variant
    }
)

# Later, send metric events as usual - no variant property needed
posthog.capture(
    'purchase_completed',
    distinct_id='user_id',
    properties={
        'revenue': 99.99
    }
)

// Get variant from your feature flag system
$variant = $yourFlagSystem->getVariant('new-checkout-flow');

// Send exposure event
PostHog::capture([
    'distinctId' => 'user_id',
    'event' => '$pageview',
    'properties' => [
        '$feature/new-checkout-flow' => $variant
    ]
]);

// Later, send metric events as usual - no variant property needed
PostHog::capture([
    'distinctId' => 'user_id',
    'event' => 'purchase_completed',
    'properties' => [
        'revenue' => 99.99
    ]
]);

// Get variant from your feature flag system
variant := yourFlagSystem.GetVariant("new-checkout-flow")

// Send exposure event
client.Enqueue(posthog.Capture{
    DistinctId: "user_id",
    Event:      "$pageview",
    Properties: posthog.NewProperties().
        Set("$feature/new-checkout-flow", variant),
})

// Later, send metric events as usual - no variant property needed
client.Enqueue(posthog.Capture{
    DistinctId: "user_id",
    Event:      "purchase_completed",
    Properties: posthog.NewProperties().
        Set("revenue", 99.99),
})

How PostHog processes experiment events

Understanding how PostHog calculates experiment results can help you debug issues and ensure your implementation is correct.

Exposure tracking

When you send your custom exposure event (e.g., $pageview), PostHog's exposure query:

1. Filters for events matching your configured exposure event name
2. Extracts the variant from the $feature/<flag-key> property
3. Records the user's first exposure timestamp per variant
4. Generates daily exposure counts for each variant

Metric calculation

For each metric event:

1. PostHog checks if the user was exposed to the experiment
2. Verifies the metric event occurred after their first exposure (and within the conversion window, if set)
3. Attributes the event to the variant the user was exposed to
4. Includes it in the experiment results

Metric events are matched to users through their exposure, so they don't need the $feature/<flag-key> property.

Multiple variant handling

If a user is exposed to multiple variants, like when a user jumps across devices, PostHog handles this based on your exposure criteria settings:

• Exclude from analysis (default): Users seeing multiple variants are removed from results
• Use first seen variant: Users are attributed to their first exposed variant

Sample ratio mismatch detection

PostHog automatically checks if your exposure distribution matches your configured variant split using a chi-squared test. Once your experiment reaches at least 100 total exposures, PostHog calculates whether the actual distribution differs significantly from expected. If it does (p < 0.001), you'll see a sample ratio mismatch warning.

This helps catch implementation issues like:

• Inconsistent variant assignment logic
• Events not being sent for certain variants
• Ad blockers or network issues affecting specific user groups

Common issues

Events not appearing in results

Problem: You're sending events, but they're not showing up in experiment results.

Solution: Verify that:

• Your custom exposure event is being sent (the event you configured in Step 3)
• Your exposure events include the $feature/<flag-key> property with the correct variant value (metric events don't need it)
• Metric events occur after the exposure event (PostHog ignores pre-exposure events)
• Property values on the exposure event exactly match your experiment's flag key and variant names (including capitalization)

Exposure count is lower than expected

Problem: Fewer users are being counted as exposed than you expect.

Solution: Check that:

• Your custom exposure event is firing for all users who see the experiment
• The $feature/<flag-key> property contains a valid variant name
• You're not filtering out users with test account filters
• Events are successfully reaching PostHog (check for network issues or ad blockers)

Uneven variant distribution

Problem: Variants don't match your configured split percentages.

Solution: Ensure:

• Your feature flag system is correctly implementing the variant split
• You're assigning variants consistently per user (not randomly on each evaluation)
• The $feature/<flag-key> value matches the variant names in your experiment setup
• You haven't changed the variant split mid-experiment