Metrics + mappings

The metric library

Metrics live in Settings → Metrics and are shared across every integration. A metric has a name (Mobile checkout conversion), a unit (percent / decimal / integer / currency), and optional description. The name is the canonical handle — it's what appears in bets, outcome verdicts, and the audit log.

Metrics are integration-agnostic. One metric can be mapped to PostHog on one workspace and Amplitude on another, or to both simultaneously with the Amplitude mapping taking priority for Amplitude-connected projects. Swapping the underlying query never changes the metric name.

Adding a mapping

1. Settings → Integrations → Amplitude tile → Add metric mapping
2. Pick the metric from the dropdown (or create a new one inline).
3. Choose a binding kind — the five kinds are described below. Fill in the kind-specific parameters.
4. Click Save. The mapping is active immediately; the next outcome-sweep cron that encounters a bet using that metric will pull from Amplitude.

A metric can have at most one active Amplitude mapping. Editing an existing mapping replaces it in place — the mapping ID stays the same so outcome history remains linked.

Event kind

The most common binding. Pulls a numeric aggregate of a single Amplitude event over a time window.

• Event name — the Amplitude event name exactly as it appears in your taxonomy (e.g. complete_checkout). Case-sensitive.
• Aggregation — how to aggregate the event count. See the next section for full details.
• Filters (optional) — event-property filters to narrow the query. Format: property = value pairs, AND'd together.

Aggregations

The Event kind supports five aggregation modes. The first two are always available; the last three require a numeric event property.

• Count events — total event occurrences in the window. Maps to Amplitude's totals segmentation metric. Use for "how many times did X happen."
• Unique users — distinct users who fired the event at least once. Maps to uniques. Use for "how many people did X."
• Sum — sum of a numeric property across all event occurrences. Requires a property name field (e.g. order_value). Use for revenue, session duration totals.
• Average — arithmetic mean of a numeric property. Requires property name. Use for average order value, mean page-load time.
• Percentile — p50 / p75 / p90 / p95 / p99 of a numeric property. Requires property name + a percentile selection. Use for latency budgets, tail-latency metrics.

Chart kind

Bind a metric to a saved Amplitude chart by its chart ID. Findry pulls the chart's primary numeric result at measurement time — no need to re-specify event parameters that are already captured in the chart.

• Chart ID — the alphanumeric ID from the Amplitude chart URL. A URL like https://app.amplitude.com/analytics/acme/chart/abc12345/ has chart ID abc12345.

Chart mappings return a single number (the chart's primary metric) and do not support time-series baseline computation. If the outcome's bet has no explicit baseline override, Findry falls back to the manual-baseline input on the outcome form.

Good fit for: teams that already curate canonical metrics as named Amplitude charts. Swapping the chart definition in Amplitude automatically changes what Findry measures next run.

Funnel kind

Define an inline multi-step funnel and bind the conversion rate at any step as the metric value.

• Events — 2 to 10 Amplitude events in order. Each step must be an event name; optional event-property filters per step.
• Target step — which step's conversion rate to use. Defaults to the last step. Step 1 is the entry event (always 100%); step 2 through N are the conversion percentages.

Funnel computation calls Amplitude's POST /api/2/funnels endpoint with an ordered event array. Findry computes step[N].count / step[0].count × 100 and returns the percentage.

Cohort size kind

Bind a metric to the size (user count) of an Amplitude Behavioral Cohort. The metric value is the number of users currently in the cohort at measurement time.

• Cohort ID — from the Amplitude cohort URL. A URL like https://app.amplitude.com/analytics/acme/cohort/xyz789/ has cohort ID xyz789. Alternatively, pick from the cohort dropdown (populated from GET /api/3/cohorts).

Good fit for: "how many users are in the at-risk churn cohort," "how many users qualify for the premium tier cohort" — absolute membership-size metrics rather than event rates.

Template kind

Pre-built query shapes for the most common metric patterns. You supply event names; Findry builds the Amplitude query for you.

Three templates are available:

• Activation rate (activation_rate) — percentage of signed-up users who completed an activation event within a window. Parameters: signupEvent, activationEvent, withinDays (default 7).
• Week-2 retention (week_2_retention) — percentage of users who came back in days 7–14 after their first event. Parameters: firstEvent (the event that marks "day 0").
• Feature adoption rate (feature_adoption_rate) — percentage of active users who fired a feature event in the last N days. Parameters: featureEvent, windowDays (default 30).

How outcomes compute

When the outcome-sweep cron runs (daily at ~07:00 UTC), for each open outcome with an Amplitude mapping:

1. Findry pulls the metric for the baseline window — the period before the bet's ship date. Window length is the same as the post-ship window (defaults to 30 days; configurable on the outcome form).
2. Findry pulls the metric for the post-ship window — from ship date to now (or to the outcome's measurement end date if set).
3. Findry computes the absolute and relative delta, then runs a z-test against the null hypothesis of no change. If p < 0.05 and the direction matches predicted impact, verdict is hit. If p < 0.05 and direction is opposite, miss. If p ≥ 0.05, inconclusive.
4. The verdict is stamped on the outcome and an outcome.measurement_run audit event is written. If the Amplitude call fails, an outcome.measurement_failed event is written instead and the outcome stays open for the next run.

Chart kind mappings skip step 1 (no baseline pull) and fall back to the manually entered baseline on the outcome form if no ship date or baseline window can be computed.