MSD0055 Netflix Watch Pause Prediction

Build a system that predicts whether a Netflix user stopped watching a show because they are tired of it or just taking a break, using a deep sequence model. When a user stops a show mid-episode or mid-season, Netflix must distinguish between two very different states: a user who is bored or dissatisfied and is likely to churn, and a user who simply went to bed or to work and will resume tomorrow. The distinction drives different actions: a bored user needs a new recommendation or a nudge, while a sleeping user should be left alone.

The system must model the user’s entire viewing history as a sequence (what they watched, when, for how long, where they stopped, whether they resumed), account for time-of-day and day-of-week patterns (stopping at 11 PM on a Tuesday is different from stopping at 3 PM on a Saturday), handle shows with naturally slow episodes that cause legitimate pauses, and predict the probability of resumption within 24 hours. The label is inherently ambiguous, because you only observe whether the user resumed, not why they stopped, so the system must infer intent from behavioral patterns.

How would you design this system? Cover the sequence model architecture (RNN/LSTM vs Transformer vs temporal convolution), the feature engineering from viewing history (session patterns, completion rates, time gaps, device switches), how you handle the label ambiguity (resumption as a proxy for interest, survival analysis for time-to-resume), how you distinguish seasonal pause patterns from genuine disengagement, and how you evaluate the system when ground-truth intent is never observed.

Line-art scene: a viewer on a couch with a remote, a phone and tablet nearby, in front of a TV paused at 31:07 of a 45-minute episode, a clock reading 11:04 PM Tuesday, and a question mark pointing to two outcome cards: just a break with a moon icon and a play button, or tired of it with an exit door icon and a warning triangle

The Problem: the same paused screen at 11 PM can mean “back tomorrow evening” or “never again”, and the platform only ever observes which one happened, never why. Design the model that reads the viewing history and tells the two apart before the 24 hours are up.

Answer

The design is a survival model over stop events: every time a user stops watching a title, a compact causal transformer reads the last few hundred play/stop events plus the stop-time context and outputs hourly resumption hazards over the next 24 hours, from which the probability and the expected time of resumption both fall out. Three decisions carry the design. First, the label is time-to-resume, not a binary “resumed or not”, so a user who resumes at 8 PM the next day and a user who never returns are separated by the shape of the curve rather than by a single threshold. Second, the model sees the stop relative to the user’s own habits and the title’s own pacing: a stop at 11 PM by a habitual 11 PM stopper, at an episode where 40% of the cohort also paused, is scored as ordinary. Third, the prediction is decoupled from the action: a calibrated probability feeds a nudge policy that is evaluated against a permanent randomized holdout, because intent is never observed and only downstream behavior can validate the system.

(1) Event-Level Sequence Tokens: each play/stop event becomes one token carrying title, device, local hour, weekday, watched fraction, stop position (mid-scene, before credits, autoplay cancelled), and gap to the previous event; the last 512 tokens form the input.
(2) Survival Head Over 24 Hourly Bins: a discrete-time hazard head predicts h_k for each hour, giving P(resume within 24 h) and the resume-time distribution in one pass, with a second 7-day horizon for weekend-only viewers.
(3) Habit and Pacing Normalization: the stop is described by its deviation from the user’s typical stop hour and typical gap duration and by the cohort drop-off curve at that episode, so seasonal and slow-episode pauses stop looking like boredom.
(4) Compact Causal Transformer: 4 layers at width 128 over 512 tokens, about 1 GFLOP per stop, with a GRU as the cheap fallback and a GBDT on aggregate features as the baseline everything must beat.
(5) Decoupled Action Policy: the model emits calibrated probabilities; a separate policy decides “leave alone”, “reorder the homepage”, or “nudge tonight” using the cost asymmetry between annoying a sleeper and losing a bored member.
(6) Randomized Holdout by Design: a permanent no-action slice keeps labels uncontaminated by the nudges and is the only place where “did we read intent right” can be measured.

Pipeline: playback telemetry stop events flow into a history store with event tokens, habit baseline and title pacing prior, then into a transformer encoder with survival head that outputs hourly hazards and P(resume 24h), then into an action policy that either nudges or leaves the user alone; an offline training box feeds the model and a dashed feedback loop returns observed resumption from the no-action cohort

Figure 1: The end-to-end path: one scored stop event, one calibrated resumption curve, one policy decision, and a no-action feedback loop that keeps the labels honest.

Clarify Before Designing:
(1) Action and Timing: what does the prediction drive, a homepage reorder at the next app open or a same-evening push notification, and how quickly after the stop must the score exist?
(2) Label Definition: is “resumed” the same title within 24 hours, any title, or the same episode; and does starting a different show count as disengagement from the show or as engagement with the service?
(3) Scale and Budget: roughly how many stop events per second, how long a history per profile is available, and is scoring allowed to be asynchronous (minutes) rather than synchronous?
(4) Signal Availability: do we have stop position within the episode, device identity, autoplay-countdown cancellations, and per-title metadata such as episode length and release date?
(5) Cost Asymmetry: how expensive is a wrong nudge (notification fatigue, opt-outs) versus a missed bored user (a lost chance to re-engage before churn)?
(6) Household Sharing: are profiles reliably one person, or must the model tolerate a household where the kid stops and the parent resumes?


Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *