Personalization for News Apps: Recency vs Relevance

TL;DR.

• News stories have a half-life measured in hours: a story 3 hours old has roughly 10x the user-perceived relevance of the same story 24 hours old.
• A pure relevance ranker buries breaking news under the user's pet topics; a pure recency ranker shows every returning user the same homepage and kills personalization for news apps entirely.
• The working pattern is score = relevance × decay(age) + must_show_boost, with decay an exponential or power-law curve tuned per section.
• Editorial "must-show" overrides are not optional — breaking news has to bypass the personalization layer for the first 30 to 90 minutes.
• Reader signatures (the topic-affinity vector built from session and reaction signals) should update inside the same session, not on a nightly batch.

If you build a news app the same way you build a music recommender, you will ship a product that recommends yesterday. Music has no expiry. A song you loved three years ago is still a fine recommendation today. News doesn't work that way: half the value of a story evaporates between breakfast and lunch. This post walks through how personalization for news apps actually weighs recency against relevance, three ranking patterns we've seen work in production, and the one editorial override you can't skip.

Why news is the hardest personalization problem

Most personalization writing assumes the candidate set is roughly stationary — a song catalog of 100M tracks, a Netflix library of ~17,000 titles, an e-commerce SKU list that turns over slowly. The ranker's job is to find the right item for the right user, and the "right" answer barely changes minute to minute.

News inverts that assumption. The candidate set turns over every few minutes. A wire story that landed 12 minutes ago may be the single most important piece of content for 10M users, and 12 hours later it may be irrelevant to all of them. The ranker is not just matching user to content — it is racing the clock against its own catalog. Surveys of the field describe news as a domain where items "expire quite soon (maybe minutes, hours or barely a few days)," which is why news recommendation engines have to model time as a first-class signal rather than an afterthought.

The Reuters Institute Digital News Report has been tracking the user-behavior side of this for years. People increasingly come to news apps for "what's happening right now," and the share of users who say they want the app to surface stories matched to their personal interests has plateaued. The 2025 personalization chapter notes that audiences want humans (and clear editorial judgment) in the driving seat even as AI ranking has improved. The expectation is both. If your homepage is stale by 20 minutes, returning users notice. If your homepage doesn't reflect what they care about, new users bounce. You have to do both, and they pull in opposite directions.

The freshness curve

We've measured click-through rate against story age across several news properties. The curve is reliably non-linear — closer to exponential than linear decay. As a rough heuristic for general-news content:

• 0 to 1 hour: peak relevance, often 1.0 baseline.
• 3 hours: roughly 0.5 of peak.
• 12 hours: roughly 0.15 of peak.
• 24 hours: roughly 0.05 of peak.
• 48 hours: effectively dead unless evergreen.

Sports, finance, and politics have steeper curves. Lifestyle, opinion, and longreads have flatter ones. You cannot use one decay constant for a whole news site. Section-level (or even topic-level) decay parameters are the cheapest accuracy win in any news ranking algorithm.

The math: combining relevance and recency

The naive approach — sort by published_at DESC — gives you a reverse-chronological feed. That works for Twitter circa 2009. It does not work for a personalized homepage where the same user is opening the app five times a day and expects the experience to feel curated.

The other naive approach — sort by relevance_score DESC — gives every returning reader the same set of stories that match their long-term interest profile, regardless of whether those stories landed an hour ago or last week. Users notice. Day-three retention craters.

The working pattern combines them multiplicatively:

final_score = relevance_score(user, story) * decay(age_minutes, section) + must_show_boost(story)

Three things to notice. First, the decay is multiplicative, not additive — a story with low relevance and high freshness shouldn't beat a high-relevance story with moderate freshness. Second, decay is parameterized by section, so politics and lifestyle don't get the same curve. Third, the editorial boost is additive on top, so a breaking story can punch through even when its personalized relevance score is mediocre.

Choosing a decay function

The two real candidates are exponential decay and power-law decay:

exponential:  decay(t) = exp(-t / tau)
power-law:    decay(t) = 1 / (1 + t / t_half)^alpha

