Google Trends Scraper & Breakout Monitor

Scrape Google Trends interest over time, regional demand, related queries, Breakouts, and Trending Now. Use snapshot mode for one-off research, or schedule a watchlist and receive only new trend signals instead of diffing a full export after every run.

Use the structured output from the Apify Console, API, schedules, webhooks, Make, Zapier, dashboards, or AI agents. No Google account, Google API key, browser, or CAPTCHA solving is required.

• Up to 200 comparison groups per run, with 1-5 jointly normalized keywords in each group.
• $0.004 per completed keyword group or $0.002 per completed Trending Now country; failed and partial checks are not charged.
• Every group gets an explicit SUCCESS, NOT_FOUND, PARTIAL, or FAILED status, so a source failure never looks like zero demand.

---

Choose a workflow

Goal	Recommended setup	Result
Discover rising SEO keywords	snapshot + all, collect related_queries	Top, rising, and Breakout related searches with Google's growth labels
Monitor AI or market breakouts	monitor + changesOnly, keep a stable monitorId	Only newly rising queries, new Breakouts, and meaningful growth-band changes
Compare ecommerce demand	snapshot + all, use property: shopping	Jointly normalized timelines, related searches, and regional demand
Track Trending Now	collect trending_now and set trendingGeos	Newly appearing topics by country with approximate traffic and related news

Start in 2 minutes

1. Replace meal prep with a topic your audience searches for.
2. Keep Snapshot + All records to get useful rows on the first run.
3. Keep the default Apify proxy for keyword data.
4. Click Start and open the Related queries dataset view.

The Store form is prefilled with meal prep; replace it with your own keyword. The equivalent copy-paste input is:

{
  "keywords": ["meal prep"],
  "geo": "US",
  "timeframe": "today 3-m",
  "dataTypes": ["related_queries"],
  "mode": "snapshot",
  "outputMode": "all",
  "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"], "apifyProxyCountry": "US" }
}

This returns Google's current top, rising, and Breakout related searches. To turn the same configuration into an alerting workflow, switch to monitor + changesOnly. The first successful monitor run creates a baseline; later runs emit newly rising queries, new Breakouts, meaningful growth-band changes, and new Trending Now topics.

---

What makes this different

Most Google Trends scrapers hand you a fresh full export every run and leave you to diff it. This one is built to be scheduled:

• Bulk keyword groups. Up to 200 comparison groups per run, each with up to 5 keywords, each with your own externalId.
• Breakout and rising detection. Repeat runs return only the queries that newly joined Google's rising list, became a Breakout, or crossed a growth band.
• Deterministic monitoring state. The diff is always last successful check against this successful check.
• Explicit failure semantics. NO_RESULTS and SOURCE_FAILED are different, always. A throttled request can never come back as "interest = 0".
• Predictable pricing. You are charged per keyword group Google answered, not per data point. A group costs the same whether it returns 90 timeline points or 9,000.

---

One important rule about Google Trends numbers

Google Trends values are relative, not absolute search volume. A value of 100 means "the highest point on this chart", and the chart is renormalized for every request.

A score of 70 in one group is not comparable to a score of 70 in another.

This is the most common way Trends data gets misreported. Every row therefore carries a source_scaling_context that says exactly which values are comparable:

{
  "id": "c6643ad8bb7bb5ad",
  "scope": "within_comparison_group",
  "comparison_group": ["chatgpt", "claude ai"],
  "geo": "US",
  "timeframe": "today 3-m",
  "category": 0,
  "property": "web",
  "data_type": "interest_over_time",
  "resolution": "DAY"
}

Two values are comparable if and only if their source_scaling_context.id matches. The id changes whenever the keywords, location, timeframe, category, property or bucket size changes.

What follows from that, and what this Actor therefore refuses to do:

Compare keywords inside one group	Valid - Google normalizes them jointly. That is what a comparison group is for.
Compare values across groups	Not valid. Different scaling basis.
Compare US against DE, or 7d against 12m	Not valid. Different scaling basis.
Claim absolute search volume	Never. Google does not publish it.
Report "interest up 34% since last week"	Not emitted. Two independently normalized 0-100 series cannot be subtracted.

