Skip to main content

​
Introduction

AppsFlyer Cohort is a measurement connector for cohorted retention and revenue analysis, currently in beta. It is built on AppsFlyer’s Cohort analytics via Data Locker feature: AppsFlyer writes daily cohort_unified CSV exports (gzip-compressed) into an Amazon S3 bucket the customer controls, and the connector reads them on a schedule, parses day-N cohort metrics, and serves the aggregated results from a per-data-source cache. The data is cohorted, meaning each row anchors to a cohort date (install date or event date, depending on alignment) and reports activity at fixed day-offset checkpoints. Cohort retention curves, post-install revenue, and lifetime-value-by-day analysis all come from this connector. Non-cohort install totals, in-app event totals, cost, and ROAS come from the standard AppsFlyer connector, which reads the AppsFlyer Master API directly and differs entirely in authentication, data source, schema, and refresh strategy. As a measurement connector, events, breakdowns, and currencies are standardized so widgets can aggregate across sources without additional configuration. Revenue is stored and reported in USD only, so this connector does not perform currency conversion. To connect this data source, see How to connect AppsFlyer Cohort to Adriel.

​
Data refresh strategy

​
Architecture data

Architecture covers the app inventory and the auto-discovered event catalog. At connection time, the most recent CSV file in the configured S3 directory is read to populate the app picker and the discovered event-name list. The chosen app, cohort alignment, report template, extra breakdowns, and enabled events are stored per data source.

​
Reports data

Cache-only. Report data is served from a per-data-source Postgres cache table (appsflyerCohort_{assetId}). Dashboard queries read this cache, never S3 directly. Refresh schedule. The cache refreshes twice daily at 05:15 and 15:15 UTC. Each run scans the S3 directory for new date-named subfolders, parses any unprocessed gzip CSV files, and upserts day-N cohort rows for every data source under the connection. The refresh strategy is upsert — new files are merged into the existing cache rather than replacing all rows. Concurrency and retries. Worker concurrency is 1 and group concurrency is 1, so a single connection processes serially and never issues parallel S3 reads. Failed runs retry up to 10 times with a fixed 3-minute backoff. If AppsFlyer’s export has not landed by sync time, it is picked up on the next run, so the worst-case lag between an event occurring and it appearing on a dashboard is roughly 12 hours.

​
Architecture levels

App → Media source → Campaign → Ad set → Ad The active hierarchy depends on the chosen report template (App, Campaign, Ad Set, or Ad). The App report exposes app-level data only; the Ad report exposes the full campaign, ad set, and ad hierarchy. See the Breakdowns section for how the template affects available breakdowns.

​
Cohort model

Cohort data is organized around a cohort anchor date and a set of fixed day-offset checkpoints called cohort periods. Cohort periods. Exactly 11 cohort periods are supported: D0, D1, D3, D7, D14, D30, D45, D60, D90, D180, and D360. Every enabled event produces its metrics at each of these periods. Periods between checkpoints (for example D31 through D44) are not reported individually; activity in the gaps accumulates into the cumulative Total* series at the next checkpoint. The period set is fixed to keep the connector stable; other periods require a request to Adriel support. Point-in-time vs cumulative. For each period N, point-in-time metrics (Count, Users, Revenue) report activity that occurred on day N of the cohort. Cumulative metrics (TotalCount, TotalUsers, TotalRevenue) report the running sum from cohort day 0 through day N. Cohort period 0 stores only point-in-time metrics; the Total* variants begin at D1. Cohort alignment. Each data source is pivoted by one of two anchor dates. With conversion-date alignment, a row’s date is the install/conversion date and period 0 reflects activity on that same day — best for retention curves and lifetime-value-by-day. With event-date alignment, a row’s date is the event date and the period reflects how long after install the event occurred — best for time-of-event analysis. Most teams use conversion-date alignment. Attribution windows. Attribution-window logic is configured at the AppsFlyer account level, not in this connector. Cohort exports already reflect the windows set for the app in AppsFlyer Data Locker; each row carries a cohort anchor date and post-anchor offsets rather than discrete click/view windows.

​
Metrics

How to read the columnsData type uses this vocabulary: Number, Currency, Percentage, Ratio, Duration, Date, Text, URL, Array, Boolean.API Key in code style like {eventName}Count(dN) is the connector field pattern, where {eventName} is an enabled event and N is one of the 11 cohort periods. Italic text describes how a value is produced when it is derived rather than read directly from the export.
Cohort metrics are generated per enabled event and per cohort period. At data source creation, 29 common AppsFlyer event names are pre-filled (such as purchase, registration, and tutorial completion), and custom event names can be added. Events discovered in the export but not on the enabled list are recorded but not exposed as metrics until explicitly added.

​
Cohort retention metrics

Retention rate is computed by Adriel per cohort period and appears automatically without configuration, because the events it depends on are tracked by every AppsFlyer app.

​
Cohort event & user metrics

​
Cohort revenue & LTV metrics

All revenue is stored in USD; the connector does not convert to the workspace currency.

​
Breakdowns

Available breakdowns depend on the selected report template. The App report exposes app-level breakdowns only; Campaign, Ad Set, and Ad reports progressively add campaign, ad set, and ad breakdowns. media_source is unavailable on the App report; agency and install_app_store are unavailable on the Ad Set and Ad reports.

​
Attribution & structure

​
Geography & install source

​
Limitations

  • Fixed cohort periods. Only the 11 periods D0, D1, D3, D7, D14, D30, D45, D60, D90, D180, and D360 are available; intermediate days are not reported separately. Other periods require a request to Adriel support.
  • USD-only revenue. Revenue is stored and reported in USD only and is not reconverted. For local-currency revenue, use the standard AppsFlyer connector.
  • Export latency. Because the cache syncs twice daily and depends on AppsFlyer’s export landing in S3, dashboard data can lag an event by up to roughly 12 hours.
  • Auto-discovered events are gated. New event names appearing in the export are recorded but are not exposed as metrics until they are added to the data source’s enabled events.
  • One data source per app is recommended. Multiple data sources for the same app under one connection are possible but inefficient — a single refresh processes all of a connection’s data sources together, so duplicating an app multiplies processing cost without benefit.
  • No cost or ROAS. This connector carries cohorted retention and revenue only; installs totals, in-app event totals, cost, and ROAS come from the standard AppsFlyer connector.

​
API references

​
See also