Activation funnels and merchant journeys

Start with the observations your app sends

Open Merchants → Custom events, select one app and an observation period, and inspect the stored event names, transport, reported origin and counts. The event count and distinct-name count are different. Events without an owned app scope are excluded from that app’s catalog; the legacy count is disclosed separately. No funnel is inferred automatically from event names.

Give a milestone a clear label, description, expected origin and an explicit list of safe scalar properties. Revisions are immutable. Existing funnels keep their pinned definition version when you revise a label or property list.

Create an activation funnel

1. Open Analytics → Activation, select the app and choose Create funnel.
2. Choose installation or a defined custom observation as entry. Choose a conversion window from 1–365 days.
3. Add 1–10 stages with clear labels. Each stage matches all or any of 1–5 requirements: a pinned custom milestone, an observed subscription event or a first positive collection. Custom requirements select reported origins and up to five exact scalar property conditions from the definition’s allowed keys.
4. Choose Requirements for cumulative setup requirements that may occur in any order, or Sequence when each stage must follow its predecessor. Requirements mode rejects a repeated requirement across stages. Sequence mode can repeat a milestone but needs distinct stored observations.
5. Save and open the report. Editing creates a new funnel version; a stale editor must reload before saving. Archiving hides the funnel from the active list while preserving historical versions.

Subscription evidence is an observed subscription lifecycle event. Collection evidence is an actual positive subscription/usage/one-time sale observation from the current transaction revision; a later refund does not erase that earlier milestone. Neither proves a feature was used successfully.

Select the entry cohort

The period selects entry times, not just events in that period. From and Through dates are inclusive UTC calendar dates in the dashboard; APIs use an inclusive from and exclusive to timestamp. The report can inspect later observations within each entry’s saved conversion window, up to query time.

Each merchant contributes the earliest eligible episode in the selected entry cohort. Later entries are counted as excluded episodes. Uninstall/deactivation or the next install closes an earlier episode. Pre-entry observations, observations at the conversion-window end and observations at a closing boundary cannot complete that episode. Open a merchant journey to distinguish an old completed installation from its reinstall. Choose Open episode to inspect a different entry within the same cohort, including two entries on one UTC day. Report aggregates still use the earliest eligible episode; selecting a contextual journey does not restate the funnel totals. Other episodes page separately; entries outside the cohort are labelled and require changing the cohort before inspection.

Understand the report

• Observed progress compares reached stages with the full entry cohort. It is evidence of stored matching observations.
• Transition rate compares reached stages with merchants that reached the preceding stage (all entrants for the first stage).
• Mature covered conversion includes only eligible journeys whose complete conversion window has elapsed, boundaries are verified, required source/deployment coverage spans the window and the episode did not close early. A zero denominator is unknown, not zero percent. Fewer than 10 mature covered journeys are marked as a small sample.
• Median elapsed time measures entry/preceding-stage completion to observed stage completion. It is not a causal effect estimate.

Click stage/state counts to inspect the same eligible merchant set. The report keeps its full counts while paging; the selected drill and CSV retain app, period and funnel version. Open a merchant’s App journeys to inspect available lifecycle/custom/collection facts, reported origins, safe properties, coverage reasons and other episodes.

Declare tracking coverage deliberately

In Custom events, add coverage for the exact milestone definition revision and origin using deployed-from time, optional through time and a release label. Select Create a declaration or an existing declaration to correct its interval, exact revision, origin or label. Set Through to close an ongoing interval when tracking stops; correction replaces that effective interval and rejects a stale edit. Historical milestone revisions remain selectable. These are owner declarations, not automatic deployment verification. Channel recency alone does not establish that every merchant emitted a milestone. Do not backdate coverage beyond the release you verified. Source history and collection checkpoints are displayed separately.

Limits and troubleshooting

A report is bounded to 10,000 selected journeys and 100,000 combined loaded facts. Overflow, a five-second calculation deadline or a recognized data-query timeout makes the report unavailable with a reason; partial totals are never shown as complete. Exports reject more than 10,000 rows. Discovery dates are bounded to 365 days; use smaller windows when necessary. A failed report load offers retry rather than a fabricated empty result.

Missing events may mean no emission, failed delivery, redaction, unsupported tracking or a genuinely unobserved step. Inspect event observability and backend events. Reports do not execute Flows, send messages or demonstrate revenue uplift. Read the same report through get_activation_funnel.