> ## Documentation Index
> Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-axis cohort selection

> Five dimensions used to scope each migration wave: tenure, geo, engagement, renewal window, and plan. Tenure and engagement also drive the ongoing qualification trigger after the project.

Cohorts aren't picked at random. Each wave targets a slice of the eligible base defined on five axes, each tested individually during the pilot so migration cohorts can sequence based on what cleared.

## The five axes

<CardGroup cols={2}>
  <Card title="Tenure" icon="clock-rotate-left">
    How long the subscriber has been continuously paying. 12+ months on a renewal cycle behaves very differently from a 3-month new subscriber. Long-tenure cohorts often migrate at higher rates.
  </Card>

  <Card title="Geo" icon="globe">
    Primary markets vs secondary. Compliance and reachability vary by region; payment-method support varies (e.g., SEPA, Brazilian Pix). Sequencing by geo lets you start where the path is clearest.
  </Card>

  <Card title="Engagement" icon="chart-line">
    Quintiles of in-app activity. High-engagement subscribers are typically easier migrations (they care about the app); low-engagement subscribers carry more churn risk on any touchpoint.
  </Card>

  <Card title="Renewal window" icon="calendar-days">
    Time until next renewal. Subscribers near a renewal cycle tend to be more receptive — the renewal is on their mind. Longer-window subscribers can wait, and waiting compounds the recovery.
  </Card>

  <Card title="Plan" icon="layer-group">
    Annual vs monthly, premium vs basic, trial vs paid. Annual cohorts have different conversion mechanics than monthly (card-save vs early-charge); premium tier subscribers often have higher migration intent.
  </Card>
</CardGroup>

## How the axes get used

The pilot samples across all five axes at once — a stratified slice of the base with every cohort represented, each measured separately so response can be attributed per cohort rather than averaged away. Two to three waves build a per-cohort read before the program scales.

Migration waves then run stratified-parallel — every cohort starts in week one at a small allocation, and volume ramps wherever that cohort's benchmarks clear. Each wave's cohort spec tightens or widens based on what the prior waves showed.

## Ongoing qualification

The five axes scope the project-phase migration. After that, the migration extends itself: new mobile cohorts continue to qualify as they cross the same thresholds the pilot validated.

When a new cohort crosses the qualified band, the standardized migration sequence runs — branded email, web checkout that preserves the subscriber's existing economic terms, entitlement bridge — without per-cohort tuning. The thresholds were set during the pilot; new cohorts cross them as time and engagement accumulate.

## Why five and not more

There are more axes you *could* split on (signup source, device tier, language, billing currency, etc.). Five is the count where:

* The combinatorics stay tractable. Beyond five, the cohort space explodes and starves any individual cell of statistical power.
* The axes are independently meaningful. Tenure, geo, engagement, renewal window, and plan all carry distinct migration-rate signal. Adding a sixth typically correlates with one already on the list.
* The reporting fits on one screen. A wave summary that's one screen tall keeps the gating decision fast; a wave summary that scrolls is a slower decision.

If your app has a meaningful axis we haven't named (e.g., a critical signup-source split), it gets folded in during the Migration Review.

[Operational safeguards →](/framework/operational-safeguards)
