AppsFlyer reporting for fintech apps: the KPIs that actually matter

Fintech UA has a reporting problem disguised as an attribution problem: the metrics that matter — purchases, subscriptions, completed checkouts — live deep in the funnel as in-app events, while the easy numbers (installs, CPI) are nearly meaningless for the business. This guide is AppsFlyer reporting built around fintech's real KPIs, with the event taxonomy, the funnel staging and the compliance-friendly mechanics.

The KPI stack that matters

Installs → registrations → checkout completed → purchase → repeat purchases. Spend efficiency is judged at the purchase stage: cost per purchase is the real CAC. CPI exists only as a top-of-funnel diagnostic — a report that leads with CPI is reporting the wrong business.

The event taxonomy, named precisely

Everything downstream depends on event names being exact and stable: registration_completed, checkout_started, checkout_completed, purchase_completed, first_purchase — whatever your app fires, written in the definitions block character-for-character. These are event-counter KPIs, which means the AppsFlyer Raw Data Pull API (event-level rows, deduplicated per user), not aggregate exports that count rows.

Funnel timing is a reporting decision

checkout takes minutes; repeat purchase takes longer. A cohort acquired this week hasn't had time to mature — so purchase columns need the same maturity discipline as ROAS: count by install cohort, label young cohorts as maturing, and never compare a 3-day-old cohort's purchase rate to a settled one. Conversion-rate panic is usually just impatience with the funnel's clock.

A run you could schedule

1. Last full ISO week, app timezone
2. Master API: spend and installs by campaign/geo
3. Raw Data Pull API: the purchase events, deduplicated per user, by campaign/geo/install-cohort
4. Filters as stored: market geo (e.g. geo = US), campaign prefix (US_), re-engagement excluded
5. Cost per purchase computed per market; maturing cohorts labeled
6. Platform spend reconciled; previewed append; summary with per-market flags

"Update the weekly acquisition report with spend by channel and purchases from AppsFlyer, and flag any market where cost per purchase rose more than 15%."

Multi-market reporting, specifically

Multi-market apps report per market — and markets are implemented as geo + prefix discipline. US_ campaigns, geo = US, the US tab; same structure per market, each on its own row of the schedule. The discipline that makes this automatable is naming: one unprefixed campaign pollutes a market's CAC silently.

Compliance-friendly mechanics

Fintech reporting changes get audited, so the write model matters: append-only updates (history immutable), full audit logs of what was written from which pulls, per-entity isolation, and least-privilege access — view to map, edit only on the report file. These properties (the safety model) are why automation is more defensible than ad-hoc manual edits, not less.

QA checklist

• ✓ Event names verified against a raw pull — exact strings, not approximations
• ✓ One market's purchase count recomputed from raw rows with dedup
• ✓ Maturity labels on young cohorts confirmed
• ✓ Prefix coverage audited — every active campaign carries its market prefix

When not to automate

While the event taxonomy is still being renamed by the app team. Stabilize the events (and get a deprecation policy), then schedule.

How Opera runs it

This is the fintech industry setup on Opera: both AppsFlyer APIs at the right grain, market filters stored per report, maturity handled, every write previewed and logged.