skip to content

A new listener picks three topics during onboarding — how long should that stated signal steer the podcast feed?

level: seniorimportance: should knowfreq 44%

answer

  1. a prior, not a history
  2. cheap to say, weakly predictive
  3. decay on listens, not on days
  4. weight by the cost of the action
  5. keep it out of the behaviour log

basics

~20 s

Only until observed behaviour replaces it. Treat the picks as a low-confidence prior that seeds retrieval while there is nothing else, then decay their weight against completed listens — not against elapsed days — and keep them attributable rather than written in as fake events.

solid answer

~50 s

A topic pick is cheap to give and weakly predictive: it says what the listener believes they want, which is not what they play. So it earns the weight of a prior, not of a history. While completed listens are zero it can dominate — it seeds the topic rung's retrieval and is the only listener-specific signal there is — and its weight should fall as real plays accumulate, counted in listens rather than days, because a listener who plays nothing for two weeks has produced no replacement for it. Weight it by how expensive the action was: an imported subscription list is a far stronger statement than three taps on a topic grid. Keep the picks in their own field rather than synthesising listen events from them, so the weight can be changed or the signal dropped without disturbing the behaviour log or the funnel's attribution.

go deeper

for a junior

Recall that what a listener says they want and what they actually play are different signals, and the second one eventually wins.

for a middle

Explain the decay mechanically: the weight falls against completed listens rather than calendar time, and the picks seed retrieval rather than being recorded as behaviour.

for a senior

Show the production consequences — why time decay erases signal for a returning listener, why synthetic events poison the behaviour log and every guard that counts it, and what you measure to set the decay.

for a principal

Decide whether the onboarding step is worth its cost at all: it buys a first session and a signal of weak strength, and the case has to rest on measured cohort engagement, not on the interface looking helpful.

## A stated preference is a prior, not a history Onboarding exists because the funnel has nothing else: a listener who signed up two minutes ago has no plays to encode, and the alternative to asking is serving global popularity to everyone. So the ask is worth making. What it buys, though, is a **prior over topics**, not evidence of behaviour, and the two differ in a way that shows up quickly in production. Stated preferences are systematically aspirational. People pick the topics they would like to be the kind of person who listens to, and then play something else. They also pick under a very cheap interface — three taps, no consequence — so there is no cost to over-claiming. That does not make the signal worthless; it makes its weight an empirical question, and the honest position is that onboarding picks predict plays weakly and the strength has to be measured on your own surface rather than assumed. ## Decay against behaviour, not against the calendar The common bug is a time-based decay: halve the onboarding weight every week. Consider a listener who signs up, picks three topics and does not open the app for a month. Time decay has erased the only signal the system has, and replaced it with nothing, so the feed gets *worse* while the listener was away. Decay on the quantity that actually substitutes for the prior — **completed listens**: - at zero completed listens, the picks are the entire listener-specific signal and should steer retrieval outright; - as listens accumulate, the weight falls, because each one is stronger evidence than a tap; - past a stated count the picks are a small residual boost, or gone. A plain form is a weight that falls from one to zero over the first *N* completed listens, with *N* chosen as the listen count at which a behavioural vector is stable enough to steer on its own. This is the same threshold the fallback ladder uses to open its top rung, and re-using one number keeps the two decisions from disagreeing. ## Not every onboarding signal is worth the same | signal | what it costs the listener | confidence it earns | how fast it should decay | |---|---|---|---| | topic picks on a grid | three taps | low — aspirational, cheap to over-claim | fast, over the first handful of listens | | an imported subscription list | a deliberate action against another account | high — a record of real, repeated commitment | slowly; it is behaviour, just borrowed | | a first search query | typing an intent | high for this session, low for the profile | it is a session signal, not a profile one | Weighting by the cost of the action is a reliable heuristic, and it explains why an imported list can carry almost the weight of native history while a topic grid cannot. ## Keep it attributable A tempting shortcut is to write the picks into the behaviour log as synthetic listen events, so every downstream stage "just works" with no new field. It is a trap: - the weight becomes unchangeable without rewriting history; - no dashboard can distinguish a play from a tap afterwards, so you can never measure whether onboarding picks are worth collecting; - anything that consumes the behaviour log inherits the fabrication, including counts used by the ladder's own guards — the listener appears to have listens they never had. Keep the picks in their own field, consumed explicitly as retrieval seeds and as a boost term, so they can be down-weighted, A-tested or removed by configuration. ## What breaks when it over-persists The visible failure is a listener who picked three ambitious topics at signup and still sees them months later, because the weight never fell far enough for real plays to outrun it. The feed argues with the listener about who they are. The measurable version: the gap between the topic distribution of a cohort's onboarding picks and of their actual completed listens, tracked as the cohort ages. If that gap stays wide while the feed keeps serving the picks, the decay is too slow. ## What to measure 1. Whether cohorts that completed onboarding have better early engagement than those that skipped it — the only justification for asking at all. 2. Agreement between picked topics and played topics, at the cohort level, by listen count. 3. The residual weight on the picks at the point most listeners stop being cold, which is the number the decay actually controls.

  • Should the funnel ask for onboarding picks at all if they predict plays only weakly?
    Usually yes, because the comparison is not against a good signal but against none: the alternative for the first session is global popularity for everyone. It also sets expectations — a listener who chose topics understands why the feed looks the way it does. Justify it with measurement, though: compare early engagement for cohorts that completed onboarding against those that skipped it, and drop the step if the gap does not survive.
  • How should an imported subscription list be weighted against the first few native listens?
    Near the weight of native behaviour, and decayed far more slowly than topic taps. An import is a record of repeated commitment on another surface, not a stated intention, so it is closer to history than to a prior. Keep it in its own field rather than merging it into the native listen log, so its contribution stays attributable and so a stale import — subscriptions the listener abandoned years ago — can be aged separately.

saying these in an interview costs you the question

  • Decays the onboarding weight on elapsed days rather than on completed listens
  • Writes topic picks into the behaviour log as synthetic listen events
  • Treats a topic tap and an imported subscription list as equally strong
  • Keeps stated picks at full weight indefinitely, so the feed overrides real plays
  • Assumes stated preferences predict plays as well as plays do