Experiences¶
An Experience is how you deliver specific feature values to your users. It's the mechanism that takes a Feature Flag you've defined and applies it — turning it on, off, or setting it to a particular value for a specific group of users.
If Feature Flags are your light switches, an Experience is the instruction that says "turn this switch ON for these users."
What Is an Experience?¶
An Experience combines:
- One or more Feature Flags — the features you want to control
- The values those flags should have — what each flag should be set to
- Rules — who should receive this experience (optional, but almost always needed)
- Weight — what is the ordering priority of this experience (is it executed before or after another?)
When FlagPal evaluates which features to show a user, it checks which Experiences apply to that user and returns the corresponding feature values.
Experience vs. Experiment¶
It's easy to confuse Experiences and Experiments. Here's the key difference:
| Experience | Experiment | |
|---|---|---|
| Purpose | Roll out a feature | Test two+ variants |
| Variants | One (single set of feature values) | Two or more |
| Goal | Ship a feature to users | Learn which variant wins |
| Metrics | Not required | Required (to measure results) |
Use an Experience when: You want to turn a feature on for certain users, or roll out a feature gradually.
Use an Experiment when: You want to compare two versions of something and measure which one performs better.
A Real-World Example¶
Imagine you've built a new homepage design. You want to:
- Show the new design to all users who have signed up after January 1, 2024
- Show the old design to everyone else
Here's how you'd set this up:
- Create two Feature Flags:
new_design(Boolean type) andregisted_at(Date type). - Create an Experience that:
- Sets
new_design=true - Has a rule:
registed_atdate_after_or_equal2024-01-01(Only apply to users who signed up after 2024-01-01)
- Sets
- Users who match the rule get the new design; others get the default
This is a very simple example showcasing how to combine different Feature Flags. In practice, your application should be able to set the
registed_atvalue to the current date when a user signs up. It is entirely up to you what properties you define as feature flags and how you set this value.
The Components of an Experience¶
Name¶
A clear, descriptive name for this experience. Example: "New Homepage for 2024 Signups"
Description¶
An optional but helpful description of what this experience does and why.
Active Toggle¶
An Experience can be active (running) or inactive (paused). Toggle this to quickly start or stop the experience without deleting it.
WARNING: When you deactivate an Experience, your users will immediately stop getting those feature values and fall back to the defaults (or another matching experience). Users who have already received the feature flag values will continue to see it, if you're storing these values for users (default FlagPal SDK behavior)
Feature Set¶
The Feature Set is the collection of Feature Flag values that users in this Experience will receive. For an Experience, there is exactly one Feature Set — this is what makes it different from an Experiment, which has multiple.
Example Feature Set for an Experience:
homepage_design="new"show_promo_banner=truemax_products_shown=12
Targeting Rules¶
Rules check what value a feature flag must have for this experience to apply. If no rules are set, the experience applies all the time.
Rules are based on the Feature Flag values — any feature value that your app sends to FlagPal or was activated via Experiences, automatically carries over to the next Experience (or Experiment). This way, you can chain multiple Experiences to create multiple different branches for your users. For example:
- Feature Flag
countryequals"US"(provided by your app by setting this user propery as a flag in the SDK) - Feature Flag
subscription_planequals"premium"(also may be provided by your app) - Feature Flag
currencyequals"USD"(possibly resolved from a previous Experience that sets desired currency by a user'scountryflag).
This is useful when you want to target different groups of users, like optimize the experience for users in a specific country or plan.
Such flows that depend on previous user actions or decisions (like setting a user's currency based on their country, and then using that currency in subsequent experiences), are considered advanced.
Learn more about Targeting Rules →
Weight¶
Weight controls how important this Experience is when multiple Experiences could apply. A higher weight means it is higher up the chain and takes precedence.
Think of weight as the "priority" of this Experience. If multiple experiences match a user, the one with the highest weight wins.
How Experiences Work Together¶
You can have multiple Experiences in a project. When FlagPal evaluates which features a user should see:
- It checks all active Experiences, sorted by weight (highest first)
- It goes over each Experience and evaluates the targeting rules for it:
- It returns the Feature Flag values from the Experience, if the Rules pass. If not - it skips it.
- The Feature Flag values are carried over to the next Experience, where it checks the rules again.
- Once all Experiences have been evaluated, the final list of Feature Flag values are returned.
This lets you create layered experiences — for example, one experience for beta users, one for premium users, and one as the default for everyone else.
Creating an Experience¶
To create an Experience:
- Go to Experiences in the sidebar
- Click New Experience
- Give it a name and description
- Set the Feature Flag values (your Feature Set)
- Add targeting rules if needed
- Set the weight
- Toggle it active when you're ready
Step-by-step guide: Creating an Experience →
Related Concepts¶
- Feature Flags — the flags used in Experiences
- Experiments — similar but for A/B testing
- Actors — the users that targeting rules are based on