In a trial/paid/churned chain with churn absorbing, how do you compute the expected months until churn?

## Absorbing chains A state is **absorbing** when `P[i][i] = 1`: once the chain enters it, it never leaves. A chain is an **absorbing chain** when it has at least one absorbing state and every other state can reach one. Non-absorbing states are called **transient**, because the chain leaves each of them permanently with probability 1. Order the states with transient ones first and absorbing ones last. Then the transition matrix splits into blocks: ``` P = [ Q R ] [ 0 I ] ``` `Q` holds transient-to-transient probabilities, `R` holds transient-to-absorbing probabilities, and the bottom rows say absorbing states stay put. Note that rows of `Q` sum to less than 1 for at least some states — the missing mass is the chance of being absorbed this step. ## The fundamental matrix Raising `P` to the `n`th power keeps the block structure with `Q^n` in the corner, and `Q^n -> 0` because absorption is certain. That makes the geometric series converge: ``` N = I + Q + Q^2 + Q^3 + ... = (I - Q)^-1 ``` `N` is the **fundamental matrix**, and `N[i][j]` is the expected number of visits to transient state `j` before absorption, starting from `i` (counting the starting visit). Summing across a row counts every transient step the chain takes, which is exactly the **expected time to absorption**: ``` t = N * 1 equivalently (I - Q) t = 1 ``` The second form is often easier by hand: it is one linear equation per transient state, and it encodes 'one step now, plus whatever the state you land in still costs'. ## Worked lifecycle example Monthly states `trial`, `paid`, `churned`, with `churned` absorbing: - `trial`: stay 0.5, `paid` 0.3, `churned` 0.2 - `paid`: stay 0.9, `churned` 0.1 Transient block and its complement: ``` Q = [ 0.5 0.3 ] I - Q = [ 0.5 -0.3 ] [ 0.0 0.9 ] [ 0.0 0.1 ] ``` The determinant is `0.5 * 0.1 = 0.05`, so ``` N = (I - Q)^-1 = [ 2 6 ] [ 0 10 ] ``` Reading it off: starting in `trial`, the user spends on average 2 months in `trial` and 6 months in `paid`, for **8 months total** before churning. Starting in `paid`, 10 months. The single-state check is reassuring: from `paid`, absorption happens with probability 0.1 each month, and the mean of that geometric count is `1 / 0.1 = 10`. It is worth noticing that 8 is less than 10. A trial user is not worse off than a paid user in some paradoxical sense — most trial users churn without ever converting, which drags the average lifetime down. ## Absorption probabilities With two or more absorbing states, the matrix `B = N R` gives `B[i][k]` = probability of eventually being absorbed in state `k` starting from `i`. To ask 'does a trial user ever convert?', make `paid` absorbing as well and recompute. Now the only transient state is `trial`, with `Q = [0.5]` and `R = [0.3, 0.2]`, so `N = 1 / 0.5 = 2` and ``` B = N R = [0.6, 0.4] ``` A trial user converts with probability 0.6 and churns without converting with probability 0.4. Intuition check: conditional on leaving `trial` in a given month, the split is `0.3 : 0.2`, i.e. 60/40 — the stay probability cancels out. ## Assumptions this model imposes A constant per-month transition probability out of a state means the time spent there is geometric, so the hazard of churning is flat: a user in month 2 of `paid` is exactly as likely to churn as a user in month 30. Real subscriptions almost never behave that way — churn spikes at onboarding and again at renewal. Two honest repairs: split the state by tenure (`paid-new`, `paid-renewed`, `paid-established`) so the hazard can vary across states, or move to a model that lets the sojourn time follow an arbitrary distribution. Also check whether `churned` is truly absorbing; if a meaningful share of users resubscribe, an absorbing state overstates how final churn is, and the answer becomes a long-run share question rather than an absorption question. ## Failure modes If some transient state cannot reach any absorbing state, absorption is not certain, `Q^n` does not decay, and `I - Q` is singular — a numerical blow-up that is really a modelling error. And keep the two outputs straight: row sums of `N` are **times** in months, while entries of `B` are **probabilities**. Reporting one as the other is the most common way this calculation goes wrong in a review.