Google Trends series by term, geo and time window, as flat rows

Google Trends as Excel-ready rows: interest over time, interest by region, related queries. One flat row per data point, each with a stable id. $0.25 per 1,000 rows.

	This actor	Official Google Trends actor
Price	$0.25 per 1,000 rows	$0.30 per 1,000 rows
Output shape	Flat rows, one per data point, stable id	Nested timeline arrays
On a Google 429	Session rotates and the run continues (observed in our soak runs, see Reliability)	Not documented
Failed or timed-out runs, last 30 days (public store stats, 2026-09-09)	Not enough public runs yet; listing is new	27% (5,996 of 21,833)
Empty related topics	Zero rows, zero charge, run succeeds	Not documented

Try it for free

{
  "searchTerms": ["coffee"],
  "outputs": ["interestOverTime", "relatedQueries"],
  "geo": "US",
  "timeRange": "today 12-m"
}

Measured on 2026-09-09 (run ef6NeMf4qBi5flDSI): 53 interest-over-time rows and 50 related-query rows, 103 rows, $0.026 at $0.25 per 1,000. Row counts vary by term and range.

Example output rows

{
  "type": "interestOverTime",
  "term": "coffee",
  "geo": "US",
  "timeRange": "today 12-m",
  "time": "2025-09-07T00:00:00.000Z",
  "formattedTime": "Sep 7 – 13, 2025",
  "value": 58,
  "isPartial": false,
  "fetchedAt": "2026-09-09T06:39:34.060Z",
  "id": "b3790555d1acb5d3"
}

{
  "type": "relatedQueries",
  "term": "coffee",
  "list": "top",
  "rank": 1,
  "query": "coffee shop",
  "value": 88,
  "formattedValue": "88",
  "link": "/trends/explore?q=coffee+shop&date=today+12-m&geo=US",
  "fetchedAt": "2026-09-09T06:39:34.060Z",
  "id": "172b002ab25dde86"
}

What you get

