In a Cox model, how do you handle a covariate that changes mid-follow-up, such as an upgrade to premium?

## Why the standard layout is not enough A baseline Cox model attaches one fixed covariate vector to each subject. Plenty of real predictors are not fixed: a customer upgrades a plan, a user turns on a feature, a device changes firmware. Forcing such a variable into a single baseline value throws away when it changed and, worse, can invert the answer. ## Episode splitting The fix is mechanical. Represent each subject as a set of non-overlapping intervals `(start, stop, event, covariates)` covering their follow-up, cut at every moment a time-varying covariate changes value. A customer observed from day 0 to day 200 who upgrades to premium on day 60 and cancels on day 200 becomes: - `(0, 60, event = 0, premium = 0)` - `(60, 200, event = 1, premium = 1)` The event indicator is 1 only on the interval that actually ends in the event. Every other interval ends because the covariate changed, not because anything happened to the subject. This is not a way of turning one subject into two independent subjects. The partial likelihood is built from risk sets at event times, and each interval simply declares which risk sets the subject belongs to and with what covariate value. At an event on day 45 the customer appears with `premium = 0`; at an event on day 120 they appear with `premium = 1`. The exponentiated coefficient is then read as the hazard ratio between being premium right now and not being premium right now, comparing subjects at the same follow-up time. ## The trap: immortal time bias The tempting shortcut is to label a customer premium for their whole observation because they upgraded at some point. This is wrong in a specific, predictable direction. To upgrade on day 60, the customer had to still be a customer on day 60 — those first 60 event-free days are guaranteed by the definition of the group. Assigning them to the premium arm donates risk-free time to premium and makes upgrading look protective even if it does nothing at all. The interval layout removes the bias by construction, because the first 60 days are correctly attributed to the non-premium state. ## Time-varying covariate versus time-varying coefficient These are routinely confused and interviewers probe the distinction. - A **time-varying covariate** is a value `x(t)` that changes while the coefficient `b` stays fixed. The hazard is `h0(t) * exp(b * x(t))`. Proportionality in the usual sense is not violated; the comparison is simply between current states. - A **time-varying coefficient** is `b(t)` — the effect itself strengthens or fades with follow-up time, which is the proportional-hazards violation, modelled by interacting a fixed covariate with a function of time. Saying the words correctly is half the answer. ## What gets harder **Prediction.** With a fixed covariate you can draw a survival curve for a profile straight away. With `x(t)`, a survival curve requires the whole future covariate path, which you do not have at prediction time. Two common responses: model the covariate process as well, or use a landmark analysis — pick a landmark time, keep only subjects still under observation then, freeze their covariate state as of that moment, and model survival forward from there. **Interpretation of the covariate itself.** If the covariate can react to the subject's evolving state — a customer who is already disengaging is less likely to upgrade — then the current-state comparison is on shaky ground, and the interval layout fixes the bookkeeping without fixing that. **Data plumbing.** The splitting has to be exact. Intervals that overlap, gaps in coverage, or a covariate value recorded slightly after the change point are all silent errors that no diagnostic will catch. Reconcile the total person-time before and after splitting as a sanity check. ## The short answer Split at the change point, carry the value that was true in each interval, put the event on the last interval only, and never backdate a state the subject did not yet have.