What distinguishes in-session recommendation signals from recurring weekly and daily cycles?

This explores two different timescales recommendation systems track: signals that arrive live during a single browsing or chat session, versus preferences that recur on predictable weekly and daily rhythms. The corpus treats these as genuinely different problems, not points on one continuum — and the cleanest way to see the difference is what each one costs you to capture.

In-session signals are *fresh but un-precomputable*. Netflix's work on real-time adaptation shows the catch plainly: reacting to what you click mid-session improves ranking by about 6%, but because those signals don't exist until the moment arrives, the system can't precompute anything — it has to recompute at runtime, which drives up call volume, timeout risk, and even makes bugs harder to reproduce How can real-time recommendations stay responsive and reproducible?. The defining property of an in-session signal is novelty: each one is new evidence about what you want *right now*.

Recurring cycles are the opposite — they're *predictable but easy to mistake for novelty*. HyperBandit's insight is that a user who reliably wants different things on Sunday morning versus Wednesday night isn't drifting or changing; they're cycling. Most systems try to detect change after the fact ("this user's behavior shifted"), but that treats every Sunday as a surprise. Instead, HyperBandit conditions on *time-of-period itself* as a context dimension, so matching times retrieve matching preference functions — the system recognizes the rhythm rather than re-discovering it Why do recommendation systems miss recurring user preference patterns?. The distinguishing move is treating recurrence as structure to exploit, not as drift to chase.

So the real contrast is recompute-on-arrival versus recall-by-clock. And there's a subtler bridge here worth noticing: conversational recommenders frame the *same* split as separate preference channels. They argue you need at least three — the current session, your historical dialogues, and look-alike users — because leaning only on the live session throws away the slower, stabler signals that traditional recommenders proved valuable crs-user-centric-modeling-needs-three-preference-channels-current-session-history. In-session is one channel; recurring cycles live in the historical channel. They're complementary, not competing.

If you want to go further, the streaming-recommendation literature wrestles with how to hold both at once without one overwriting the other — DEGC isolates parameters per time-slice precisely so emerging in-session patterns can be learned without erasing the older recurring ones Can model isolation solve streaming recommendation better than replay?. That stability-versus-freshness tension is exactly what makes mixing the two timescales hard, and it's why the corpus keeps treating them as distinct signals rather than collapsing them into one notion of "recent behavior."