Cross-Network Trend Radar

Most trend scrapers hand you a leaderboard. A leaderboard is what the platform already publishes, so every scraper of that platform returns the same thing.

This one computes the two things no platform publishes about its own list:

1. Is it actually rising, or has it been there all week.
2. Is it rising on more than one network at once — the one signal a single-platform scraper cannot produce no matter how deep it goes.

Sources

Source	What you get	Where the rise signal comes from
Google Trends	10 rising searches per country across 95 countries measured to serve data (of 103 codes tested), each with an approximate traffic bucket and the minute it started rising	the platform's own start time
Bluesky	up to 25 topics with post count, category, start time, and a lifecycle status the platform computes itself	the platform's own trending / saturating / cooling / stale
Mastodon / fediverse	trending hashtags across the largest servers, each with seven days of daily use counts	a real daily series
Wikipedia	articles whose pageviews jumped, any language edition	a real daily series, fetched per article
Hacker News	front-page stories with points per hour	the story's own age
Douyin	the public hot-search board	snapshot only, no rise signal

Every row says which of those it is, in seriesProvenance. A spikeRatio appears only on rows whose series was genuinely measured day by day.

The thing most trend data gets wrong

A rank list and a measurement look identical in a data structure, and they are not the same thing. Wikipedia's daily top-1000 is a rank list: an article that is absent from it today did not get zero views, it just placed below 1000th. Inferring a series from rank presence produced these, measured:

Article	Inferred from rank	Actually measured
Susan Dell	14.8×	58.4×
Carrie (miniseries)	1.3×	2.6×
Other Mommy	1.3×	2.3×

Three of four candidates were wrong, in both directions. So the top list is used here only to pick candidates, and each candidate's real daily series is fetched per article. A gate in the code refuses to emit a spike ratio on any row whose series did not come from a real measurement.

Cross-platform confirmation is a selective signal

Measured on live runs: 374 rows across 5 platforms produced 3 cross-platform groups; 1,053 rows produced 6. Between half a percent and one percent.

That is the point of it. A light that comes on for everything tells you nothing. But it means this layer gives you a handful of rows per run, not a full page — the bulk of the volume is in the per-row trendSignal. If you want a long list, read the rows; if you want the few things several independent networks noticed at the same time, read the cross-platform records.

Matching terms across networks is conservative on purpose. The rule is containment: the smaller set of distinguishing words has to be fully inside the larger one. A single shared common word is not enough, because that produced these false matches on live data:

• supreme court of the united states ↔ Arsenal vs. Leeds United — on united
• state fair of texas ↔ James Talarico's Texas Senate — on texas

Both are rejected now, by containment alone: only a third of the smaller term's words are shared. Terms are also diacritic-folded, so beşiktaş – kocaelispor and besiktas – kocaelispor are one topic.

The rule does not depend on how much you sweep. An earlier version also demanded that a shared word not be common across the run, and that made the same two terms match in a five-country sweep and not match in a ninety-five-country one, because a popular word appears in more phrasings the more you collect. It is gone.

What remains: a one-word term joins any phrase containing it, so liverpool groups with liverpool vs man city. That is right for a watchlist and occasionally too eager for grouping. Every group reports matchedOn, so you can see why two terms were joined and disagree if you want to.

Geographic spread

A full sweep of all 95 verified countries returns about 950 rising searches, and that is where the second derived layer lives: the same search rising in many countries at once. Measured on one sweep, 44 topics were rising in three or more countries, distributed like this:

Countries	Topics
51	1
35, 32, 29	1 each
21, 17, 16, 13, 12, 11, 10, 9	1 each
7	3
6	5
5	4
4	9
3	11

China, Iceland, Luxembourg, Malta, Mongolia, Brunei, Laos and Macau return nothing and are excluded from the verified list rather than reported as failures. If a large share of the requested countries stops answering, the run fails — all 95 answered when measured, so a shortfall means the endpoint changed or is throttling, not that there is no news.

One limitation worth knowing

Terms are matched on their words, so the same event written in a different script forms its own group. On the sweep above, liverpool - manchester city covered 51 countries and ливерпуль – манчестер сити covered 7 more (Armenia, Azerbaijan, Belarus, Georgia, Israel, Kazakhstan, Uzbekistan) as a separate row. That is the same football match. No transliteration is attempted here, because guessing at it would create false matches that are harder to spot than this one; the script of the term tells you which language sphere the group describes.

