Apify Google Trends Scraper: what a run costs
Apify's Google Trends Scraper (apify/google-trends-scraper) returns interest over time, interest by subregion and city, related queries, and related topics for the search terms you hand it. Since 2026-06-30 it bills per dataset row: $0.003/result subject to change · verified 2026-09-09 on the free plan and $0.001 on Starter, plus the platform compute each run burns.
Everything below was checked against Apify's own API and Store listing on 2026-09-09. Numbers move; the dates tell you how stale this page is when you read it.
What does a run actually cost?
Two separate meters run at once. The developer charges you per result, and the platform charges you for the machine.
Meter 1, the result fee. The Actor's price schedule that started 2026-06-30 charges one event per row in the default dataset, discounted by your subscription's Store tier:
| Your plan | Store tier | Per result | Per 1,000 results |
|---|---|---|---|
| Free | — | $0.003 | $3.00 |
| Starter, $19/mo | Bronze | $0.001 | $1.00 |
| Scale, $199/mo | Silver | $0.0005 | $0.50 |
| Business, $999/mo | Gold | $0.0003 | $0.30 |
Plan prices from apify.com/pricing; per-result prices from the Actor's own record at api.apify.com/v2/acts/apify~google-trends-scraper, both fetched 2026-09-09. The schedule also carries PLATINUM ($0.00015) and DIAMOND ($0.0001) tiers, but the public pricing page lists no plan that maps to them, so treat those as enterprise-only until Apify sales tells you otherwise.
Meter 2, the compute. Most pay-per-event Actors fold platform usage into the event price. This one does not: its API record sets isPPEPlatformUsagePaidByUser: true, and Apify's docs confirm that "some Actors may require you to pay for platform usage separately".
The arithmetic, using the Actor's default run options (4,096 MB of memory) and the free/Starter rate of $0.20 per compute unit, where one unit is 1 GB of RAM for one hour:
- 4 GB for one hour = 4 CU = $0.80
- 4 GB for ten minutes = 0.67 CU = $0.13
So on a small job the machine costs more than the data. A ten-minute run returning 100 rows on Starter is about $0.10 of results against about $0.13 of compute. At 5,000 rows the result fee takes over. If you are budgeting, work out both lines, not just the one on the Store page. The Apify pricing guide explains how included usage and overage interact with this.
What happened to the $20/month rental?
The Actor's pricing history, straight from its API record:
| Date | Model |
|---|---|
| 2024-01-03 | $20/month rental, 7-day trial |
| 2026-03-03 | Pay-per-event, charging $0.00005 per Actor start |
| 2026-03-11 | Actor start plus a tiered per-result fee |
| 2026-06-30 | Per-result fee only, Actor-start charge removed |
This matters because the whole rental-versus-usage break-even calculation that older guides run on this Actor is now arithmetic about a model that no longer exists. Apify is retiring rental Actors platform-wide by October 2026, per the Store pricing docs. If a page still tells you this scraper costs $20 a month, it was written before March.
How do you configure a run?
These are the real input keys from the Actor's input schema tab, checked 2026-09-09, not a paraphrase of the form labels:
| Key | Default | What to watch |
|---|---|---|
searchTerms | none | Required, unless you pass startUrls or spreadsheetId instead |
isMultiple | off | Treats a comma inside a search term as a separator for multiple terms |
timeRange | Past 12 months | customTimeRange takes YYYY-MM-DD YYYY-MM-DD and overrides it |
geo | Worldwide | Changes which fields you get back: Worldwide returns interestBy, a small country returns only interestByCity, a large one adds interestBySubregion |
viewedFrom | none | Sets the country used for residential proxies ("Country for residential proxies to ensure correct results"), not the geo of the data |
category | All categories | Narrows to a vertical |
startUrls | none | Paste Trends URLs directly. Geo encoded in a URL wins over the geo field |
spreadsheetId | none | Reads the term list from a public Google Sheet |
maxItems | 0, no limit | Set this on your first run or the invoice is open-ended |
maxConcurrency | 10 | Trends rate-limits. Lower it before you widen the geo |
maxRequestRetries | 7 | Retries cost compute even when they fail |
Keys and the first seven defaults come from the Actor's input schema tab; the concurrency and retry defaults are stated in its Store README. There is also a pageLoadTimeoutSecs control if pages are stalling rather than erroring.
Run one term, one geo, and maxItems: 25 first. Read the usage breakdown on the finished run, then scale. That single capped run costs a few cents and tells you the row count per term, which is the number the cost table above depends on.
Why do a quarter of runs time out?
Apify publishes 30-day run statistics for every public Actor. Here is what this one reported on 2026-09-09, across 21,724 runs:
| Outcome | Runs | Share |
|---|---|---|
| Succeeded | 13,590 | 62.6% |
| Timed out | 5,515 | 25.4% |
| Aborted | 2,071 | 9.5% |
| Failed | 548 | 2.5% |
Source: publicActorRunStats30Days at api.apify.com/v2/acts/apify~google-trends-scraper. Roughly one run in four ends on the clock rather than on the data, and the Store's 3.68-star average across 32 reviews is consistent with that.
The API does not say why, and neither will this page. What it does say is that the Actor's default run timeout is 604,800 seconds, a full week, so a timed-out run is one where somebody set a shorter limit and the job did not finish inside it. Google Trends rate-limits aggressively, and the default maxConcurrency of 10 pushes into that.
Compute is billed per GB-hour consumed, not per successful result. A run that grinds for six hours at 4 GB and then times out has already spent about $4.80 on Starter and hands you a partial dataset. Three defences:
- Cap the work with
maxItems, and split long term lists across several runs instead of one heroic one. - Drop
maxConcurrencyto 2 or 3 for a wide geo or a longcustomTimeRange. Slower runs that finish beat fast runs that die. - Set an explicit run timeout in the Console. A one-hour ceiling turns a runaway job into a $0.80 mistake instead of a $4.80 one.
Can you compare the numbers from two different runs?
No, and this is the mistake that quietly ruins weekly trend dashboards.
Google's own documentation describes the scaling: "Each data point is divided by the total searches of the geography and time range it represents" and "the resulting numbers are then scaled on a range of 0 to 100 based on a topic's proportion to all searches on all topics." The 0-100 index is relative to the window you asked for. Monday's run and next Monday's run each rescale to their own maximum, so appending them and plotting value over time produces a chart of two unrelated scales sitting next to each other.
Two ways around it:
- One long window instead of many short ones. Re-run
customTimeRangeacross the whole period each time and overwrite the dataset. Every point is then scaled against the same denominator. - Carry an anchor term. Include one stable, high-volume keyword in every run with
isMultipleso all terms in that request share a scale, then normalise each week's numbers against the anchor. This follows from the scaling rule above rather than from a documented Google feature, so validate it on two overlapping runs before you build reporting on it.
Google also notes that Trends uses "only a sample of Google searches". Low-volume keywords will wobble between runs no matter how you schedule them.
Should you use Google's official Trends API instead?
Sometimes yes. Google opened a Trends API in alpha and, as of 2026-09-09, it is still application-gated: "we're prioritizing developers that know what they want to do, that can start doing it soon, and that are willing to provide feedback." It offers a rolling five-year window, daily through yearly aggregation, and consistently scaled data that can be compared across requests, which is exactly the limitation described in the previous section.
| Route | Access | Cross-request comparable | Cost | Maintenance |
|---|---|---|---|---|
| Google Trends API (alpha) | Application, no guaranteed timeline | Yes, by design | Free while in alpha | Google's |
| Trends UI, CSV export | Immediate | No | Free | Yours, manual |
| Apify Actor | Immediate | No, without an anchor | $0.30-$3.00 per 1,000 rows plus compute | Apify's |
| Your own browser scraper | Immediate | No | Proxies plus your time | Yours, and Trends changes often |
Read that honestly. If you need three keywords once a quarter, the CSV export in the Trends UI costs nothing and this Actor is overkill. If comparability across months is the whole point of your project, apply for the alpha and wait. The Actor earns its fee when you need scheduled, geo-segmented pulls into a dataset today, without babysitting a browser fleet.
What comes back in the dataset?
Field names as listed on the Actor's Store README, checked 2026-09-09. Row shape varies with your input, so inspect your first capped run rather than coding against this table blind:
| Field | What it holds |
|---|---|
interestOverTime_timelineData | Timeline entries with time, formattedTime, value, hasData |
interestBySubregion | Region-level index, with geo code and region name |
interestByCity | City-level index where Google has enough volume |
relatedTopics_top | Topic entries with mid, title, value |
relatedQueries_top, relatedQueries_rising | Breakout and top related searches |
Export as JSON, CSV, or Excel from the run's Storage tab, or pull items with the Apify API for anything automated.
How do you schedule weekly snapshots?
Save the input as a Task, attach a Schedule, and let each run write its own dataset. The Tasks and Schedules guide covers the setup, and the Google Sheets integration will append each run for you if the destination is a spreadsheet rather than a database.
One caveat before you fan out across many scheduled Actors: Apify's two tier-1 sources disagree about free-plan concurrency. apify.com/pricing lists 5 maximum concurrent runs on the free plan, while docs.apify.com/platform/limits lists 25 in the same row of its limits table. Both fetched 2026-09-09. Plan for 5, because a queued run costs nothing but a rejected one breaks your schedule. Paid plans agree across both pages: 32 on Starter, 128 on Scale, 256 on Business.
The free plan carries $5 of monthly usage, which is enough for several capped runs of this Actor. Set maxItems: 25, run one term, and read the usage breakdown before you commit to a schedule.
Open the Google Trends Scraper
When Trends is the wrong signal
Trends gives you a normalised index, never a search volume. If your question is "how many people search this," you need a keyword tool, not this Actor. If it is "which of these two terms is rising faster in Germany," Trends answers it well. Pair it with Google SERP data when you need to know who is actually ranking for the rising term, and see market intelligence for how the two feeds combine. If you would rather build the pipeline yourself, Build an Actor is the starting point.
Two charges. The result fee is $0.003 per dataset row on the free plan, $0.001 on Starter, $0.0005 on Scale and $0.0003 on Business, per the Actor's pricing schedule dated 2026-06-30. On top of that you pay platform compute, roughly $0.13 for a ten-minute run at the Actor's default 4 GB of memory on the $0.20/CU plans.
No. It ran as a $20/month rental Actor from 2024-01-03 until 2026-03-03, when it moved to pay-per-event. Apify is retiring the rental model platform-wide by October 2026.
Timeouts are the Actor's most common non-success outcome: 5,515 of 21,724 public runs in the 30 days to 2026-09-09, or 25.4%. Cap the job with maxItems, lower maxConcurrency from its default of 10, shorten the time range, and set an explicit run timeout so a stalled run cannot burn compute for hours.
Not directly. Google scales each result set from 0 to 100 within the geography and time range you requested, so two runs use two different denominators. Either re-run one long custom time range each time, or include a stable anchor keyword in every run and normalise against it.
Yes, in alpha and application-gated as of 2026-09-09. It returns consistently scaled data over a rolling five-year window, which the scraped 0-100 index cannot match. Apply at developers.google.com/search/apis/trends if cross-request comparability matters more than shipping this week.
Save your input as a Task, attach a Schedule, and route each run's dataset to storage, Google Sheets, or your database through the Apify API. Read the scaling caveat above before you chart the results week over week.