Most "trend" products feel like magic boxes. Ours is deliberately boring and inspectable, because trust starts with a data source you can verify. Here is exactly how we collect what you see.
The source: a public RSS feed
We read Google's public Trends RSS feed for the US region. It is a public, aggregated signal — not anyone's personal data — and it gives us, per trending search: the keyword, an approximate search volume, a category, a representative news link and a publish time.
The cadence: every four hours
A scheduled job ingests the feed on a fixed 4-hour cycle. Four hours is a deliberate trade-off: frequent enough to catch fast-moving spikes, infrequent enough to avoid hammering a public feed or filling the database with near-duplicate snapshots. Each run upserts trends and records the exact moment we stored them.
Two clocks, not one
This is the detail that matters most. Every row carries two timestamps:
- Publish time — when Google reports the trend started rising (its pubDate).
- Collection time — when our system actually ingested the row.
We keep them separate because they answer different questions. "What is hot right now?" is a publish-time question. "What has my crawler freshly captured in the last 6/12/24/48 hours?" is a collection-time question. Conflating the two produces misleading freshness claims, so the trends table exposes both as independent filters.
Honest limitations
The feed reflects Google's coverage and ranking, which we do not control. Volumes are approximate. A 4-hour cadence means sub-hour micro-spikes can be missed. When a chosen window has no fresh rows, we say so and fall back to the most recent data rather than showing an empty table dressed up as "live".
None of this requires you to trust us blindly — it is meant to let you check.