Exponential decay falls off cleanly and is easy to reason about — tau is the time constant, and the score halves every tau * ln(2) minutes. Power-law is more forgiving in the long tail, which matters if you have evergreen content mixed with the news stream. If you're starting from scratch, start with exponential per section, fit tau empirically against historical CTR, and only move to power-law if you see your evergreen content getting unfairly punished. We've seen tau values between 90 and 360 minutes in production, depending on the section. The half-life decay literature on collaborative filtering (e.g. the CEUR-WS work on matrix-factorization with time decay) confirms the same shape: a single global half-life is almost always worse than per-section or per-item parameters.

For a deeper treatment of why we model recommendation scores as products of independent signals rather than as a single learned blob, see explainable recommendations and the path of a recommendation.

Three ranking patterns that actually work

After shipping news personalization across a few different apps, three patterns hold up. Pick one, then layer the others as you grow.

1. Age-decay multiplier on the relevance score

This is the baseline of any news ranking algorithm worth shipping. Compute relevance with whatever you have — a topic-affinity vector, an embedding similarity, a knowledge-graph traversal — then multiply by the section-aware decay function above. This single change typically pushes session length by 8 to 15% versus a pure relevance ranker, because returning users stop seeing yesterday's stories at the top of their feed.

The implementation is one extra column in your candidate-generation step and one multiplication in your ranker. There is no excuse not to ship it.

2. Editorial "must-show" overrides for breaking news

The hard truth: when a major story breaks, it has to be the top result for everyone, regardless of personalization. If a head of state dies, an earthquake hits, or a market crashes 8% in 90 minutes, your ranker should not be deciding whether to show that story to a user whose long-term interests are sports and food.

The mechanism is a manual lever — an editorial CMS flag that adds a large must_show_boost (we use values like +10.0 on a normalized score in [0, 1]) for a fixed window, typically 30 to 90 minutes. After the window expires, the boost decays out and the story re-enters normal ranking, where it will fall organically as it ages.

NYT Open has written about how the New York Times mixes algorithmic ranking with editorial curation for exactly this reason. The lesson: don't pretend your ranker can do editorial judgment. Build the override, give it to your editors, and trust them to use it sparingly. A news app personalization stack without an editorial override is one major breaking story away from a customer-support fire.

3. Reader-signature inference for niche topic coverage

The first two patterns handle the "what's hot" problem. The third handles the "what does this specific reader actually want" problem. The reader signature is a sparse vector of topic affinities — usually 200 to 2,000 dimensions, depending on your taxonomy — that updates from in-session signals: dwell time, scroll depth, completion, save, share, swipe-away.

Two design decisions matter here. First, the signature has to update inside the session, not on a nightly batch. If a reader spends 90 seconds on a Federal Reserve story at 9:14 a.m., the 9:30 a.m. refresh of the homepage should reflect that. Nightly batches lose roughly half the available signal. Second, the signature should have a decay of its own — interests shift, and a topic the reader cared about six months ago is not necessarily a topic they care about now.

We cover the architecture for in-session signal capture and low-latency recompute in the reference architecture for real-time personalization. The short version: a streaming pipeline pushing reaction events into a feature store, with the ranker reading the latest signature on every request and a target end-to-end latency under 50 ms.

The day-zero problem in news

News has a particularly nasty cold-start problem, because by definition you have no behavioral signal on a brand-new user, and yet they're standing on your front page expecting a personalized experience. We've written about the cold-start problem and day-zero personalization more generally — for news specifically, the working approach is:

1. Start every new user on a "balanced" feed: top stories from the last 6 hours, weighted toward editorially-flagged must-shows, with topic diversity enforced.
2. Capture the first 5 to 10 reactions (taps, dwell, swipe-away) within the first session.
3. By the second session, the reader signature is good enough to start ranking with personalization weight 0.4 and the balanced default 0.6.
4. By session three, flip the weights.

This is roughly the bet behind Vivo, our day-zero AI video briefing product — a 2 to 3 minute personalized news video on your second open, generated from the signal of your first session. The recency-vs-relevance tradeoff is the same as in a list-based news app; the format is just different. Personalization for news apps gets a lot easier when you treat the first session as labelled data for the second, rather than as a problem to wish away.

What goes wrong if you skip the recency layer

Three common failure modes we've seen on news products that went pure-relevance:

