News portal recommender system: where the feed breaks
The first thing that dies on a news portal is the one-size-fits-all feed. The homepage serves everyone the same block: the model simply has no feature by which users would be split into groups, and it ranks by a shared click counter.
A reader with a different city, a different category, and a different reading rhythm gets someone else's interest — feed personalization exists only formally, while a drop in engagement is blamed on seasonality.
The second failure is quieter: fresh materials sink. An article published an hour ago has no accumulated interaction history, and it loses to a week-old item with a large reserve of signals.
Formally the system works correctly; in practice the news hook is served at the moment when it is already stale, and the feed looks like an archive.
The third is repetition in the feed. A filter by material ID does not catch a repackaged news item: the same story enters under a different category, a different headline, and a different cover image.
Plus a feedback loop: shown — clicked — amplified, and within a few days the feed converges on a narrow group of stories.
Then an editorial crutch appears. The duty editor manually moves materials to the top positions to pull traffic toward the evening peak, and carries this every day.
We break down how this is fixed: which signals are rebuilt, how the "fresh" and "by interest" streams are separated, and what to measure to see the effect.
Measurable effect: retention, read-throughs, and editorial workload
The effect of personalized feed is visible in four groups of metrics: the share of read-throughs to the end of a material, reading depth within a session, returns to the portal after 7 and 28 days, and the pause between visits of a regular reader.
Separately, we look at technical performance — the response time of the recommendation block and the share of transitions after an impression. If the block responds slowly, read-throughs will not grow, no matter how accurately the feed is selected.
The main difficulty is separating growth from seasonality and the news agenda.
We keep the control group on the previous, non-random feed and compare days comparable in "temperature," rather than simply "before and after." In parallel, we calculate an organic index across the entire portal: if all channels grow at once, the effect cannot be attributed to recommendations.
Editorial workload shifts from "assemble the top stories by hand" to "check deviations." Automated selection removes manual feed sorting from the editor, so time goes to headlines, fact-checking, and investigating anomalies, rather than arranging blocks.
A separate effect is the long tail of the archive: materials that have left manual selections continue to receive impressions and read-throughs.
Research by Reuters Institute shows that media sustainability is held up by returning readers, not one-off traffic spikes, so in the report we separately record the share of repeat visits by cohort.
We launch the pilot on part of the traffic, and we agree on the metrics and their calculation rule before the start — then growth is visible in numbers, not in interpretation.
Operating formats of a recommender system: what a portal should choose
The serving scheme is chosen by data density, not by how "advanced" the algorithm is. Collaborative filtering, as applied at Netflix, relies on accumulated reading history: while the reader — material matrix is sparse, the recommendation block shows random links.
Content features start immediately — text, category, tags, publication freshness — but quickly create a bias toward one topic.
The difference between modes is visible along three axes: whether accumulated traffic is needed, how much manual work the editorial team takes on, and how expensive it is to change the scheme later.
| Mode | When it fits | Limitations |
|---|---|---|
| Collaborative filtering | A steady reader flow, materials accumulate viewing history | Does not work without accumulated data; new items and rare categories receive no impressions |
| Content features | Cold start, narrow topic, feed needed immediately | Bias toward popular topics, weak account of the reader's personal habits |
| Hybrid scheme | The portal is growing, part of the blocks already provided with statistics | Requires weight tuning and monitoring, otherwise one part suppresses the other |
| Editor rules | Top news, manual selections, themed special projects | Does not scale to the long tail, requires a policy and access rights |
The hybrid scheme is the workable compatibility solution: content features cover cold start and new categories, collaborative ones connect where statistics have already been accumulated, and weights are revised based on read-through metrics, not by eye.
The modes do not exclude each other — a portal can keep a hybrid on the homepage and pure editor rules in the breaking news block.
Editor rules are compatible with any of the modes: they set priority materials and prohibitions, while the algorithm fills in the rest.
The homepage feed is delivered to the frontend under a single contract, so changing the scheme does not require rewriting the layout — the order of blocks and weights change, and the editorial team continues working in the usual interface.
How we implement: log audit, scheme, setup, verification
The order of steps here is not accidental: until it is clear which events actually reach the storage, any model is built on sand. That is why we start with logs, not with algorithm choice, and only then fix the exchange scheme and verification method.
- Log audit. We examine what exactly is written: impressions, clicks, read-throughs, subscriptions, search queries. We check completeness, duplicates, delivery delay, and joining events with the reader profile. The output is a list of gaps: where the identifier is lost, which fields are not always filled.
- Event markup. We agree on a dictionary: event name, timestamp, source, action weight. A read-through weighs more than a click, a random transition weighs less. A unified dictionary allows retraining the model and correctly comparing periods with each other.
- Integration scheme. We decide how selections reach the page: server-side delivery, a separate serving service, or a prepared cache. We fix the behavior when the service is unavailable — the reader should see a meaningful list, not an empty block.
- Testing on traffic history. We run the model on accumulated logs: reconstruct sessions by time, serve recommendations, and see whether they would have matched actual actions. Errors are visible before the first impression to a live reader.
- Online experiment. We enable the feed on part of the traffic alongside the current mechanism: we observe session depth, read-through share, and page response. The rollout goes in increments, rollback is one switch.
- Result acceptance. We compare metrics with those fixed before the start, check behavior under peak load, a cold profile, and incomplete data. We hand the team a retraining policy, monitoring, and troubleshooting for typical failures.
What the portal team keeps after project delivery
Project delivery is not a demonstration of a working service, but the handover of a loop that the portal team then runs on its own.
Therefore, what is handed over is not only code, but everything needed to change ranking rules, retrain the model, and troubleshoot a failure without us.
Acceptance goes by checklist, not by presentation: each artifact is checked on the customer's side — they bring up the environment on their own stand, run retraining, and roll back a version.
- Training and serving code — a repository with configurations, pinned dependencies, and instructions for bringing up the environment from scratch.
- Integration schemes — the event path from impression to storage: message formats, redelivery, failure points, feature update delay.
- Model update policy — retraining frequency, control slices, rollout threshold for a new version, and procedure for rolling back to the previous one.
- Access policies — roles for data reading, separation of production and test environments, and logging of access to personal data.
- Set of automated checks — top-hit share, feed diversity, behavior on new users; calculated after each retraining.
- Incident playbook — what to look at first when metrics drop, how to roll back a version, and how to restore the previous dataset.
Handover to the team is a separate stage: over two or three sessions, the customer's engineers retrain the model themselves and release a version into the feed. After that the loop lives without our participation — we stay in touch, but changes are made on their own.
Case study: how reading depth grew on a news portal
The portal ran on a chronological feed: materials were placed by publication time, and everything depended on whether an item made it into the first screens of the homepage.
Reading depth held at 1.3 articles per visit, and more than half of visitors left the homepage without opening a single material. The baseline was fixed over a 30-day window before implementation — so that afterward we could compare on the same metrics.
What we changed
The feed was assembled with a hybrid model using collaborative filtering: the reading history of a specific visitor, the behavior of readers with similar interests, material freshness, and category weight from the editorial team.
The feed is recalculated on every page refresh; for new visitors it is filled by what is popular in the category over the last hours, and the editorial team keeps priority materials at the beginning in a separate list.
| Metric | Before implementation | After |
|---|---|---|
| Reading depth, articles per visit | 1.3 | 3.1 |
| Exits from homepage without opening a material | 57% | 31% |
| Returns to the portal within a week | 22% | 38% |
| Share of visits with personalized feed | — | 74% |
Limitations remain, and we do not hide them. To visitors without consent to personalization, we serve the editorial feed — this is about a quarter of the audience.
The model retrains once a day, so it does not react instantly to a sharp news hook — on such days the freshness weight is raised manually.
Reading depth grew more than twofold, and empty homepage visits became fewer: personalization takes on the routine of layout, while editorial judgment remains with people.
How does behavioral selection differ from editorial selection?
Behavioral selection determines the order of materials by readers' actual actions: what they opened, how deeply they read through, what they returned to, at which paragraph they left.
Editorial selection is built on a human decision — the person sets topic priority, category order, and which material goes on the front page.
The algorithm is objectively stronger where the audience is large and heterogeneous. It holds the long tail of publications, which an editor physically cannot keep arranging by hand, and serves each reader their own feed order.
The editor is irreplaceable in another way: on days of major events, when what matters is not headline flashiness but a unified picture of the day, and when topic balance must be consciously maintained.
The weaknesses are mirrored. An algorithm without sufficient viewing history locks onto the most popular items, pulls up catchy headlines, and gradually narrows the topic range to a couple of categories.
An editor does not scale: one order for everyone, manual editing cannot keep up with the news flow, and the subjectivity of the decision is hard to verify with a metric.
Hence the hybrid mode — a workable option for most portals.
The algorithm ranks within thematic blocks, while the editorial team sets the boundaries: fixed positions on the front page, a limit on the share of one topic in the feed, and downgrading a material with high reader exits.
The choice of scheme is determined by the share of regular readers, publication frequency, and how important it is for the editorial team to manage the front page manually.
Concerns about data quality and cold start
Objections before the start sound almost the same: there is no markup, new materials do not need recommendations, last year's preferences do not reflect the audience's interest. We answer to the point.
We start not with the model, but with a data audit: impression and click logs, the share of automated traffic, session depth, and category taxonomy completeness.
Where there is little history, text and tag proximity works — the selection is assembled from day one, and personal weights are pulled in as events accumulate.
How do you serve recommendations without user history?
For new readers — what is popular in the category, adjusted for time of day and region; personal signals turn on after several read materials. Fresh articles enter the selection based on text and tag parsing, without waiting for clicks.
How do you assess the quality of the selection?
On historical data — a time-based holdout set so the model does not peek into the future, plus hit and diversity metrics. On live traffic, we compare with a control group: session depth, returns.
What about news freshness?
The freshness weight is a separate feed parameter, not retraining of the entire model. A material rises in the first hours, then yields to those that hold attention. The window is configured by category: shorter for breaking news, longer for analysis.
How often do you retrain models, and can you roll back?
Retraining runs on a schedule and by a metric degradation trigger. Weights are updated without stopping the feed, the previous version is saved for rollback, and activation happens after running on shadow traffic.
Let's discuss the task: what to know before the start
To discuss the task substantively, we do not need full access to production — a description of the portal and data exports are enough.
The more accurate the input data, the faster we will return with an estimate and a work plan: we will break down the scope by stages and specify what we do on our side, and what data and decisions are needed from your team before the project starts.
- Content profile and volumes: how many materials are published per day, what share are new versus archive, how often categories are updated, and how long a material lives in feeds.
- Analytics access: an export of events for 3–6 months — impressions, clicks, read-throughs, returns, in-portal search. Anonymized reader identifiers and a timestamp are enough; personal data is not needed.
- Material markup: whether tags, categories, entities, and embeddings exist in your storage — or whether they need to be assembled from texts on our side.
- Serving points: where recommendations should appear — the main feed, a "similar" block inside an article, newsletters, mobile app. Each point requires its own set of signals.
- Infrastructure constraints: where production runs, what feed response time is considered acceptable, and what load headroom is needed during peak hours.
- Editorial rules: what must not be recommended, how many manual promos should remain in the feed, and whether there are requirements for category diversity.
- Success metrics: what we consider the result — read-through share, session depth, next-day returns. They determine the comparison scheme with the current feed.
- Who makes the decision: a person on the editorial side and on the product side who confirms acceptance of stages.
Describe the task in free form — that will be enough to return with an estimate, a work plan, and a list of what we will clarify on the first call.
