Google Trends Intelligence
Pricing
from $3.00 / 1,000 google trends intelligence records
Google Trends Intelligence
Google Trends interest over time and related queries with trend direction, momentum, volatility, source proof, API output, scheduling, monitoring, and integrations.
Pricing
from $3.00 / 1,000 google trends intelligence records
Rating
0.0
(0)
Developer
Skootle
Maintained by CommunityActor stats
0
Bookmarked
1
Total users
0
Monthly active users
6 days ago
Last modified
Categories
Share
Google Trends Intelligence
Built by Skootle for reliable, decision-ready data.
TL;DR
- Pulls Google Trends interest over time and related queries for up to 5 keywords in one run, then ships three record types: raw
TREND_POINTrows, rankedRELATED_QUERYrows, and a per-keywordSUMMARYwith the trend maths already done. - Direction, volatility, momentum, peak and trough are computed for you. Direction comes from an ordinary least squares fit across the whole window, not from comparing the first and last reading.
- A block, a rate limit, or a captcha interstitial fails the run loudly with the HTTP status and a body snippet. It never returns as an empty dataset.
- A genuine no-match is marked explicitly with
zeroMatch: trueandsourceStatus: "ok", so you can tell "Google has no data" apart from "the scraper got shut out". - Built for people who feed trend data into decisions: SEO and content teams sizing demand, brand and product teams tracking interest curves, and agents that need clean numeric fields plus a prewritten
agentMarkdownsummary.
If this Actor saves you analysis time, share what worked on the reviews page. Report bugs through Issues so they can be fixed with source evidence.
What does this actor return?
Every run writes one dataset. Filter on recordType to split the three shapes. Every record carries recordId, schemaVersion, sourceName, sourceQueryUrl, trendsUrl, retrievedAt, fieldCompletenessScore and agentMarkdown.
trendsUrlis the human Google Trends chart for that exact query, so any number can be opened at source.sourceQueryUrlis the API URL the row came from.fieldCompletenessScoreis the percentage of scored fields populated, so you can filter thin rows without inspecting each one.agentMarkdownis a short prewritten summary of the row, for piping records into an LLM instead of a spreadsheet.
TREND_POINT
One row per keyword per time bucket. The rolling average and the change against the previous bucket are precomputed.
RELATED_QUERY
One row per related query, from either the top list or the rising list. Rising rows carry both the label Google printed and a parsed numeric growth, plus an explicit isBreakout boolean.
For listType: "top", relativeValue is a 0 to 100 index against the strongest related query, and growthPct is null. For a query Google labels Breakout, formattedValue is "Breakout", isBreakout is true, and growthPct is null because Google does not publish an exact figure above 5000 percent.
SUMMARY
One row per keyword per run. This is the record most buyers actually consume.
Every SUMMARY row ships six methodology notes. Two are shown here for space; all six are in the Methodology section below.
How is this different from other Google Trends scrapers?
1. A block is never delivered as an empty result.
This is the main one. Most Trends scrapers classify anything that is not parseable JSON as "no data" and hand you an empty array with a 200-flavoured success. You then write a report saying interest collapsed, when in fact a residential exit node got burned and Google served a captcha page.
This actor classifies every HTTP response into one of four outcomes before parsing:
| Class | Trigger | Action |
|---|---|---|
ok | Body looks like a Trends payload | Parse it |
retry | HTTP 429, any 5xx, an empty 200, or a socket failure | Back off, rotate proxy session, try again |
blocked | HTTP 403, or a 200 carrying an HTML interstitial, a /sorry/index redirect, a reCAPTCHA, or an "unusual traffic" notice | Rotate and retry, then fail the run with the status and a body snippet |
fatal | A 4xx other than 403 and 429, or a body that is not JSON after the XSSI guard is stripped | Fail immediately, because retrying a malformed request cannot help |
A JSON endpoint that answers with <!doctype html is an interstitial, not data, so it is treated as a block and can never be mistaken for an empty result.
2. Trend maths that survives a noisy day.
Direction is an OLS slope across every bucket in the window. A single spike or a single dead day cannot flip the label. You also get slopeRSquared so you can tell a clean trend from a scattered one before you act on it.
3. Partial buckets are excluded from the maths.
Google flags the trailing bucket while it is still filling. Include it and every average and slope drags toward a decline that has not happened. Those buckets are still emitted as TREND_POINT rows with isPartialBucket: true, so nothing is hidden, but the SUMMARY excludes them and reports how many it excluded in partialBucketsExcluded.
4. Breakout is a boolean, not a magic number.
Google prints Breakout and sends a large sentinel value alongside it. This actor derives isBreakout from the label Google actually printed rather than by threshold-guessing the sentinel, and sets growthPct to null rather than reporting a fake precise number.
5. Every row is traceable.
trendsUrl opens the exact chart. sourceQueryUrl is the API call. retrievedAt is the timestamp. If a number looks wrong you can check it in about ten seconds.
How do I know the numbers are real?
Drawn from run Tw3XwwlVBKyWPVOuQ, 258 records, not a mockup. Every label under it is a field you can filter on. Here is how to check any run yourself.
- Open the chart. Every record carries
trendsUrlpointing at the human Google Trends page for that exact keyword, geo, timeframe, category and property. The page should match the record. - Cross-check the average.
SUMMARYreports bothaverageInterest(computed here, partial buckets excluded) andgoogleReportedAverage. They should be close. A large gap means partial or missing buckets, whichpartialBucketsExcludedanddataCoveragePctconfirm. - Check the run posture fields.
sourceStatus,zeroMatch,interestOverTimeReturned,relatedQueriesReturnedandnotesdescribe what happened upstream. Any problem shows up there, and a blocked call fails the run instead of writing a record. - Check coverage.
dataCoveragePctis the share of buckets Google reported real data for. Low-volume keywords give sparse series, and this makes that visible instead of silently averaging zeros.
What input does it take?
| Field | Type | Default | Description |
|---|---|---|---|
keywords | array of strings | required | 1 to 5 keywords. Each is 1 to 100 characters. More than one keyword makes it a Google Trends comparison, and the 0 to 100 index is then relative across the whole set. |
geo | string | "US" | Google geo code, up to 10 characters. "US", "GB", "US-CA", "US-NY-501". Empty string means worldwide. |
timeframe | enum | "today 3-m" | Window to pull. See the valid values below. |
category | integer | 0 | Google Trends category id, 0 to 1500. 0 is all categories. |
property | enum | "" | Search surface. See the valid values below. |
maxRelatedQueries | integer | 25 | 0 to 50. Caps how many rows are emitted from each of the top and rising lists, per keyword. |
includeInterestOverTime | boolean | true | Set to false to skip the timeline call and emit only related queries plus the summary. |
includeRelatedQueries | boolean | true | Set to false to skip the related-queries calls and emit only the timeline plus the summary. |
language | string | "en-US" | Passed to Google as hl. 2 to 10 characters. Affects the language of formatted labels. |
proxyCountryCode | string | "US" | Two-letter country code for the proxy exit node. Match it to geo where you can, since Trends responses vary by request origin. |
maxRetriesPerRequest | integer | 4 | 1 to 8. Attempts per HTTP call before the run fails. Each retry gets exponential backoff with jitter and a fresh proxy session. |
Valid timeframe values
| Value | Window |
|---|---|
now 1-H | Past hour |
now 4-H | Past 4 hours |
now 1-d | Past day |
now 7-d | Past 7 days |
today 1-m | Past 30 days |
today 3-m | Past 90 days |
today 12-m | Past 12 months |
today 5-y | Past 5 years |
all | 2004 to present |
Google picks the bucket size from the window. Short now windows return sub-hourly or hourly buckets, today 1-m and today 3-m return daily buckets, today 12-m and today 5-y return weekly buckets, and all returns monthly buckets. That choice is Google's, not this actor's, and it is why row counts vary so much by timeframe.
Valid property values
| Value | Surface |
|---|---|
"" | Web search (the default, and what most buyers want) |
images | Google Images |
news | Google News |
froogle | Google Shopping |
youtube | YouTube search |
Example input
How much does a run cost?
Cost tracks the number of upstream HTTP calls and the number of dataset rows, so here are the drivers rather than a made-up figure.
HTTP calls per run:
- One landing-page call to pick up the consent and NID cookies. A failure here is a warning, not a stop.
- One explore call. This covers all of your keywords at once and returns the short-lived widget tokens.
- One interest-over-time call. Google's timeline widget covers every comparison item in a single response, so this does not multiply by keyword. Skipped if
includeInterestOverTimeisfalse. - One related-queries call per keyword. This is the part that scales with
keywords.length. Skipped ifincludeRelatedQueriesisfalse.
So a 1-keyword run is about 4 calls and a 5-keyword run is about 8 calls. Comparing 5 keywords in one run is materially cheaper than 5 separate single-keyword runs, because the landing page, explore and timeline calls are shared.
What increases cost:
- Longer timeframes and finer buckets.
TREND_POINTrows equal buckets multiplied by keywords. A 5-year weekly window and a 90-day daily window produce broadly similar row counts, whilenow 1-dat sub-hourly resolution produces far more. maxRelatedQueries. Up tomaxRelatedQueriesrows from the top list plus up tomaxRelatedQueriesfrom the rising list, per keyword.- Retries. Each retried attempt is another proxied request. Blocked and rate-limited attempts consume proxy traffic before the run fails.
- Proxy traffic. Residential proxy egress is usually the larger line item, not compute. Trends payloads are small JSON documents, so this stays modest.
What reduces cost:
- Set
includeRelatedQueries: falseif you only want the interest curve, orincludeInterestOverTime: falseif you only want the query lists. - Lower
maxRelatedQueries. - Batch related keywords into one run rather than firing one run per keyword.
What are the limits?
- 5 keywords per run. This is Google's comparison limit, not an artificial cap.
- Interest values are relative, not absolute. There is no way to get search counts out of Google Trends. See Methodology below.
- Comparison changes the numbers. In a multi-keyword run the 0 to 100 index is scaled across the whole set, so the same keyword run alone and run against a bigger keyword will report different values. Both are correct. They answer different questions.
- No geographic breakdown or topic data yet. This actor covers interest over time and related queries. Interest by region and related topics are not in v0.1.0.
- Low-volume keywords return sparse or empty series. Google withholds data below a volume floor. That surfaces as
zeroMatch: truewithsourceStatus: "ok", or as a lowdataCoveragePct, not as an error. - Trends data is not real time. Even the shortest windows lag, and the trailing bucket is flagged partial until it fills.
- Google can change the protocol. The three-call flow, the XSSI guard, and the widget naming are all undocumented surfaces. When they drift, this actor throws a
fatalerror naming the exact call that changed rather than returning a plausible-looking empty payload. - Rerunning the same query can shift values slightly. Google samples. Small movements between runs are normal and are not a bug in this actor.
Methodology
Interest values are a 0 to 100 relative index, not search counts. Google scales the series so that the highest point in the requested window equals 100 and everything else is a proportion of that. Change the timeframe, the geo, the category, the property, or the set of compared keywords, and every number in the series can change. A value of 50 means "half the interest of this query's own peak in this exact window". It does not mean 50 searches, 50 thousand searches, or 50 percent of anything else.
Partial buckets are excluded from the maths. Google flags the trailing bucket with isPartial while it is still filling. Those buckets are emitted as TREND_POINT rows so you can see them, but the SUMMARY computes average, median, standard deviation, slope, direction and volatility without them, and reports the count in partialBucketsExcluded. Including a half-collected day is the single most common way a Trends report invents a collapse that never happened.
Direction is an OLS slope, not an endpoint comparison. An ordinary least squares regression is fitted across every complete bucket, indexed by position. The reported slopePerBucket is interest points gained per bucket, and totalChangeOverWindow is that slope extended across the window. The label is assigned relative to the series mean, not in absolute points, because 0.2 points per day means something very different for a keyword averaging 5 than for one averaging 80:
risingwhen the fitted change over the window is at least 10 percent of the series meanfallingwhen it is at most negative 10 percent of the series meanflatwhen it falls between thoseunknownwhen there are fewer than 3 complete buckets
slopeRSquared reports how much of the variance the fitted line explains, so you can weigh the direction label by how well it actually describes the series.
Volatility is the coefficient of variation, banded. Standard deviation divided by the mean, reported raw as coefficientOfVariation and banded as volatility:
lowbelow 0.15moderatefrom 0.15 up to 0.35highat 0.35 and aboveunknownwhen the mean is zero or there are too few points
High volatility means the keyword spikes on events rather than holding a level, which changes whether you buy against it or wait for the next spike.
Momentum compares the recent quarter to the earliest quarter. momentumPct is the mean of the last quarter of the window against the mean of the first quarter, as a percentage change. It needs at least 4 complete buckets. This catches the case the slope misses: a keyword that fell for two months and turned around last week has a negative slope and a positive momentum, and both readings are useful.
Breakout means growth above 5000 percent. Google prints the literal string Breakout on a rising query when growth exceeds 5000 percent, and does not publish a figure. Those rows get isBreakout: true and growthPct: null. Every other rising query gets its percentage parsed out of the printed label into growthPct, with the original label preserved in formattedValue.
Silent zeros, and why this actor refuses to produce them
Worth stating plainly, because it is the design decision everything else follows from.
There are two very different reasons a Google Trends query comes back with nothing:
- Google answered normally and there is genuinely no data. The keyword is below the volume floor, or the geo is too narrow, or the window is too short. This is a real answer.
- Google refused to answer. The proxy exit node is burned, a rate limit hit, a captcha interstitial came back, or the protocol drifted. This is not an answer at all.
Most scrapers flatten both into the same empty array. That is what makes them dangerous in a pipeline. A silent zero looks exactly like a real zero, so it propagates into a dashboard, a report, or an agent's reasoning, and nobody finds out until someone makes a bad decision on it.
This actor separates them:
- Case 1 produces a
SUMMARYrecord withzeroMatch: trueandsourceStatus: "ok". TheagentMarkdownsays so in plain language: Google answered normally and reported no data, this is a real answer and not a failure, try a broader timeframe or a wider geo. - Case 2 fails the run. The error names the HTTP status, the URL, the number of attempts, and includes a body snippet so you can see what Google actually served. Nothing is written to the dataset pretending to be data.
A failed run is cheap to notice and cheap to rerun. A silently zeroed run is neither.
FAQ
Can I get actual search volumes? No, and neither can anyone else from Google Trends. Trends publishes a relative index only. If you need absolute volumes you need Keyword Planner or a third-party volume dataset, and then Trends is the right tool for shape and timing rather than magnitude.
Why do the numbers change when I add a second keyword? Because the index rescales across the comparison set. With one keyword, 100 is that keyword's own peak. With two, 100 is the peak of whichever keyword is larger, and the smaller one gets squashed proportionally. Run keywords alone for individual shape, run them together for relative size.
Why is my last data point lower than the rest?
It is probably a partial bucket that is still filling. Check isPartialBucket on that TREND_POINT row. The SUMMARY already excludes it from the trend maths for exactly this reason.
What happens if Google blocks the run?
The run fails with a TrendsSourceError naming the HTTP status, the URL, the attempt count and a snippet of the body Google served. It does not write an empty dataset. Retrying later, or with a proxyCountryCode matched to your geo, usually clears it.
direction says rising but the chart looks flat to me. Which is right?
Check slopeRSquared and totalChangeOverWindow. A rising label with a low R squared means the fitted line does drift upward, but the series is scattered enough that the line is a poor description of it. The threshold for rising is a fitted change of 10 percent of the series mean, which can be a small absolute movement on a high-average keyword.
Can I track a topic rather than a search term? Not in v0.1.0. Keywords are passed to Google as literal search terms. Trends entity and topic ids are not supported yet.
Does geo accept sub-regions?
Yes. Google's geo codes nest, so US, US-CA and US-NY-501 (a metro code) all work. An empty string means worldwide. Narrower geos hit the data floor sooner, so expect more zeroMatch results at metro level.
How do I use this with an LLM or agent?
Every record carries an agentMarkdown field: a short prewritten summary with the numbers, the caveats and the source link already in prose. Feed that in directly rather than asking the model to interpret raw fields. The numeric fields are still there when you want the model to compute something.
Tutorial: build a weekly demand brief
- Start with two to five terms that answer one commercial question, such as
cold plunge,sauna, andice bath. - Use
today 3-mfor a campaign-planning view,today 12-mfor seasonality, ornow 7-dfor a fast-moving launch. - Keep
includeInterestOverTimeandincludeRelatedQueriesenabled. SetmaxRelatedQueriesto 10 for a compact brief or 25 for fuller research. - Schedule the Actor weekly in Apify, then send the dataset to Sheets, a webhook, Make, Zapier, or your own API consumer.
- Filter
recordType: "SUMMARY"for one decision row per keyword. Usedirection,momentumPct,volatility,breakoutQueries, andtopRisingQueriesto decide what deserves action. - Keep
TREND_POINTrows for charts andRELATED_QUERYrows for content briefs, product language, and campaign expansion.
A useful operating rule is to treat direction as the long-window signal and momentumPct as the recent change. When they disagree, inspect slopeRSquared, the peak date, and the source chart before acting.
Pricing
Google Trends Intelligence uses pay-per-result pricing with a small Actor start fee. Dataset result charges apply to every emitted TREND_POINT, RELATED_QUERY, and SUMMARY row. The live pricing card in the Apify Store is authoritative.
The lowest buyer price is set from measured Cloud economics, including compute, residential proxy traffic, retries, storage, failed-run exposure, and Apify's creator share. Batching up to five related keywords is usually cheaper than running each keyword separately because the landing, explore, and timeline calls are shared.
Every run has a $5 maximum total charge. Usage passthrough is disabled, so buyers see the Store price instead of receiving separate platform-resource charges.
Legal and source terms
This Actor reads public Google Trends web endpoints and is not affiliated with, endorsed by, or sponsored by Google. Google Trends values are sampled relative indexes, not absolute search volumes. You are responsible for using the data in accordance with applicable law, Google's terms, and your own compliance requirements.
Do not use this Actor to infer sensitive traits about individuals, to evade access controls, or to make high-impact decisions without independent verification. Source URLs and retrieval timestamps are included so material findings can be checked against the human Google Trends interface.
More from Skootle
Pair this Actor with other Skootle data products when a workflow needs both demand and execution evidence:
- Website SEO Audit Intelligence turns a demand hypothesis into a bounded technical and content audit.
- Website Tech Stack Intelligence adds explainable technology fingerprints, security headers, and integration signals for lead qualification.
- Federal Contract Intelligence connects public-sector demand research with award, agency, NAICS, and recompete evidence.
For support, open an Issue on the Actor page with the run ID, input, and the specific field that looks wrong. Keep private data and credentials out of issue reports. Reviews belong on the reviews page, while reproducible defects belong in Issues so they can be fixed against source evidence.
