What "Trending" Actually Measures

"Trending" is one of the least honest words in software. It usually means popular right now, globally — a ranking of what the largest number of people are already looking at. That's a fine description of the past and a poor guide to the near future, because by the time something is unambiguously popular, being early is no longer available to you.

Feedpik's Radar measures something narrower and more useful: convergence across the sources you personally subscribe to. Several independent outlets you already trust, deciding within the same window that the same thing matters.

Because we sell an algorithm that's supposed to belong to you, it would be a bit rich to keep this one behind a curtain. So here's exactly what it computes.

Step 1: group the articles that are about the same thing

Before anything can be measured, the radar has to know that four articles with four different headlines are one story. Keyword matching is bad at this — the same event gets written up as "chip export controls", "Nvidia licence rules" and "Washington tightens semiconductor policy", with barely a word in common.

So the grouping is semantic. Every article carries a 1,536-dimension embedding of its text. The database computes cosine similarity between candidate pairs, keeps the pairs above a similarity threshold, and the clusters are what those connections form. Only the above-threshold pairs ever leave the database — the vectors themselves stay put, which is what makes this fast enough to run on a page load.

The practical consequence: a story gets recognised as one story even when no two outlets phrase it the same way.

Step 2: compare two windows, not one

A cluster's size tells you how much is being written. It doesn't tell you whether that's more than usual, which is the entire question.

So the window is split in half. If you're looking at 48 hours, the radar counts mentions in the last 48 hours (the current half) and mentions in the 48 hours before that (the baseline half), and compares them. You can switch the window to 24h, 48h or 7d in the reader; the split follows.

This sounds obvious. It isn't how the first version worked, and the reason is worth writing down.

The original implementation fetched "the most recent N articles" and split them by timestamp. We measured what that actually spans: for an account with ten sources, the 500 most recent articles covered 27 hours. At twenty-five sources, 15 hours. In both cases the entire fetch landed inside the current half — so the baseline came back empty, every topic looked brand new, and the acceleration comparison was decorative for exactly the busy accounts it was meant to help.

The obvious fix — fetch more articles — was the wrong one. Clustering is quadratic in the number of articles, and 500 already costs about 1.3 seconds on a path that a chat digest waits for. Quadrupling that to fix a windowing bug is a bad trade. Instead the same budget is split: 250 articles from the current half, 250 from the baseline half. Same cost, and the comparison finally has something to compare.

Step 3: score it, 0–100

Each surviving cluster gets a score, and the list is ordered by it. Four inputs, with these weights:

Input	Weight	What it is
Breadth	40%	How many distinct sources are covering it
Volume	25%	How many articles in total
Acceleration	25%	Mentions now vs. the baseline window
Freshness	10%	How recent the latest article is, relative to the window

Breadth carries the most weight because it's the premise of the feature. One outlet publishing five times is a publication with a beat. Five outlets publishing once each, on the same day, about the same thing, is a story. The radar exists to catch the second case.

Each input is put through a saturating curve — log2(1+v), normalised against a ceiling — rather than counted linearly. Breadth saturates at 6 sources, volume at 10 articles, acceleration at 8×. This is not decoration; it fixes two specific failures:

• A story in twelve outlets is not twice the story it is in six. Linear breadth would let one mega-covered topic sit at the top of your radar for three days.
• A ×40 ratio off a single prior mention is an artefact of the denominator, not forty times the acceleration. (Concretely: a topic with no prior coverage is scored against a floor of half a mention, so a genuinely new story registers as a strong ratio without a division by zero and without running away with the ranking.)

Freshness is deliberately small at 10% — enough to float this morning's story above one that peaked at the far edge of the window, not enough to rank anything on recency alone. If freshness mattered more than that, you'd have reinvented the chronological feed with extra steps.

Step 4: one gate, and only one

The radar excludes a cluster for exactly one reason: fewer than two distinct sources. One outlet talking to itself is not convergence, and no amount of volume turns it into convergence. That gate is the feature's definition, so it stays a hard cut.

Everything else — minimum mentions, minimum acceleration ratio — defaults to off.

That's a change from how it started, and it's the most instructive thing in this post. Radar used to be a boolean: a topic was "heating" if it had at least 3 mentions and at least 2 sources and was either new or accelerating 2×. Three thresholds, ANDed.

Two problems showed up immediately. First, the binding constraint was almost always the mention count, and the case it excluded was the cleanest signal the radar has: two different outlets, one article each, same story, nobody covering it the day before. That's the shape of a story at the start. We were filtering out the best cases.

Second, a flag throws away the margin. A reader looking at "1 heating · 5 tracked" has no way to tell whether the other five were noise or were each one article short of the line. The information existed and the interface destroyed it.

A score keeps the margin. Nothing is dropped for being merely close, and the order tells you how close. If you want strict filtering — "only alert me at 5+ mentions and 2×" — that's still available as an option on watches. It's just not imposed on everyone by default.

What you see, and what it means

Each topic card shows the score, then the raw numbers behind it: mentions, distinct sources, the ratio against the previous window, and which of your sources are covering it. The top item is highlighted because it's the top of a ranking, not because it belongs to a different category — every topic on the list cleared the same gate.

We show the inputs, not just the output, for the same reason every ranked article in Feedpik shows its reasons: a number you can't interrogate is a number you can't disagree with, and disagreeing is the point.

What it can't do

Three honest limits.

It needs sources. With five feeds, "two distinct sources converging" is a rare event, and your radar will be quiet. That's the correct behaviour — a radar that invents topics to fill space is worse than an empty one — but it means the feature gets meaningfully better somewhere north of twenty sources.

It will never show you a single-outlet scoop. By definition. If one publication breaks something and nobody has picked it up yet, that's not convergence and the radar stays silent. Your ranked feed is what catches that; the radar is a different instrument.

It inherits your sources' biases, including syndication. If eight of your sources run the same wire copy, that reads as breadth even though it's one story photocopied. Distinct publishers is the best available proxy for independent judgement, and it isn't a perfect one. Worth knowing when you're deciding whether a 78 means eight newsrooms decided something matters, or one newsroom did and seven reprinted it.

The point of publishing this

You can't own an algorithm you're not allowed to read. Radar is the piece of Feedpik that most resembles a black box from the outside — a number appears, topics get ordered — so it's the piece that most needs its workings written down.

Start free, add the sources you already read, and open the Radar. If the ranking looks wrong to you, you now know precisely which of the four inputs to blame.