Every dataset row carries type, term, fetchedAt (ISO timestamp), and a stable id (a hash of the row's type, term, and time/location/query key, so the same logical data point always gets the same id across runs).

interestOverTime

Field	Description
term	The search term this row belongs to
geo	Geo filter used for the request ("" = worldwide)
timeRange	The time range or custom range used for the request
time	ISO 8601 timestamp of the data point
formattedTime	Google's human-readable label for the point (e.g. "Sep 7 – 13, 2025")
value	Relative search interest, 0-100
isPartial	True when Google flags this point as incomplete (usually the most recent point)

interestByRegion

Field	Description
term	The search term this row belongs to
geo	Geo filter used for the request
resolution	COUNTRY, REGION, CITY, or DMA
geoCode	Google's code for the region (e.g. US, US-CA)
geoName	Human-readable region name
value	Relative search interest in that region, 0-100

relatedQueries

Field	Description
term	The search term this row belongs to
list	top or rising
rank	0-based position within its list
query	The related search query
value	For top: 0-100 relative popularity. For rising: percentage growth, capped at 5000 to represent "Breakout"
formattedValue	Google's display string (e.g. "100" or "Breakout")
link	Relative Google Trends explore URL for that query

What to expect from rising: for broad terms over long ranges Google's own rising list mixes in loosely related breakout queries (for air fryer over 12 months it lists hotel booking and noise cancelling headphones next to ninja crispi pro air fryer). That is what Google serves, identical through residential proxies, not a scraping artifact; the top list is always on-topic. Filter rising rows by shared words with your term if you need a tight list.

relatedTopics (opt-in, best effort)

Same row shape as relatedQueries, with topicTitle, topicType, and topicMid (Google's topic identifier) in place of query.

As of September 2026, Google returns an empty related-topics list to most automated sessions even for mainstream terms, while related queries keep working. The actor requests topics only when you select this output in outputs, reports zero rows without failing the run when Google returns none, and does not charge for rows it did not return.

Want the file instead of running the actor? A Google Trends export for your keywords is $10, made to order, at https://tallyrake.com/files (CSV and XLSX by email within 24 hours of your order details).

Time ranges and geo codes

timeRange accepts Google Trends' own presets: now 1-H, now 4-H, now 1-d, now 7-d, today 1-m, today 3-m, today 12-m (default), today 5-y, or all (2004-present). Set customTimeRange to a specific window instead, formatted "YYYY-MM-DD YYYY-MM-DD" : this overrides timeRange when set.

geo takes a two-letter country code (US, GB, DE, ...), a country-region code (US-CA, US-NY, ...), or an empty string for worldwide. Region codes follow Google's own Trends explorer, which follows ISO 3166.

How results are counted for pricing

Every pushed dataset row (one interest-over-time point, one region, one related query, one related topic) is one result. A single run over N terms and M output types produces roughly N × (points-per-timeseries + regions-per-geo-map + related-queries-found + related-topics-found), which varies by term and how much data Google has for it. Related queries/topics commonly return 0-50 rows per list; interest-by-region at COUNTRY resolution returns around 250 rows (one per country), and narrower resolutions return more.

Recipes

Compare three terms on one scale

Put three products or brands on the same 0-100 axis instead of three separate scales.

{
  "searchTerms": ["coffee", "tea", "matcha"],
  "compareTerms": true,
  "outputs": ["interestOverTime"],
  "geo": "US",
  "timeRange": "today 12-m"
}

Row count and cost: estimate, roughly 150-160 rows (about 52 weekly points per term over 12 months), well under $0.05. No real run at this exact input yet.

US interest plus rising queries as CSV

Pull one term's trend line and what people are searching alongside it, then hand the dataset straight to a spreadsheet.

{
  "searchTerms": ["coffee"],
  "outputs": ["interestOverTime", "relatedQueries"],
  "geo": "US",
  "timeRange": "today 12-m"
}

Measured on 2026-09-09 (run ef6NeMf4qBi5flDSI): 53 interest-over-time rows and 50 related-query rows, 103 rows, $0.026. On the run's Dataset tab, use the Export button and choose CSV. To pull it by URL instead: https://api.apify.com/v2/datasets/<datasetId>/items?format=csv, where <datasetId> is the run's dataset ID from the Console or the API response.

My last Trends tool returned 429 : try this input

A shorter window, one term, and paced requests so a rate limit does not end the run.

{
  "searchTerms": ["coffee"],
  "outputs": ["interestOverTime", "relatedQueries"],
  "geo": "US",
  "timeRange": "today 3-m",
  "pacingMs": 500
}

Row count and cost: estimate, in the range of the 103-row run above, under $0.05. This works because each search term gets its own session that rotates on a real 429 and retries with backoff (six attempts, about 1 s to 45 s). Measured 2026-10-06 on the platform, 15 terms, US, 3 months, concurrency 3: 13 of 101 requests were rate-limited by Google and every one recovered, 15 of 15 terms delivered (2,813 rows).

No Apify Console feature prefills an actor's input from a URL for a stranger to click through (checked docs.apify.com, September 2026); copy the input above into the Input editor by hand.

Advanced options

• searchTerms accepts 1 to 5 terms per Google Trends comparison; more than 5 are automatically batched into separate comparison calls of up to 5.
• compareTerms (default off): when enabled, all search terms in a comparison are sent together so their values are relative to each other (one term is the 0-100 anchor). Off by default, each term is scored independently on its own 0-100 scale.
• maxConcurrency (default 2, max 3): how many search terms are processed in parallel. Higher values finish faster but raise the chance of Google 429s.
• requestsPerSession (default 8): reuse a Trends session for this many successful requests, then rotate. A session still rotates immediately on a real 429, regardless of this setting.
• proxyConfiguration (default: Apify Proxy on): Google Trends rate-limits by IP. Using Apify Proxy is strongly recommended for any run beyond a couple of terms.
• category, searchType, and regionResolution narrow the request to a Google Trends category, search vertical (web/images/news/YouTube/Shopping), and region granularity.
• fetchMode is http by default. browser is the fallback described under Fallback mode. Leave it on http unless HTTP runs start failing.

Coming from pytrends or google-trends-api?

Two symptoms bring people here.

Related queries come back empty. google-trends-api's own issue tracker reports an empty rankedList for related queries (pat310/google-trends-api#174, open since 2025-02-19), and pytrends has been archived since August 2024, so neither library will be fixed upstream. The current widget protocol (an explore call, then a per-widget token, then the relatedsearches call) still returns data. This actor uses the current protocol; the relatedQueries rows in the example above came from a real run on 2026-09-09. Related topics are different: Google returns an empty list to automated sessions for that widget, so it is opt-in and never charged when empty.

HTTP 429 (too many requests). Two 429s get mixed up. The first request to trends.google.com/trends/explore always answers 429 while it sets the NID cookie; that one is harmless if the cookie is kept. The real rate limit hits the /trends/api/ calls when one IP or session makes too many requests in a short window. This actor keeps a session, rotates it on a real 429, retries with backoff, and continues with the other terms; a run fails only if every term fails. In our test runs on 2026-09-09 every term completed from both a home IP and Apify datacenter proxies. On datacenter, version 0.1.2 saw 7 real 429s in 28 requests, all recovered by session rotation; version 0.1.11 (fresh session per term, paced requests) saw 0 real 429s in 30 requests across two runs of 15 on the same input. Expect occasional retries rather than failures.

Reliability

If one optional slice (regions, related queries, related topics) is still blocked after retries, the run keeps the rows that landed, succeeds, and names the terms and the missing slice in its status message instead of failing (since 0.1.20). residentialForRelated (off by default) fetches the related slices through residential proxy identities when a set of terms keeps hitting that limit.

Sessions rotate automatically on a Google 429 response and retry with exponential backoff (1s, 2s, 4s, capped, up to 5 attempts). If a search term still fails after all retries, that term's failure is logged and the run continues with the remaining terms; the run fails outright only if every term fails.

Fallback mode

fetchMode defaults to http. That is the path the rest of this README describes, and it is unchanged.

Set fetchMode to browser only if Google changes the widget protocol or starts answering plain HTTP clients with a JavaScript challenge. Browser mode opens one headless Chromium page per term (or per compare-group of up to 5) at https://trends.google.com/trends/explore?q=<terms>&geo=<geo>&date=<range>&hl=en. It accepts the Google consent page when that page is shown, then reads the JSON the page itself requests from /trends/api/explore and /trends/api/widgetdata/*. Those bodies go through the same parsers as HTTP mode, so the dataset rows have the same fields and the same stable id.

The first response from the explore document is often HTTP 429. That response sets the NID cookie (the same handshake the HTTP client already counts separately from real rate limits). Browser mode reloads the page once after that 429. A page that still never yields an explore response fails that term after retries. A term whose optional slice (regions, related queries, related topics) is missing from the page traffic keeps the rows that did parse, and the run still succeeds. The run fails only when every term fails. The cost-limit guard is the same one HTTP mode uses.

Give a browser run at least 2 GB of memory. The actor does not raise its minimum memory, so HTTP runs are not forced onto that size. requestsPerSession and residentialForRelated are HTTP-mode knobs: the browser loads every widget on one page through proxyConfiguration, and each term gets a fresh browser session. regionResolution does not drive the map. Rows are labeled with the resolution on the captured map request, which is the granularity the explore page chose for that geo (for a US page, that is the state map).

Platform cost is per term, not per row, because the page loads either way. Planning figure at 2 GB and about 6 seconds per term (the measured page was 5.0 seconds, plus the default pacing gap): about $0.0007 of compute per term. On residential proxy, add about $0.004 for the measured 0.48 MB of traffic, so about $0.005 per term all-in. Datacenter proxy (the default) has no per-term traffic charge. The $0.25 per 1,000 rows event price is unchanged. The arithmetic is in BUILD-NOTES-BROWSER.md.

Bigger jobs

Running thousands of trend series, or need this as a one-off file instead of a run? We build custom exports — any keywords, countries and date ranges, delivered as flat CSV or JSON within 24 hours: https://tallyrake.com/datasets/

Limitations

• Google Trends values are relative, not absolute: 100 marks the peak popularity for the selected term, time range, and geo : not a fixed volume of searches.
• With compareTerms enabled, all terms in that comparison share one 0-100 scale relative to whichever term peaks highest; with it disabled (default), each term is scored independently and values are not comparable across terms.
• Google does not guarantee availability or consistency of historical data, and can change or withdraw related queries/topics for a given term with no notice.
• Very low-volume terms may return empty or partial results, particularly for interestByRegion.
• relatedTopics is frequently empty for automated sessions (see above); rely on relatedQueries for keyword expansion.

Support

Questions or issues: ops@tallyrake.com

Cost limit

If a run reaches the "Maximum total charge per run" you set, it stops in process rather than being aborted by the platform: the run ends with status SUCCEEDED, and the run status message on the run detail says how many rows were written and how many were found but not written and not billed. Re-running the same input writes and bills the same prefix again, so raise the cap before re-running if you want the rest.