When to use this path
Choose this path when:- Your app sells through App Store Connect, Google Play, Stripe, or another accessible subscription source.
- You already use AppsFlyer or Adjust for attribution.
- You want CAC, ROAS, and payback reporting before changing app code.
- You want read-only recommendations before granting write access to ad platforms.
What this setup includes
| Source | Required? | What FloKit reads |
|---|---|---|
| Subscription source | Yes | Trials, activations, renewals, refunds, cancellations, customer IDs |
| Attribution source | Strongly recommended | Install source, campaign, ad set, creative, country, MMP customer user ID |
| Ad platform spend | Recommended | Spend, budgets, bids, campaign metadata |
| Product events | Optional at first | Paywall views, onboarding milestones, offer interactions |
| Warehouse | Optional | Historical cohorts and finance-approved revenue |
Setup sequence
Create a production workspace
Create a workspace for the live app. Keep staging and QA data separate from production.
Connect subscription revenue
Connect App Store Connect, Google Play, or Stripe. Confirm FloKit can read trials, subscription starts, renewals, refunds, cancellations, and customer identifiers.
Connect attribution
Connect AppsFlyer or Adjust. Confirm install attribution, campaign source, ad set, creative, country, and customer user ID are available.
Map identifiers
Confirm how subscription customer IDs map to app user IDs and MMP customer user IDs. This is the most important step for trustworthy campaign-level reporting.
Import or connect spend
Connect ad platform spend or provide a spend export. Without spend, FloKit can show revenue and conversion quality but cannot calculate CAC payback.
Review data quality
Check source health, sync status, missing IDs, missing campaign metadata, and unattributed users before reviewing payback.
Read the first report
Review cohort sizes, CAC, ROAS, LTV, and payback windows. Compare against your MMP and subscription source.
Minimum data requirements
| Requirement | Why it matters |
|---|---|
| Stable customer identifier | Connects revenue to users and cohorts |
| Attribution user identifier | Connects users back to campaign source |
| Subscription timestamps | Defines cohort membership and renewal windows |
| Revenue amount and currency | Calculates LTV, ROAS, and payback |
| Spend by campaign or ad set | Calculates CAC and payback by acquisition source |
| Refund and cancellation events | Keeps revenue quality realistic |
Validation checklist
- Revenue totals are within the agreed tolerance of the subscription source.
- Campaign and ad set names match the MMP or ad platform.
- Paid cohorts have cost data for the same reporting window.
- Unattributed users are explainable and not unexpectedly high.
- Refunds and cancellations are included in net revenue rules.
- Currency conversion rules are documented.
- The first report is reviewed before recommendations are used.
Common mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Connecting attribution before revenue | Reports show installs but not payback | Connect revenue first |
| Mixing sandbox and production data | Payback is inaccurate | Separate workspaces |
| Ignoring ID joins | Paid cohorts look unattributed | Map IDs before decision-making |
| Missing spend | CAC and payback cannot be calculated | Connect ad spend or import cost data |
| Acting on the first sync immediately | Data gaps become spend decisions | Validate source health first |
When to add events
Add server-side events when you need to answer questions like:- Which onboarding step predicts retained revenue?
- Which paywall variant has better payback, not just conversion?
- Which offer drives renewals after the first billing period?
- Which lifecycle behavior predicts churn or refund risk?