Countries are not platforms

A search rising in nine Google Trends countries is not nine networks confirming it; it is Google seeing it in nine places. Those are two different claims and they are reported in two different fields: platformCount and geoCount. minPlatforms counts platforms only.

Or watch terms you already care about

Discovery is one job; watching is another. Give it a list of terms — a brand, a product, a competitor, a topic — and it reports whether each one is rising anywhere across all the sources and all 95 countries, using the same requests.

A term that is rising nowhere still gets a row, saying so. That is the answer to the question, and a gate enforces it: returning one row per term is required, so you can never confuse "not rising" with "the run failed".

Matching uses the same containment rule as everything else, so watching tesla finds tesla valve (the whole watched term is in it) but not nikola motors.

Absent means not rising, not unpopular. A live run watching six terms found liverpool on 2 platforms in 45 countries, and found bitcoin, nvidia, taiwan and openai nowhere at all. Those four are not obscure — they are permanently popular, and a rising list is by construction a list of things that just changed. Watch a term to learn when it breaks out, not to measure how big it usually is.

It builds its own history

Google Trends tells you when a search started rising but not what its volume was yesterday. Douyin's board has no history at all. So the run remembers: each topic's volume is written to a key-value store on your own account, and later runs compare against it.

That adds runsSeen, firstSeenAt, hoursTracked, volumeChange, volumeChangePct and runSpikeRatio — a measured series for sources that publish none.

Two things to know. The first run has no history, so those fields are null, not 0. And the series is paced by your schedule: runSpikeRatio compares this run against your previous runs, so the same number means something different hourly than it does weekly. Every row therefore carries observationGapHoursMedian, and a gate refuses to emit the ratio without it.

Runs less than 15 minutes apart count as one point in time: a run started right after another (or two started together) does not compare against it, and the stored series keeps the later observation. Ratios are only ever computed across observations at least 15 minutes apart.

The store is pruned: 24 observations per topic, topics dropped after 30 days unseen, 4,000 topics maximum.

Volume scales do not convert

volume means a different thing per source — a Google traffic bucket, a Bluesky post count, fediverse tag uses, Wikipedia pageviews, Hacker News points, a Douyin hot value. Each row states which in volumeKind. Adding or ranking across sources is wrong, so cutoffs are per source, and every run reports observedScalePerSource with the real min / p50 / p90 / max so you can set thresholds against the actual distribution instead of a guess.

Worth knowing: the fediverse aggregate ceiling is around 7,000 uses a day, so a cutoff of 10,000 there returns nothing at all.

On the path it takes

Google Trends exposes two things: a published RSS feed of what is rising, and the data API behind the Trends web interface. The second one is richer — twelve months of weekly history, related queries marked Breakout — and it is rate-limited per IP hard enough that it is not usable at product scale without a proxy pool. Measured: twenty-five keyword lookups through it completed zero times; after about thirty-five requests even the cheap first call starts returning 429, and a fresh session forty-five seconds later still gets 429.

The RSS feed has a separate quota and does not throttle. Measured: four full sweeps of all 95 countries, 95 of 95 answering every time, no failures, about 0.8 seconds per country.

So this Actor reads the feed, and spends its effort on what the feed does not give you: whether something is rising, whether several independent networks noticed it at once, and what it looked like on your previous runs.

It is not a replacement for a full Trends scraper. If you need five years of interest-over-time for a keyword you have chosen, this does not do that, and the tools that do are running proxy infrastructure to get it. What this does is find the things you had not thought to ask about.

What is not here, and why

No TikTok, Instagram, Weibo or Reddit. Not because they are hard — because they say no in writing. TikTok's robots file names AI crawlers individually and disallows everything, and its * rules do not include the API path. Weibo and Reddit disallow everything for *. Those endpoints do return data if you ask them, which is exactly why the test here is the written policy and not the status code.

Douyin is the one source whose host publishes no robots file at all, rather than permitting this explicitly like the others, so it is off by default and the choice is left to you.

Output

recordType tells the records apart: TREND (one per topic per source), CROSS_PLATFORM, GEO_SPREAD, WATCH (one per watched term), and one SUMMARY carrying which sources answered, the signal distribution, the observed scale per source, the history statistics, and the caveats above.

If fewer than half the enabled sources answer, the run fails rather than quietly presenting single-source results as cross-platform findings.