When to freeze a cohort for payback review (and when not to)

A payback argument that quietly changes which days are still “open” for late revenue is not a measurement debate — it is a definition rewrite. Freeze the cohort on a written rule before the review, and record when the freeze does not apply.

What the freshness docs actually freeze

AppsFlyer data freshness (body-read 20 September 2026) states that for People-Based Attribution (PBA), during the first seven days after conversion PBA may identify additional events and change KPIs and media-source attribution retroactively; after seven days, the paths are frozen. Raw data includes a final_data field that is true when data is final. SKAN postbacks received on a given day are processed at end of day UTC and are available by 10:00 UTC the following day. Continuous (near-real-time) attribution updates with a typical 15–60 minute lag.

Operator freeze checklist

1. Write the freeze horizon in the review brief (for example: D7 cash ROAS frozen at D7+2 UTC after last late SKAN window of interest).
2. Do not freeze while continuous pipelines are still backfilling the same install day without a documented lag allowance.
3. For PBA-style web paths, treat day 0–7 as mutable unless final_data says otherwise.
4. Never reopen a frozen cohort to absorb a creative win without logging a definition change.

Facts vs limits

Download the freeze card.

Draft prepared 20 September 2026. Local expansion-500 file; human editorial review pending. No CMS write.