Partial periods

The newest bucket in any timeline is usually still accumulating, and Google flags it isPartial. It looks exactly like a collapse in interest, and it is the classic source of fake "traffic is crashing" alerts. Rows carry is_partial: true, and partial buckets are excluded from every signal this Actor emits.

Missing data is not zero

Where Google has too little data it returns a 0 alongside hasData: false. Those rows are published as value: null with has_data: false, never as 0.

---

Data returned

Data type	What you get
interest_over_time	Relative interest per keyword per time bucket, with is_partial
related_queries	Top and rising queries, including Breakout entries
interest_by_region	Relative interest per region, with has_data
trending_now	Today's trending searches per country, with news headlines

Use the purpose-built dataset views to inspect New signals, Related queries, Interest over time, Trending now, or Group status without manually selecting fields.

Related topics is deliberately not offered. Google currently answers that endpoint with HTTP 200 and an empty list for every keyword tested, including high-volume ones. Shipping it would report "no related topics" for every keyword on earth, which is exactly the kind of confident-looking false zero this Actor exists to prevent. If Google starts serving it again, it will be added.

---

Input reference

{
  "queries": [
    { "keywords": ["chatgpt", "claude ai", "gemini"], "externalId": "ai-assistants" },
    { "keywords": ["electric bike"], "externalId": "ebikes" }
  ],
  "geo": "US",
  "timeframe": "today 3-m",
  "category": 0,
  "property": "web",
  "dataTypes": ["interest_over_time", "related_queries", "interest_by_region"],
  "mode": "monitor",
  "outputMode": "changesOnly",
  "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"], "apifyProxyCountry": "US" }
}

