Export Google Trends interest over time, regions, related queries, rising searches and Trending Now topics. Schedule a keyword watchlist to track new rising and Breakout signals. No Google account or source API key is needed.
CSV exports of API and scheduled runs keep every column again. Rows are now
stored in smaller row_page items of a few dozen rows, because Apify's CSV
export dropped nested columns such as source_scaling_context/... from
larger pages. Rows, their order, JSON exports and prices are unchanged.
Larger runs stored by 1.10.13 and 1.10.14 keep their old pages: export those
as JSON with unwind=rows if you need every field.
When the spending limit stopped a Trending Now feed at delivery, the run
summary counted it as delivered while its status row said FAILED
(BUDGET_LIMITED). The summary now agrees with the row. This was rare: the
limit is usually checked before the feed is fetched.
Documentation
New Output contract
section: record types, the fields on every row, identifiers, order, paging,
and the promise that fields, record types and values are only added.
New "In development" section in the README, without dates.
2026-10-11: Compact storage for large exports (1.10.14)
Changes
API and scheduled runs now store rows in compact row_page items, up to
500 rows each, instead of one Dataset item per row. Every row keeps its fields and order.
The Output tab, the run's results link and any API request or export with
unwind=rows return the same flat rows as before.
Action needed only if your integration reads raw Dataset items: add
unwind=rows to the request, or set the new input datasetFormat to flat
to keep one item per row. limit and offset count stored items, so do not
page with unwind=rows: read the run in one request, or page through raw
items and read each page's rows.
Runs started in Console or by AI agents through Apify MCP or Apify AI keep
one item per row unless the input sets datasetFormat: Console's Export
button and the MCP dataset tool read stored items as they are.
If you imported the n8n Google Sheets workflow from this page before
October 11, 2026, import it again or set datasetFormat to flat: the
old copy reads raw items and would report no changes for compact runs.
The previous version stays available as build old until November 10,
2026: pass build=old in the API, or choose it under Run options > Build in
Console. It is the unchanged 1.10.12 build: one item per row, and it rejects
inputs that contain datasetFormat.
Prices are unchanged and still follow rows, not stored items: a group
includes its first 250 rows, and from October 20, 2026 each further row
costs $0.00002 in either format.
Known issue
Found after this release: a CSV export with unwind=rows of a larger API
or scheduled run can miss nested columns, such as source_scaling_context/...
and source_metadata/.... Top-level columns, JSON exports, the Output tab,
runs started in Console and the n8n workflow are complete. If you need every
column in CSV, set datasetFormat to flat for those runs. A fix is in
development.
2026-10-10: Short batch runs finish in time (1.10.12)
Fixes
A batch run with a short timeout, for example 20 keyword groups in 12-15
seconds, could be stopped by Apify as TIMED-OUT after its time ran out.
Once the run is stopping it no longer writes a progress summary for every
remaining group, so it finishes about a second earlier and keeps its final
summary and all rows.
2026-10-10: A refused check no longer fails your run (1.10.11)
Changes
When Google refuses or does not answer any check in time, the run now ends
SUCCEEDED instead of FAILED. Nothing changes in the data: every check
is still a group_status row with status FAILED and its reason
(THROTTLED, SOURCE_UNAVAILABLE or RUN_DEADLINE), never a zero, and
it is not charged. The status message says Google gave no data and, for a
short timeout, what would help. Read each group's status before using
the results.
Action needed only if your integration retries failed runs: set the new
input failRunOnRefusal to true to keep the previous behavior.
A changed Google response format or an error in the Actor still fails the
run.
Fixes
A run whose timeout ends before the proxy connection is ready now reports
its checks as RUN_DEADLINE rows, and can still deliver your cached
result, instead of a proxy error that asked you to check your proxy
access. No request is sent without the proxy.
2026-10-06: Large repeated batches stay within memory (1.10.10)
Fixes
A large batch that you run again in snapshot mode no longer loads every
cached result into memory at the start. Before, a repeat of up to 200
five-keyword groups with every data type could run out of the 512 MB
default memory. Small batches and single checks work exactly as before.
2026-10-06: Pricing for very large exports (1.10.9)
Pricing
From October 20, 2026, 22:18 UTC, a completed keyword group still costs
$0.004 and includes its first 250 data rows; each further row in the same
group costs $0.00002 (1,000 extra rows: $0.02). Most groups, with one or a
few data types, stay under 250 rows and cost the same as before. Trending
Now stays $0.002, and failed or partial groups remain free. If a run's
spending limit cannot cover a whole group, that group is not charged and is
marked BUDGET_LIMITED.
2026-10-06: Steadier cached results (1.10.8)
Fixes
When your result cache opens slowly, the run now simply continues without
it. Before, a slow cache could interrupt a run after Google had already
answered.
A damaged cache record that claims a result but holds no rows is ignored, so
a refused check stays an honest FAILED instead of an empty success. A
verified "no data" result is still delivered from the cache as before.
2026-10-05: More time for Google in short runs (1.10.7)
Improvements
A run now asks Google first and opens its result cache in the background.
Before, the cache store was opened before the first request, which took a
short run about half a second it needed for Google.
Cached results are read in the background at the start of the run, so a
check Google refuses in the last seconds of a short run can still get your
last verified result. Before, that read had less than a second and could
miss.
Fixes
A gracefully aborted run is reported as aborted even when it delivered a
cached result, and keeps rows a check had fully collected when the abort
arrived.
If saving a cached result fails part way, the saved rows are counted and
the run reports the write error, instead of adding a second, failed status
for the same group.
2026-10-04: Safer cached results and charges (1.10.6)
Improvements
When Google refuses most checks of a batch but some are verified, the run
now succeeds with those results instead of failing. The status says how
many checks were verified (for example "2 of 20 checks verified (10%)"),
every refused check stays a FAILED row, never a zero, and monitoring
state is not advanced. A batch without a single verified check still fails.
A graceful abort now stops the run within seconds: no new requests to
Google, unfinished checks are marked RUN_ABORTED, everything already saved
stays with its charge, and the final run summary is written.
Fixes
A keyword group or Trending Now feed is now charged only after its status
row and observations are saved. If a write fails or the run is stopped in
between, you keep what was saved and are not charged for that group.
A group your spending limit cannot cover now shows BUDGET_LIMITED with
nothing charged, instead of a status row without its observations.
A damaged record in the google-trends-monitor-cache store is now skipped,
and the check keeps its normal status, instead of failing the whole run.
Cached rows now carry the externalId of the run that delivers them, not
the one of the earlier run that verified them.
The cache never uses the last seconds a run needs to write its results, and
one slow or failed store call switches it off for the rest of the run, so a
large batch cannot wait on a slow store group after group.
2026-10-03: The last verified result when Google refuses (1.10.5)
Features
When Google refuses a fresh check for a few minutes, which a run with a
short timeout cannot wait out, the Actor now delivers your account's last
verified result of the same check instead of failing the run. Every such row
keeps its original time, is marked CACHED with its age, and the group is
not charged. Results up to 24 hours old are used (less for hourly
timeframes, never for the last hour or four hours), in snapshot mode only.
Set cachedResultOnRefusal to false to get a failed status instead.
2026-10-03: Slow connections work again in short runs (1.10.4)
Fixes
Version 1.10.3 gave each connection in a short run at most half of the
remaining time. When the proxy connections themselves were slow (six seconds
or more to open), every attempt was cut and the run failed, although the same
run finished in time on 1.10.2. That limit is removed, and timeouts are
reported as before. Short runs again get every retry that fits in their
timeout.
2026-10-02: A stuck connection no longer uses up a short run (1.10.3)
Fixes
In runs with a short timeout, one slow or stuck proxy connection could take
all the remaining seconds, so the retries never happened. Opening a
connection and waiting for its answer now each get at most half of the time
left (never less than 5.5 seconds, which covers normal slow connections); a
stuck one is closed and the next attempt starts on a new connection. Runs
with longer timeouts are unchanged.
When a check fails because its connections kept timing out rather than
because Google refused it, the result now reports a timeout instead of rate
limiting.
2026-10-01: More retries for runs with a very short timeout (1.10.1)
Fixes
Runs with a timeout under about two minutes, for example 25 seconds from an
API integration, now spend their remaining seconds on several quick retries
through different connections when Google refuses a request. Previously such
a run tried twice and failed.
Improvements
When a short run still fails because Google refused it or the time ran out,
its status message names the timeout and suggests 300 seconds or more, which
lets the Actor wait out most refusals. A failed group is still not charged.
2026-10-01: Steadier recovery for short timeouts, watchlists and comparisons (1.9.1)
Fixes
Runs with a timeout between about two and three and a half minutes now use
all of their remaining time to wait out a Google refusal. Previously a run
with 179 seconds left gave up after about a minute, while one with 181
seconds kept trying.
When several keyword groups were refused at the same time, they used up the
shared retry allowance within about three minutes and all failed. Retries
are now spaced further apart, so every group keeps a try for the end of the
refusal wave. The total number of requests is still capped.
In a comparison of several keywords, one refused keyword no longer stops the
others: each remaining keyword is still checked once, and its related
queries are delivered. The comparison is still reported as partial and is
not charged until every keyword is complete.
2026-10-01: Riding out Google's refusal waves (1.8.1)
Improvements
Google sometimes refuses related-query requests for a minute or more, for
every connection at the same moment. Switching to a new connection does not
help during such a wave, but waiting does. With the default run timeout the
Actor now keeps retrying a refused request for up to five minutes instead of
three, and with a 300-second timeout for up to three minutes instead of two.
The number of attempts is unchanged, and they are spaced further apart. A
group that is still refused is reported as failed and is not charged.
Runs with a timeout below about three and a half minutes keep the previous
one-minute window. If you use related queries on a schedule at the top of the
hour, the default timeout gives the Actor the most room to recover.
2026-09-29: Longer recovery when Google refuses a group's first request (1.7.1)
Improvements
When Google refuses the first request for a keyword group, the Actor now
spreads its retries over the same recovery window it already uses for
timeline, regional and related-query data, instead of giving up within about
a minute. The number of attempts is unchanged. A group that is still refused
is reported as failed and is not charged.
A failed run that your input cannot fix now asks you, in its status message
and at the end of its log, to open an Issue with the link to the run. Apify
then shares that run with me automatically, so there is no need to paste your
input.
The RUN_SUMMARY record now states why a run or check failed (for example
rate limiting, a timeout or the run's own time limit), counts checks by
outcome and records the run's timeout and memory. Your keywords are not
included.
The status message shows what the run is checking while it works.
2026-09-28: Where to report a failed run (1.6.1)
Improvements
When a run fails for a reason you cannot fix in your input, for example Google
refusing every request or the proxy not connecting, its status message now
ends with a link to this Actor's Issues tab. Paste the message and the run ID
into an Issue so the failure can be matched to its cause. Runs rejected for
invalid input or proxy settings keep their correction message without the
link. Run statuses, results, charges and monitoring state are unchanged.
2026-09-27: Retry after redirected requests, startup and storage recovery (1.5.1)
Improvements
Google sometimes redirects a request from one connection instead of answering
it. The Actor still never follows such redirects, but it now repeats the
request through a new connection, as it already does for rate limits, instead
of failing the keyword group at once. A group that stays redirected on every
attempt is reported as failed and is not charged.
Calendar dates are checked before the platform starts a run.
Temporary failures reading or replacing storage records receive bounded
recovery. Dataset appends and charges are never blindly replayed.
An interrupted startup may resume only when a persisted marker from the same
build proves output has not begun. Once output might have started, restart
protection remains in force to prevent duplicate delivery or billing.
Fixes
A nonempty batch whose groups are all invalid returns explicit INVALID_INPUT
records and an ALL_INPUTS_INVALID summary, without querying Google, charging
or changing monitoring state. This is a completed validation report, not
collected data. Empty requests and invalid global settings still require
correction.
A final summary error no longer hides the original failure, and a temporary
failure to update advisory Console text does not discard a completed result.
2026-09-26: Reliable monitoring state and input checks (1.3.1)
Fixes
Rising queries now keep separate monitoring history for each seed keyword.
TOP rankings cannot overwrite rising-growth bands. Existing monitors establish
one fresh related-query BASELINE on their next successful check;
trending-topic history is unchanged. Failed checks do not advance this
migration.
Improvements
Repeated keywords within a comparison are collapsed ignoring case and
whitespace. Repeated groups with the same ordered keywords and settings are
reported as INVALID_INPUT, with their externalId preserved, and are not
requested or charged again.
Custom date windows are checked for real dates and chronological order before
contacting Google. A bad per-group date does not discard valid groups.
Documentation
Matching scaling-context IDs identify the same settings, but do not make
separately collected scores directly comparable. Relative date windows move,
and Google can sample and scale each request independently. Keep each request
as a separate snapshot when analyzing past results. Existing inputs, IDs and
monitoring events are unchanged.
2026-09-26: Distinct IDs for related queries in comparisons (1.2.1)
Fixes
Related Queries returned for different keywords in the same comparison now
have distinct source_id values, even when the related query text is
identical. This prevents separate observations from overwriting each other in
exports or integrations keyed by ID. Single-keyword IDs are unchanged. This
update does not change retries, pricing or monitoring event classification.
Migration
For older multi-keyword exports, match records using
source_scaling_context.id, keyword, related_type and related_query;
the old ID alone can be ambiguous. Existing stored rows are not rewritten.
2026-09-22: Fixes for interrupted runs (1.0.35 and 1.0.37)
Fixes
Some runs spent too long retrying Related Queries when Google would not
return that data. We've shortened the extra retry and moved timeline and
regional lookups ahead of it. If Related Queries still fails, you keep the
other results with a clear partial status. Your last complete monitoring
snapshot stays intact. Your existing Tasks and API inputs work as before.
Improvements
Added a short retry for temporary connection problems at startup. Persistent
connection failures are still reported before any checks are charged.
2026-09-18: Better handling of refused requests (1.0.33 and 1.0.34)
Improvements
Added a fresh connection attempt for Related Queries when ordinary retries
do not help. The 22 September update reduces the time spent on this step.
If Keywords and Comparison groups together exceed 200 groups, the first 200
can still run. The extra groups are marked as invalid.
Trending Now lists with more than 50 countries are caught by input validation
before a run starts.
Fixes
Fixed runs that described rejected search settings as a Google outage.
Results now explain which groups Google rejected.
2026-09-17: Catch blank keywords before starting (1.0.32)
Improvements
Empty or whitespace-only keywords in Comparison groups now show an input
error before the run starts, just like empty entries in the main Keywords
field.
2026-09-14: Keep useful results from larger runs (1.0.28)
Fixes
Fixed a case where a large batch was marked as failed even though timeline
and regional data had been collected. Missing Related Queries alone no longer
causes that outcome.
Improvements
Runs that reach their time limit after verifying at least one check can now
finish with the results collected so far. The summary shows which checks were
completed, partial or unfinished, so you can decide what to run again.
Retries also leave a pause between temporary Google refusals without fetching
successful results again.
2026-09-13: A dedicated regional results view
Features
Added an Interest by region view with region names, codes, keywords and
relative interest, including an indicator for unavailable data.
You can now use UK and UK regional codes in place of the corresponding GB
codes, or worldwide and global for a worldwide search.
Improvements
Added retry attempts for Related Queries within the existing time limit.
2026-09-11: Custom dates and settings for each group
Features
You can enter a date range such as 2025-11-01 2026-01-31 in the input form
or API. Each Comparison group can also have its own country, timeframe,
category and search property. A mistake in one group's settings affects that
group only.
Improvements
The run summary now distinguishes checks skipped at a time or spending limit
from actual source failures.
Fixes
Fixed valid Trends and Trending Now responses being rejected because their
response type was labelled incorrectly.
2026-09-09: Safer handling of spending limits and interruptions
Improvements
Completed groups are delivered as they finish, so a later error does not
discard data you've already received.
Errors in one group are isolated from other groups. Failed checks free up
their reserved budget for later work.
Interrupted monitoring runs keep the last complete snapshot. Restarting the
same interrupted run stops safely to avoid repeating potentially paid work.
Start a new run when you want to check again.
Fixes
Fixed delivery of the last paid group or feed when it reaches the spending
limit. A smaller remaining budget can still cover a Trending Now feed.
2026-09-08: Clearer results when Google asks us to wait
Improvements
Retries now coordinate their pauses instead of repeatedly requesting data
while Google asks the Actor to wait.
The run summary shows the outcome for each requested data type, making
incomplete results easier to spot.
2026-09-02: Updated connection defaults (1.0.13)
Improvements
Updated the default connection settings for keyword searches. Inputs using
automatic Apify Proxy settings pick up the new defaults without changes.
2026-09-01: First release (1.0)
Features
Collect timelines, regional interest, related and rising queries, Breakouts
and Trending Now topics. Use a snapshot for one-off research or monitor a
watchlist for new signals, then browse the results or export them to your
workflow.
Every group has a status, including partial and failed checks. Only fully
answered keyword groups and Trending Now feeds are charged.
To get these updates, use the latest build in your run or Task settings.
If you've pinned an older build, choose a newer one when you're ready to upgrade.
