Metrics¶

A Metric is something you want to measure. In FlagPal, metrics are used to track the outcomes of your Experiments — they tell you whether the variant you tested is actually making things better or worse.

Without metrics, an experiment is just a guess. With metrics, it's a scientific test with measurable results.

What Can You Measure?¶

Anything that can be counted or recorded can be a metric. Here are some common examples:

Metric Types¶

FlagPal supports three types of metrics:

Boolean (Yes/No)¶

Records whether something happened or not. The value is either true (happened) or false (didn't happen).

Example: purchase_completed — did the user complete a purchase?

How it's used: You should assume there are unique events/metrics that happened once during the users' flow. If a user who enters an experiment makes two purchases, this will be counted as two separate events. Therefore, it's entirely possible to record one Exposure Metric in the Experiment (like a click or session), but and have two Goal Metrics (purchase_completed or conversion).

Count (Number of Times)¶

Currently, very similar to the Boolean type. Records how many times something happened. The value is a whole number.

Example: cart_items_added — how many products did the user add to their cart?

Money (Revenue / Monetary Value)¶

Records a monetary amount. The value is an integer (whole) number.

Why an integer? Because the best practice is to always measure money cents to avoid mathematical rounding errors. Most currencies in the world have a decimal point, but some don't; therefore, it is best to use the smallest unit possible.

Example: purchase_revenue — how much did the user spend on this purchase?

How it's used: FlagPal applies formatting to the metric values for better readability in the dashboard.

How Metrics Connect to Experiments¶

Metrics are attached to Experiments to measure which variant wins. Here's the flow:

1. You create a Metric in FlagPal (e.g., purchase_completed)
2. You add the Metric to an Experiment
3. When users interact with your app, your app sends metric data to FlagPal (e.g., "User 1 entered the experiment of Variant A", "User 2 clicked a button in Variant B", "User 3 completed a purchase in Variant A", etc.)
4. FlagPal associates that metric event with whichever experiment variant the user was in
5. FlagPal shows you the results per variant

Creating Metrics¶

Metrics are managed in the Metrics section of the sidebar. To create a metric:

1. Go to Metrics in the sidebar
2. Click New Metric
3. Give it:
4. Name — a clear, descriptive name (e.g., purchase_completed)
5. Description — what this metric measures and why (optional but helpful)
6. Kind — Boolean, Count, or Money

Step-by-step guide: Tracking Metrics →

Metric Data: How It Gets Into FlagPal¶

Metrics don't collect data automatically — your application needs to send metric events to FlagPal via the API. This can be configured in your Application via our SDKs or done by your development team.

When something measurable happens in your app (like a purchase), your app calls the FlagPal API to record it. FlagPal then attributes that metric event to the correct experiment variant based on which variant that user was in. In case the Metric is sent by your App but it isn't tracked in any Experiment, it will be ignored.

For non-developers: You don't need to worry about the technical details of how metric data is sent. Your developers handle that. Your job is to define the metrics in FlagPal and make sure they're attached to the right experiments.

Viewing Metric Results¶

See Reading Experiment Resulsts for more information about how metrics are analyzed. Here is a short overview:

Once an experiment is running and data is coming in, you can view results on the Experiment page. Usually you want to compare metric ratio (e.g., purchase_completed vs button_click_count) to see which variant is performing better. You can do so by selecting the Exposure Metric (like button_click_count) and the Goal Metric (like purchase_completed). The analytics dashboard will show you the ratio of the two metrics for each variant, the probability of each variant winning, and the statistical significance of the results.

This setup allows you to compare the performance of many different metrics in a single experiment and provide deeper insights into the effectiveness of each variant.

Example Results View¶

For a purchase_completed (Boolean) Goal Metric in a button color test, with a button_click_count (Count) Exposure Metric:

The Variant B button has a 5.01% conversion rate vs 2.97% for the Variant A button — a clear winner!

Best Practices for Metrics¶

Define Metrics Before You Run the Experiment¶

It's tempting to look at the results and then decide what to measure, but this leads to "cherry picking" — finding metrics that happened to look good by chance. Define your key metrics before you start the experiment.

Focus on Primary Metrics¶

Each experiment should have one primary metric that determines the winner. You can have secondary metrics for additional insight, but make the decision based on the primary one.

Use Meaningful Metrics¶

The metric should directly reflect the goal of the experiment. If you're testing a checkout redesign, the primary metric should be purchase completion rate — not something loosely related like page views.

Give Metrics Time¶

Metrics need time to accumulate enough data to be statistically meaningful. Don't cut an experiment short just because one variant looks like it's winning after a few days.

Related Concepts¶

• Experiments — where metrics are used
• Feature Flags — the features being measured
• Actors — the users generating metric data