Google Trends shows relative search interest broken down by place. This service returns that breakdown as rows - one per location per term - with the region code, the timeframe and the resolution carried on every row so a run stays self-describing after it leaves the platform.
The single most common mistake with Trends data is reading the number as volume. It is not, and the service cannot make it one.
Every value in the export is an integer from 0 to 100 - all 1,726 of ours were, with none above 100. It is Google's own normalised index: 100 marks the peak of whatever slice you asked for, and every other place is scored against that peak. It is not searches, sessions or people, and two runs with different timeframes or regions are two different scales that must not be compared directly.
That normalisation has a consequence worth stating plainly. In 17 of our 22 populated runs exactly one location scored 100. In the other five, none did - three were comparison runs where the peak belonged to the other term, and two were city-level runs where every single value came back zero. A missing 100 is not a bug; it means the peak of the scale sits outside the slice you were handed.
What the service does hand you is a stable frame: the term, the place, the region code, the timeframe and the resolution on every row. That is what lets an export stay meaningful in a spreadsheet three months later, when nobody remembers what was asked.
Four choices shape a run, and two of them change the output far more than people expect.
Resolution defaults to city. Read the note below before leaving it there.
This is the xlsx header, identical across all 31 runs and matching the JSON keys exactly. The fill rates are counted over the 1,726 rows those runs returned, spanning 852 distinct locations.
tesla | toyota - on every row it produced. Present on all 1,726.query; on a comparison it is the part this row scores. Present on all 1,726.IN-TG or US-CA. Present on 1,126 of 1,726 - see the note below, because which rows carry it follows an exact rule.US or IN. Empty when the run was worldwide - 250 of our rows.Past day, Past 4 hours, Past 30 days, Past 12 months. Present on all 1,726. Note it is not the code you submit.REGION, CITY and DMA. Present on all 1,726.Seven of the eight columns are present on every row. Only geo_code varies, and not randomly - the note below gives the exact rule. Two things worth carrying into your importer: value is an index rather than a count, and query and term differ the moment you compare two terms, which is precisely when people key on the wrong one.
All four come from reading the 1,726 rows against the published reference, and each one changes what a run is worth.
Resolution defaults to city, and at city level 91% of our rows scored zero - 776 of 850. At region level only 15% did, and at DMA level 3%. A single brand term simply is not searched enough in most individual towns to register against a national peak. Two of our city runs came back entirely zero. If you want signal rather than a long tail of blanks, set resolution to region explicitly.
It is populated on every REGION row and every DMA row - 840 and 36 of ours, no exceptions. It is empty on all 600 in-country city rows. And on a worldwide run it carries a two-letter country code rather than a subdivision code. So a null here tells you the resolution, not that data is missing; do not treat it as a failed lookup.
You submit a code like now 1-d or today 12-m; the row says Past day or Past 12 months. Our four observed labels map cleanly onto four documented codes, but they are not the same strings - so if you round-trip a value from the export back into a request, it will not match. Keep the code you sent.
A pipe-separated query runs as a comparison. Across our three comparison runs the result was exactly 2.00 rows per location every time - 51 places, 102 rows - with query holding the full tesla | toyota string and term holding one side. Budget on locations multiplied by terms, and group by term, never by query.
Where a geographic breakdown of interest earns its keep.
A region-level run puts every state or province on one 0–100 scale for your term. That is a defensible first cut at where demand already exists - useful for deciding launch order, field coverage or where a distributor is worth signing, and far cheaper than finding out through a media budget.
Compare your term against a competitor's and each place returns a score for both. Because the scale is shared across the comparison, the gap per region is the readable part: the map of where you are ahead, level or behind, rather than a single national number that hides all of it.
Hold the term, region, resolution and timeframe steady, run it on a schedule, and the exports become comparable snapshots. Because every row carries its own timeframe and resolution, a file from six months ago still says exactly what it measured - which is what makes the series trustworthy.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. All scrapers unlocked. Worth spending some of it on a resolution test: the same term at city and at region level returns very different amounts of usable signal.
Roughly $2 per 1,000 results. Rows here are counted per location per term, so a region-level run over one country is small and a city-level comparison across several is not - the estimator prices the run before it starts.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams tracking demand across many terms and markets on a fixed cadence. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Trends tells you where attention moved. These two help with why, and with what is actually ranking for it.
A spike usually has a cause. Filter news to the last hour, day, week, month or year around the date a term moved and the story is normally right there.
Knowing a term is in demand is half of it. The organic results show who currently owns that demand - listings, ads and related questions, with a documented field set.
Short answer: yes. This reads a public, aggregated, anonymised statistic - about as far from personal data as web data gets.
Google Trends is published for anyone to read, signed in or not. Collecting publicly visible information for research is long-established practice, and as long as the data is publicly available and the process doesn't disrupt the site there are no federal laws prohibiting it.
This service sits at the comfortable end of the range. The thing being read is already an aggregate: a normalised index across a population, with no individual, no identifier and no personal detail anywhere in the output. There is nothing here to re-identify, because no row describes a person.
Google's terms restrict automated access, so this remains a terms question. We touch nothing behind a login, run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
query, term, location, geo_code, value, geo, timeframe and resolution. That is the header of real Livescraper trends exports, identical across 31 runs and matching the JSON keys exactly. Seven are present on every row; only geo_code varies, and by an exact rule rather than at random.value is Google's relative index: an integer from 0 to 100 where 100 is the peak of the slice you asked for. All 1,726 of our rows were in that range. It is not searches, sessions or people, and two runs with different timeframes or regions are on different scales - comparing them directly is meaningless.tesla | toyota. Each location then returns one row per term - exactly 2.00 rows per location across our three comparison runs. query keeps the whole string and term holds the individual side, so group by term. The scale is shared across the comparison, which is what makes the gap between the two readable.REGION and DMA row in our sample carried one; all 600 in-country city rows did not. On a worldwide run it holds a two-letter country code instead of a subdivision code. An empty value tells you the resolution, not that a lookup failed.Submit your terms, pick a region and a resolution, and get search interest back as rows you can rank, map and re-run. Your first 500 rows are free.
Google Trends is one of the few genuinely free windows onto demand, and one of the most awkward to use at scale. The interface is built for looking at one term at a time, and the number it shows resists being copied into a spreadsheet without losing the context that makes it meaningful. The Google Trends Scraper returns the same breakdown as rows: one per location per term, each carrying the term, the place, the place's code, the relative score, the region the run was scoped to, the timeframe and the resolution. Submit up to 1,000 queries in a run, choose a window from the past hour to the past five years, pick a region and how finely to cut it, and export as CSV, JSON or Excel.
The eight columns on this page are measured, not assumed. They are the header row of real Livescraper trends exports, identical across 31 runs and matching the JSON keys exactly, and every number quoted comes from the 1,726 rows those runs returned across 852 distinct locations. That matters because the published reference documents the request side thoroughly - timeframe codes, resolutions, region codes - and does not enumerate the response columns at all. One limit of our evidence is worth stating: those runs used only two distinct queries, a single term and a two-term comparison. That is enough to establish how the output is shaped, how the columns relate and how the settings change what comes back; it is not enough to say how any particular term of yours will score, which is what the free tier is for.
Four measured behaviours matter more than the column list. First, resolution defaults to city, and at city level 91% of our rows scored zero against 15% at region level and 3% at DMA - a single term rarely registers in an individual town, so the default setting quietly produces a long tail of blanks. Second, geo_code follows an exact rule: present on every region and DMA row, absent on all 600 in-country city rows, and holding a two-letter country code on worldwide runs, which means an empty value describes the resolution rather than a failed lookup. Third, the timeframe that comes back is humanised - you send a code and the row says "Past day" - so a value from the export will not round-trip into a request. Fourth, a pipe-separated comparison returns one row per term per place, exactly two rows per location in every comparison run we made, which doubles both the row count and the bill.
The value column deserves its own warning, because misreading it is the most common way this data goes wrong. It is a relative index from 0 to 100, not a count of anything. One hundred marks the peak of the slice you requested and every other place is scored against it, so the same term in the same region over two different timeframes produces two incompatible scales. It also means the 100 can be missing: in five of our twenty-two populated runs no location reached it, three because the peak belonged to the other term in a comparison and two because every city-level value was zero. Read correctly, though, the shape is exactly what most teams want - a ranked, comparable, re-runnable picture of where attention sits, with enough context on each row that a file still explains itself months later. Start free: your first 500 rows cost nothing and need no credit card.