Separating Resurrected Users from New Cohort Decay

A frequent scenario in mature mobile products: the growth team launches a promotional discount or seasonal push campaign. Monthly Active Users (MAU) spike by 25%, and leadership celebrates an apparent surge in retention.

Three weeks later, active users plummet back to previous levels. What happened?

The campaign did not improve the fundamental retention of new users. Instead, it triggered a temporary wave of resurrected dormant users—individuals who installed the app months or years ago, opened it for a single transaction, and promptly returned to their dormant state.

When analytics systems mix new installs, retained users, and resurrected users into single active metrics, product teams lose the ability to measure real product improvements.

The Four User State Classifications

In clean telemetry architecture, every active user on day (T) must be classified into exactly one of four mutually exclusive lifecycle states based on their historical activity:

1. New Users ((N_T)): Users whose first-ever verified application activation occurred on day (T).
2. Retained Users ((R_T)): Users active on day (T) who were also active in the immediately preceding observation window (e.g. active in the past 7 days).
3. Resurrected Users ((S_T)): Users active on day (T) who were completely inactive during the preceding observation window (e.g. 30+ days of silence) but installed the app prior to day (T).
4. Churned Users ((C_T)): Users active in the previous window who logged zero activity on day (T).

The Mathematical Accounting Identity

The total active user base at any time (T) is governed by the fundamental lifecycle identity:

$$\text{Active Users}_T = \text{New}_T + \text{Retained}_T + \text{Resurrected}_T$$

If you only measure the left side of the equation ($\text{Active Users}_T$), an increase in Resurrected users can easily conceal a dangerous collapse in Retained users.

Why Cohort Retention Must Exclude Resurrections

True cohort retention measures the survival rate of a specific group of new users ($N_0$) over elapsed time.

If a user from the January cohort drops out on Day 10 and reappears on Day 75 due to a push notification, they must be recorded as:

• Day 10: Churned.
• Day 30: Churned (not retained).
• Day 75: Resurrected event (analyzed separately in resurrection retention curves).

Allowing that user to retroactively count as a “Day 75 retained user” within the original January cohort corrupts the cohort curve, producing artificial bumps that make it impossible to evaluate whether product changes actually improved long-term engagement.

Recommended SQL Warehouse Architecture

To prevent state contamination, structure your event warehouse around a daily User Lifecycle State Table generated by a nightly dbt or cron job:

• Maintain a persistent last_active_timestamp per user_id.
• Compute days_since_prior_activity dynamically on each event date.
• Tag every event row with its instantaneous lifecycle state (NEW, RETAINED, RESURRECTED).

By decoupling resurrected spikes from organic cohort retention, your analytics infrastructure provides leadership with unambiguous signals regarding genuine product adoption.