Skip to content

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:

  1. You define the metric in FlagPal — give it a name, description, and type
  2. 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_completed
  • button_clicked
  • revenue_generated
  • signup_completed
  • cart_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.

Running an Experiment →


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:

  1. Receives the metric event
  2. Looks up which experiment variant the metric was assigned to
  3. Records the metric value for that variant
  4. 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:

  1. 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).
  2. 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.

  1. Create metric:

    • Name: checkout_started
    • Description: "Fires when a user begins the checkout flow."
    • Type: Boolean

      Tip: You can create an experiment_started metric and attach it to all your experiments to avoid creating Exposure metrics for every use case.

  2. 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
  3. Create metric:

    • Name: checkout_order_value
    • Description: "Records the total order value (in your currency) when a purchase is completed."
    • Type: Money
  4. Attach all metrics to your experiment.

  5. Fire checkout_started when a user begins their checkout process and checkout_purchase_completed with checkout_order_value = [order total] when a purchase succeeds.

  6. Wait for data to accumulate and review the experiment results.