Never charged for an empty result. Breakout and rising search queries from Google Trends with the real growth percentage behind Google's Breakout label, plus current interest and the 12-month curve — by seed keyword, country and category.
A run that runs out of time now stops cleanly, and a cost-capped run counts the seed it cut.
A run close to its time limit now stops itself rather than being cut off mid-request. A seed that had just enough time left to start could be killed by the platform partway through, ending the run without its status. The run now declines to start a fetch — or to wait out a rate-limit cooldown — that it cannot finish in time. It ends successfully with everything already delivered still delivered and charged, and the seeds it did not reach reported as left. Running out of our own time is never blamed on Google: no error is recorded and no "Google did not answer" row is written for a seed that was never actually asked.
A cost cap that cuts a seed mid-list now counts that seed as left to do. When your maximum cost per run stopped the last seed partway through its list, the status said "0 seed(s) left" — while telling you to raise the cap to fetch everything. A cut seed is genuinely unfinished (re-running it returns its full list), so it is now counted, and the number and the advice agree.
Related topics: the answer in the FAQ was out of date. It said Google's related-topics feed was returning empty data platform-wide. That is no longer true — the surface is delivered by the sibling actor Google Trends · No Charge on Miss , and the FAQ now points there.
1.0.11 — 2026-08-29
A typo in an input field name now gets a helpful pointer instead of sample rows. When a run
configures something but no search terms reach the actor — a misspelled field name, or settings
with the keyword list left out — you get one uncharged row that names the field it did not
recognise and the field it needed, rather than the sample output.
Running the actor with genuinely no input still returns the sample rows, exactly as before.
Added a live example dataset to the README: 12 rows from a verified run, including one seed that
returned nothing and was not charged.
1.0.10 — 2026-08-27
Hardening in the shared Google Trends engine this actor is built on: a reply that comes back
valid but empty is now recognised as Google declining the request rather than accepted as a
genuine empty answer, on every surface the engine can read. Such a reply is retried, and an
answer that never arrives is reported as an uncharged miss. Rising and Breakout queries — the
surface this actor reads — already behaved this way, so its own output is unchanged.
1.0.9 — 2026-08-27
Initial release.
Seed keywords in, Google Trends rising and Breakout queries out, one row per query.
growthPercent on every rising row, including the ones Google labels only Breakout — the number
is in Google's payload and this actor ships it.
isBreakout reflects Google's own label and is never derived from the growth number.
Filters: breakoutOnly, minGrowthPercent, maxResultsPerKeyword, geo, timeRange,
category, and an optional 12-month curve per rising query (includeTimeline).
Seeds with no rising data, seeds whose rows your filters removed, and fetches Google refused all
ship as uncharged rows carrying status and charged: false.
Running the actor with no search terms returns sample rows without fetching anything.
Every seed on your list is attempted. A stretch of seeds that simply have no rising data is an
answer, not a block, and no longer stops the run early with a rate-limit message.
The run message claims "Google blocked or refused every attempt" only when that is literally
what happened — seeds that answered with an empty list are reported as their own outcome.
If the run ever breaks in an unexpected way it stops with a plain explanation and an ERRORS
record instead of a bare crash: rows already delivered stay in your dataset, and nothing
undelivered is charged.
A run that is interrupted and continues elsewhere, or that you resume after it has finished,
never charges you twice for a keyword you already have and never adds a duplicate row. It
carries on with the seeds it had not reached yet, and the closing message describes the whole
run rather than only the part after the interruption.
A run's own time limit covers the whole run, so resuming one no longer restarts its clock.
In the rare case where a resumed run cannot check what it already delivered, it stops instead
of guessing, charges nothing further, and tells you to re-run.
