Tracking Metrics¶
Metrics let you measure what matters. This guide explains how to define metrics in FlagPal and how they connect to your experiments.
Overview¶
Metrics work in two steps:
- You define the metric in FlagPal — give it a name, description, and type
- Your app sends metric data to FlagPal via the API when something measurable happens
FlagPal then connects the incoming metric data to whichever experiment variant a user was in, so you can see how each variant performed.
Step 1: Navigate to Metrics¶
Click Metrics in the left sidebar.
You'll see the Metrics management page with a list of all metrics in your project.
Step 2: Create a New Metric¶
Click New Metric (or the create button).
Name (required)¶
Use a clear, descriptive name that explains what's being measured.
Examples:
purchase_completedbutton_clickedrevenue_generatedsignup_completedcart_abandoned
Description (optional but helpful)¶
Describe what this metric measures, when it fires, and what it means.
Example:
Records when a user successfully completes a purchase. Fired by the backend after payment processing succeeds. Excludes canceled or refunded orders.
Type (required)¶
Choose the metric type based on what you're measuring:
| Type | Use For |
|---|---|
| Boolean | Did it happen? (yes/no) |
| Count | How many times? |
| Money | How much revenue? |
Metric types are used for formatting the analytics results in the UI.
Step 3: Save the Metric¶
Click Create or Save to add the metric to your project.
Step 4: Attach the Metric to an Experiment¶
Metrics are used in Experiments. When creating or editing an experiment, look for the Metrics section and add your metric.
When you attach a metric, you can also choose which features it may be segmented by (see Segmenting Metrics by Features below). You can leave this empty for now and come back to it later using the metric's Features action.
Step 5: Your App Sends Metric Data¶
For the metric to collect data, your application needs to send metric events to the FlagPal API whenever the measured event occurs.
For non-developers You don't need to implement this yourself. If you're using our SDKs this can be easily configured by hooking into certain events in your application. With a custom codebase, share the metric name and type with your developers and tell them when it should fire (e.g., "send this event whenever a user completes checkout"). They'll handle the technical implementation.
When metric data is sent, FlagPal:
- Receives the metric event
- Looks up which experiment variant the metric was assigned to
- Records the metric value for that variant
- Updates the experiment results
Segmenting Metrics by Features¶
Sometimes a single number isn't enough — you want to know how conversions differ by country, locale, device, or any other feature you track. FlagPal supports this by letting a metric event carry one or more feature values alongside its value.
How to set it up:
- On the experiment's Metrics section, select the metric and open its Features action (or choose features directly while attaching the metric — see Step 4).
- Pick which features this metric may be segmented by. Only the features you select here can ever be used to break this metric's data down later.
How it works when data is sent:
- Your app includes feature values alongside the metric value (e.g.
country: "US",locale: "EN") — see the API documentation for the exact request format. - Feature values are only kept if the feature was enabled for that metric in step 2 above. Anything else is silently dropped.
- The metric value is always recorded, even if none of its features were kept. Enabling segmentation for a feature never causes data to be lost.
Note Segmented data is captured as soon as you enable a feature and start sending its values — this is the foundation for filtering and breaking down results by feature. Viewing results filtered by a specific feature in the Experiment Results UI is not available yet; historical data captured now will be usable once that's released.
Tip Only enable segmentation for features you actually plan to analyze eventually. Selecting a handful of relevant features (e.g. country, locale, plan tier) keeps this manageable; you can always come back and enable more later.
Viewing Metric Results¶
Once an experiment is active and data is coming in, click on the experiment to see results by variant.
Refer to the Experiment Results guide for more details.
Tips for Good Metrics¶
Be Specific About When the Event Fires¶
A metric is only useful if everyone on your team agrees on exactly when it should be recorded. Document this in the metric's description.
Vague: "Fires when a user buys something"
Precise: "Fires when the backend payment processor confirms a successful transaction, before any refund processing"
Avoid Double-Counting¶
Make sure your developers only send a metric event once per occurrence. If a user reloads a confirmation page, the metric shouldn't fire again.
Use the Right Type¶
- Use Boolean for one-time events (signup, first purchase, upgrade)
- Use Count for events that happen multiple times (page views, clicks, logins)
- Use Money for any monetary value
Create Metrics Before Starting Experiments¶
Define your metrics before you run the experiment. This prevents "moving the goalposts" — changing what you're measuring after you've seen early results.
A Complete Example¶
Scenario: You're running an experiment testing a new checkout flow and want to measure purchase success.
-
Create metric:
- Name:
checkout_started - Description: "Fires when a user begins the checkout flow."
- Type: Boolean
Tip: You can create an
experiment_startedmetric and attach it to all your experiments to avoid creating Exposure metrics for every use case.
- Name:
-
Create metric:
- Name:
checkout_purchase_completed - Description: "Fires when a user successfully completes a purchase through the checkout flow. Includes all payment methods."
- Type: Boolean
- Name:
-
Create metric:
- Name:
checkout_order_value - Description: "Records the total order value (in your currency) when a purchase is completed."
- Type: Money
- Name:
-
Attach all metrics to your experiment.
-
Fire
checkout_startedwhen a user begins their checkout process andcheckout_purchase_completedwithcheckout_order_value= [order total] when a purchase succeeds. -
Wait for data to accumulate and review the experiment results.
Related Guides¶
- Running an Experiment → — use metrics in A/B tests
- Creating a Feature Flag →