• The "yesterday's news" homepage. Returning users open the app at 6 a.m. and see the same five stories that were there at 11 p.m. Day-three retention drops 20 to 40% versus a recency-aware ranker.
• Topic monoculture. A relevance-only ranker over-fits to the user's strongest signal. A reader who clicked three NBA stories in a row will see only NBA for the next week. Diversity has to be enforced explicitly, either through MMR-style re-ranking or a hard quota.
• Breaking-news blindness. The single most common complaint on news app reviews: "Why am I not seeing X?" where X is the story everyone is talking about. The fix is the editorial must-show, not a smarter model.

For comparison with related domains, personalization for media sites covers the same tradeoffs for general media properties (video, podcasts, longform), where the freshness curves are flatter but the diversity problem is similar.

Evaluation: how do you know it's working?

A news ranking algorithm is hard to evaluate offline because the candidate set keeps changing. Two metrics that hold up in practice:

• Session-aware nDCG: discount-cumulative-gain against the user's actual reaction stream within a session, rather than against a frozen relevance label. This penalizes stale stories the way users actually do.
• Time-to-first-interesting-story: how many scrolls before the user does something positive (tap, save, dwell > 20 seconds). Recency-aware rankers consistently cut this in half versus pure relevance, which translates directly into session length.

Pair both with a CTR-by-age curve you keep refreshed weekly. If the curve drifts (politics gets steeper during an election cycle; sports flattens during the off-season), your decay constants should drift with it. A static tau in a section that's actively changing is a quiet way to lose 10% of your CTR.

How ×marble fits in

If you'd rather not build the recency-decay-plus-relevance-plus-editorial-override stack from scratch, that's roughly what the ×marble personalization knowledge graph does out of the box. We model both content (with topical and entity edges) and reader signatures (with in-session updates), and the ranker exposes the section-level decay parameters and editorial boost as configuration rather than code. Vivo is the news-briefing product built on top of it, and the same engine powers our video and music personalization products. See timesmarble.com if you'd like to talk through whether it fits your stack — we work with marketing engineers and technical product founders, and the integration is usually a few days, not a quarter.

FAQ

How is news app personalization different from music or video personalization?

Catalog turnover. A music catalog is roughly stationary — a song from 2018 is still a fine recommendation in 2026. A news catalog turns over every few minutes, and the value of any single story decays on a half-life of hours. That forces every news recommendation engine to combine a relevance score with a time-decay function, which most music and video rankers don't need.

What's a sensible decay constant for a news recommender?

In an exponential decay model exp(-t / tau), we've seen production tau values between 90 and 360 minutes, depending on the section. Politics and sports tend toward the low end (90 to 180 minutes); lifestyle, opinion, and longreads sit at the high end (240 to 360+). Fit it empirically against historical CTR per section rather than picking one global value. Re-fit at least quarterly.

Should breaking news bypass personalization entirely?

For a window, yes. The standard pattern is an editorial must-show flag that adds a large additive boost to a story's final score for 30 to 90 minutes, after which the boost decays and the story re-enters normal ranking. Without this, a strongly-personalized news ranking algorithm will hide major news from users whose long-term interests don't include the topic.

How quickly should the reader signature update?

Inside the session, ideally on every refresh. If a reader spends 90 seconds on a Federal Reserve story at 9:14 a.m., the 9:30 a.m. refresh of the homepage should already reflect that affinity. Nightly batch updates lose roughly half the available signal and produce a noticeably less responsive product.

Do I need a knowledge graph for news personalization, or are embeddings enough?

Embeddings get you a long way, especially for topical similarity. The argument for a knowledge graph in news specifically is explainability and editorial control — you can ask "why did this user see this story?" and get an answer in terms of entities and topics, and you can give editors levers that operate on the same vocabulary the ranker uses. We compare the two approaches in knowledge graphs vs vector embeddings.

Further reading

• Hyper-personalization explained for engineers — the broader framework that recency-vs-relevance fits inside.
• The cold-start problem and day-zero personalization — the new-user side of the problem, applied across product categories.
• Reference architecture for real-time personalization — the streaming, feature-store, and serving stack that makes in-session signature updates possible.
• Five patterns for adding personalization — the general playbook this news-specific post is a specialization of.
• Reuters Institute Digital News Report — how audiences actually think about news personalisation in the AI era.
• News recommender systems: a survey — the canonical academic overview of recency, popularity, and freshness as ranking signals.