Metric

A metric is computed from one or more registered source tables (Fact Tables) under Data Management → Tables. A single metric can bind multiple Fact Tables, which lets one metric span events that live in different tables — for example, combining an ad-revenue Fact Table with an IAP Fact Table to compute total revenue per user.

The Create a New Metric form

Click Create in the Metrics Catalog to open Create a New Metric. It has two sections.

1. Basic Information

• Name — letters, numbers, and underscores only.
• Description (Optional) — e.g. "the number of unique users per day".
• Metric Group — the group the metric belongs to.
• Metric Type — a radio choice between Non-MAB Experiment (default) and MAB Experiment. This selects which experiment family the metric is built for; it is not the aggregation. The aggregation is Field Aggregation in the next section.
• Owner — defaults to the signed-in user.

2. Metric Configuration

• Select Source Table — the registered Fact Table(s) the metric reads from. Bind a single table when the events live in one place; bind multiple Fact Tables when the metric definition spans events across tables.
• Field Aggregation — how user-level values are aggregated. The options are the metric types (Average, Sum, Ratio, User Count, …).
• Filter by Field Aggregation — restrict the rows that count toward the metric.
• Formula — combine aggregated terms; the term A defaults to Participations of the Experiment.
• Advanced — Expected Direction, Numeric Format, Decimal Unit, Conversion Factor, Metric Unit (Optional), Minimum Detectable Effect Threshold, and Delayed Calculation.
• Metric SQL — the SQL the configuration compiles to.

Multiple source tables

When a metric binds more than one Fact Table, each table contributes its rows to the same metric formula. Use this when the underlying events are split across tables (for example, ad-revenue events and IAP events stored separately) and you want a single metric on top of both.