Field	Default	Notes
queries	-	Up to 200 groups, 1-5 keywords each (5 is Google's limit)
geo	US	US, DE, US-CA, … Empty string for worldwide
timeframe	today 3-m	now 1-H … today 5-y, all
category	0	Google Trends category ID; 0 is all
property	web	web, images, news, shopping, youtube
dataTypes	timeline + related + region	Fewer types means fewer requests and less throttling
mode	monitor	snapshot stores nothing
outputMode	changesOnly	all also returns timelines and regions
trendingGeos	run's geo	Countries for trending_now
monitorId	-	Separates independent watchlist histories

Modes

• snapshot - what Google says right now. Nothing is stored, nothing is diffed.
• monitor - remembers the last successful check per configuration.

Output modes

• changesOnly - new and changed rising/breakout queries, new trending topics, plus a status row per group. This is the alerting shape.
• all - additionally every timeline point and region score. Timelines are measurements rather than events, so changesOnly does not include them.

---

Monitoring semantics

The first successful check of a configuration is a BASELINE - it records what is already there without alerting on the whole backlog. From then on:

change_type	Meaning
BASELINE	First successful check of this configuration
RISING_QUERY_NEW	A query joined Google's rising list
BREAKOUT_NEW	A query became a Breakout (rising past Google's reportable ceiling)
RISING_QUERY_CHANGED	A rising query's growth crossed a band
TRENDING_TOPIC_NEW	A new topic in the Trending Now feed
UNCHANGED	Already reported; suppressed in changesOnly
OBSERVATION	A timeline point or region score - a measurement, not an event

Growth bands. Google's rising percentages jitter run to run, so a change is reported only when growth crosses a band: <100%, 100-249%, 250-499%, 500-999%, 1000%+, breakout. Without this, every run would alert that +240% became +250%.

There is no "breakout ended" event. Related queries are a top-N ranked list, not an inventory. A query dropping off it means something else outranked it - Google never says the rise ended. Reporting that as an event would be inventing information, so this Actor does not.

Monitor identity includes the full normalized configuration: keywords, location, timeframe, category, property and data type. chatgpt in US over today 3-m and chatgpt in DE over today 12-m are separate monitors and never share state.

State is only advanced by runs that can stand behind it. A run that was throttled, whose payloads stopped parsing, or that was cut short by a charging limit leaves the previous state untouched. A verified NOT_FOUND answer is valid state, never a source failure. Overwriting state after a failed check would record signals as delivered that you never received, and silence them forever.

---

Output

One flat row shape, discriminated by record_type and data_type, so the whole run exports as one CSV.

A breakout signal:

{
  "record_type": "observation",
  "source": "Google Trends",
  "source_id": "trends:c6643ad8bb7bb5ad:rel:rising:chatgpt atlas browser",
  "scraped_at": "2026-08-31T08:00:00Z",
  "schema_version": 1,
  "fingerprint": "9f1c2b7a4d…",
  "external_id": "ai-assistants",
  "status": "SUCCESS",
  "data_type": "related_queries",
  "keyword": "chatgpt",
  "related_query": "chatgpt atlas browser",
  "related_type": "rising",
  "related_value": null,
  "formatted_value": "Breakout",
  "change_type": "BREAKOUT_NEW",
  "source_scaling_context": { "id": "c6643ad8bb7bb5ad", "…": "…" },
  "source_metadata": { "is_breakout": true, "growth_band": "breakout" }
}

Every requested group also gets exactly one group_status row, including the ones that failed - 200 groups in always means 200 status rows out:

{
  "record_type": "group_status",
  "status": "PARTIAL",
  "comparison_group": "chatgpt vs claude ai",
  "external_id": "ai-assistants",
  "source_metadata": {
    "data_type_statuses": {
      "interest_over_time": "SUCCESS",
      "related_queries": "FAILED",
      "interest_by_region": "SUCCESS"
    }
  },
  "error": { "code": "THROTTLED", "message": "…" }
}

Statuses

status	Meaning
SUCCESS	Google answered with data
NOT_FOUND	Google answered and genuinely had nothing. A real, verified absence
PARTIAL	Some requested data types succeeded, others did not
FAILED	We could not find out. Never means zero interest

Run metrics land in the key-value store under RUN_SUMMARY: group counts by status, requests, retries, 429s, session bootstraps, proxy bytes, rows by type, new breakouts, source health, and whether state was saved.

---

Proxy is required for keyword data

This Actor is not affiliated with, endorsed by, or connected to Google. "Google" and "Google Trends" are trademarks of Google LLC. It reads publicly available Google Trends data.

Google Trends rate-limits its data endpoints per IP address, and it is tight. Measured on 2026-08-31 from a single clean address:

• roughly a handful of widget requests before refusal;
• a fresh cookie and a freshly-minted widget token from the same address are still refused, so the block is on the IP, not the session;
• once blocked, the address stayed blocked for over 33 minutes of once-a-minute polling, and had still not recovered when we stopped watching;
• a 5-group run direct from one address: 0% success, 50% of requests 429.

So the Actor rotates proxy sessions rather than repeatedly using a refused IP, and proxyConfiguration is required when you request keyword data.

The default is Apify's Residential pool. On 2026-09-01, both Residential and datacenter completed 10/10 benchmarks, but a later production run through the default auto pool exhausted four rotated sessions with HTTP 429. A later production check also exhausted four Residential sessions when country selection was automatic, while RESIDENTIAL@US succeeded immediately. US-targeted Residential therefore became the reliability-first default; a custom proxy remains available for controlled deployments. Saved inputs that still contain only {"useApifyProxy": true} are automatically migrated at runtime.

Trending Now alone works without a proxy. For a Trending Now-only run, the Actor ignores the proxy setting so the public RSS feed does not incur proxy traffic.

No CAPTCHA solving, no Google login, no browser, and no access-control circumvention is involved. The Actor uses plain HTTPS against publicly available endpoints and honours Google's robots.txt: it never requests /trends/explore or /explore, the two paths trends.google.com/robots.txt disallows. That constraint is enforced in code, not by convention.

---

Pricing

Pay per event:

Event	Price	What it covers
Completed keyword group	$0.004	One comparison group Google fully answered - all its timeline points, region scores and related queries included
Completed Trending Now feed	$0.002	One country's trending feed and its topics

These prices include Apify platform usage, including compute and the default Residential proxy traffic. You do not receive a separate platform-usage charge for a standard pay-per-event run.

You are never charged for retries, PARTIAL groups, throttled requests, failed groups, or input rows rejected as invalid. A group that Google fully answered with no data is charged, because checking it was the work.

100 fully completed groups cost $0.40. A partial or failed check costs no event charge, so the watchlist size is the maximum number of charges.

---

Schedule alerts

The reason to run this twice: with mode: monitor and outputMode: changesOnly, a repeat run returns only signals that are new since the last successful check.

For example, run it daily and send new Breakouts to Slack, Make, Zapier, or your own webhook:

1. Actor -> Schedule -> daily.
2. Actor -> Integrations -> Webhook on ACTOR.RUN.SUCCEEDED.
3. Filter the dataset for change_type in BREAKOUT_NEW, RISING_QUERY_NEW.

# Only this run's new breakouts
curl "https://api.apify.com/v2/datasets/<DATASET_ID>/items?clean=true&format=json" \
  | jq '[.[] | select(.change_type == "BREAKOUT_NEW")]'

# Start a run from the API
curl -X POST "https://api.apify.com/v2/acts/automa-flow~google-trends-monitor/runs" \
  -H 'Authorization: Bearer <YOUR_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{
        "queries": [{"keywords": ["electric bike"], "externalId": "ebikes"}],
        "geo": "US",
        "timeframe": "today 3-m",
        "mode": "monitor",
        "outputMode": "changesOnly"
      }'

Python:

from apify_client import ApifyClient

client = ApifyClient("<YOUR_TOKEN>")
run = client.actor("automa-flow/google-trends-monitor").call(
    run_input={
        "queries": [{"keywords": ["electric bike"], "externalId": "ebikes"}],
        "geo": "US",
        "mode": "monitor",
        "outputMode": "changesOnly",
        "proxyConfiguration": {
            "useApifyProxy": True,
            "apifyProxyGroups": ["RESIDENTIAL"],
            "apifyProxyCountry": "US",
        },
    }
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item)

Webhook-friendly output

Filter observation rows by change_type. The most useful alert values are BREAKOUT_NEW, RISING_QUERY_NEW, RISING_QUERY_CHANGED, and TRENDING_TOPIC_NEW. Keep the group_status rows in operational workflows so that a failed check is visible instead of looking like “nothing changed”.

Use with AI agents through Apify MCP

Expose this Actor as a typed tool in any MCP-compatible client:

https://mcp.apify.com?tools=automa-flow/google-trends-monitor

Example prompt:

Run automa-flow/google-trends-monitor for one comparison group containing
"chatgpt", "claude ai", "gemini", and "perplexity ai" in the US over the
past 90 days. Return rising and Breakout related queries, keep group_status
rows visible, and cite each signal's source_url.

For a scheduled agent, use mode: monitor, outputMode: changesOnly, and a stable monitorId. Values from different comparison groups, locations, properties, or timeframes are not directly comparable.

---

Limitations

• Values are relative and unitless. Google does not publish absolute volume.
• Google decides the bucket size from the timeframe; it is reported per row, and daily and weekly series are not comparable.
• Maximum 5 keywords per comparison group. That is Google's limit, not ours.
• Related topics is not returned (see above).
• Trending Now is per country; there is no worldwide feed.
• Rising and breakout lists are top-N rankings, so absence from them carries no information and is not reported as an event.
• Throughput is bounded by Google's per-IP rate limit, not by this Actor.

---

Support

When reporting an issue, include the run ID and the affected group status. Do not paste API tokens, proxy URLs, cookies, or other credentials. Source changes are handled as explicit failures so a broken response cannot silently become a zero-interest result.