Skip to main content
Kairos needs signal to make good decisions. Recurr does not need to replace your analytics stack. It needs enough clean subscriber and cohort signal to decide who is ready, what path they should see, when to follow up, and whether the program should scale.

​
What Recurr reads

The exact sources depend on your stack, but useful signals often come from:
  • Product analytics
  • RevenueCat, Adapty, Stripe, Paddle, Firebase, or a custom access model
  • Your warehouse or reporting layer
  • Payment rail events
  • Recurr subscriber surfaces, including email, checkout, billing, and help

​
Signals that matter

Useful migration signals include:
  • Subscriber tenure
  • Plan, price, and billing period
  • Current billing rail
  • Renewal timing
  • Product engagement
  • Prior support or billing friction
  • Store-cancellation state where relevant
  • Checkout and payment outcomes
Not every program needs every signal. The pilot scopes the minimum useful signal set for the first cohorts.

​
Protecting LTV models

Recurr does not overwrite the original acquisition cohort when a subscriber migrates. Migration is tracked as a lifecycle event on the subscriber: when they were eligible, when they were offered a path, whether they moved, what offer path they saw, and what rail they now renew on. That lets finance and data teams separate underlying subscriber quality from migration effect. The model can account for migration probability and web-book economics without poisoning historical LTV curves or treating migrated subscribers as a new acquisition cohort.

​
How signals inform Kairos

Kairos uses approved signal inputs to inform decisions such as:
  • Which subscribers should move now
  • Which subscribers should wait
  • What offer framing or message path should be used
  • When follow-up should happen
  • Whether the next cohort should scale, pause, or adjust
  • Which lifecycle motion should run after migration
The decisioning loop is only useful if it connects to real subscriber outcomes: movement, payment, support signal, churn risk, recovery, upgrade, and future retention.

​
What your team provides

Before the pilot, Recurr usually needs:
  • The subscriber identifier that ties systems together
  • The sources that define subscription state
  • The events or fields that indicate engagement and billing state
  • Access to the reporting source or export path needed for cohort selection
  • A technical owner who can confirm the data shape
Recurr turns that into the working signal map for the Migration Hub and pilot.