# Changelog of Trending Keywords Scraper — Google Trends Rising Queries (`steadyfetch/breakout-keywords-scraper`) Actor - **URL**: https://apify.com/steadyfetch/breakout-keywords-scraper/changelog.md - **Full Actor documentation**: https://apify.com/steadyfetch/breakout-keywords-scraper.md ## Changelog ### 1.0.53 — 2026-09-19 - **The whole "Maximum cost per run" you set is now spent on breakout keywords.** A capped run used to hold back about a tenth of your cap as a cushion against platform usage — but your cap pays for the keywords and nothing else, so that tenth was cap you had asked to spend and did not get: a cap worth eleven keywords planned ten. A run now plans every keyword its cap can pay for, and still ends on its own line naming your cap and what was left, never on a run the platform cuts short. Nothing about the price, the charged event, the input form or any output column changed. ### 1.0.52 — 2026-09-19 - **The price is now on the first screen of this page, in the opening line.** It sat about 1,900 characters down, below the sample block and the input-form picture. The opening line now names the thing and the cost together — trending keywords from Google Trends rising queries, from $1.50 per 1,000 breakout keywords — and keeps the reason to use this one rather than the Trends UI (the real growth percentage behind the word "Breakout") in the same sentence. This build changes nothing about the run: no input field, output column, charged event or price moved. ### 1.0.51 — 2026-09-18 - **The shelf note about a sibling actor's lookup fee now reads as a live charge, not a coming one.** Nothing on this actor moved: no price, input field, output column or charged event changed, and a run costs what it cost yesterday. What changed is a neighbour this page points at — the keyword-volume actor's fresh-lookup fee of $0.19 was announced ahead of time and is now charging, so the sentence that said it was coming says it is here. A run there answered from its 30-day cache still adds nothing, and the same block's note about the three actors that add a small delivery-conditional fee is stated in the present tense for the same reason. ### 1.0.50 — 2026-09-14 - **The page's first screen now carries the price and says how often the data actually moves.** Both facts were already on the page and both were below the fold: what a keyword row costs — from $1.50 per 1,000 breakout keywords, all-inclusive, nothing charged for starting a run — and that Google recomputes rising data against your chosen time range daily, so the same seed can return a different rising set tomorrow and every row carries `fetchedAt` to tell you when a figure was true. They now sit where you decide whether to run this once or on a schedule. No price, input field, output column or charged event changed. ### 1.0.49 — 2026-09-13 - **The store card now says that the 12-month curve and the current-interest figure are things you ask for, because a bare Start does not return them.** The card promised the rising and Breakout queries "plus current interest and the 12-month curve". The queries and the real growth percentage do come back on a bare Start; the other two do not. **Attach the 12-month curve** is off unless you turn it on, and it then attaches a curve to the first five rising queries of each seed (raise **Curves per keyword** for more, up to the 25 Google returns); **Also return top queries** is off unless you turn it on, and those are the rows that carry an interest score of 0-100 rather than a growth percentage. The card now says both are on request. No setting, default, output column, charged event or price moved — only the words on the listing. - **The store card now says what a keyword row costs.** The card described what comes back and named no price, so a buyer comparing actors in the search results could not compare this one on price at all, and had to open the page to find it. It now carries the same headline the page does: from $1.50 per 1,000 breakout keywords, the cheapest paid rate on the ladder, and no start fee. Nothing else moved: no input field, output column, charged event or price changed. ### 1.0.48 — 2026-09-13 - **The input form now opens with the call that works, what one keyword row costs and what is never charged — the screen an AI agent reads.** An AI agent shopping the store never reads this page: it reads the input form's own description, and that description used to open by telling a human to click Start. It now opens with a ready-to-send input, says which field is required and that every other one can be left out, gives the per-row price on the Apify free plan and on paid plans with the per-1,000 arithmetic, repeats that there is no start fee and no minimum, says a seed with no rising data is never charged, names the run option that caps the bill and the limit Google itself sets at 25 rows a seed, and points a full timeline, today's trending searches or a search-volume question at the right sibling actor. **Search terms** leads with the value shape and its example instead of the console instruction, which now comes last. Nothing else moved: no input field, output column, event or price changed, and the console form behaves exactly as before. ### 1.0.47 — 2026-09-12 - **An aborted or migrated run now leaves its receipt from the first moment of the run, instead of only after start-up finishes.** The record that says how a run ended was only put in place once the run had finished starting up — reading your input, opening its stores, working out what a previous attempt had already delivered and charged. A run stopped inside that window ended with nothing written about it at all, which mattered most on a re-started run, where the thing not written about was the earlier attempt's work. It is now in place from the run's first moment. Nothing else moved: no input field, output column, event or price changed, and a run that reaches its work behaves exactly as before. ### 1.0.46 — 2026-09-12 - **This actor has a new title on the store: Trending Keywords Scraper — Google Trends Rising Queries.** Same actor, same id, same URL, same input, same output, same price — only the words on the listing changed, so nothing you have saved, scheduled or wired into an integration needs touching. The title now carries the phrase buyers actually search for, which is the only reason it moved. - **One wording fix in "What each seed costs":** the per-row figure now says "the Apify free plan", which is the name Apify uses and the one the rest of our actors already used. The figure itself, and every other price on the page, is unchanged. - **A "Max results per keyword" or "Curves per keyword" above 25 no longer refuses to start the run.** Both settings were capped at 25 in the input form itself, so sending 50 — from the API, or from an AI agent guessing a number — did not start a run at all: you got a validation error, no rows, no status line and nothing to look at. The cap is still 25, because Google returns no more than 25 rising and 25 top queries for a seed. What changed is what a larger number does: the run now starts, uses 25, and writes one uncharged row saying what you asked for and what bound it. Your defaults, your prefills and the smallest values you can send are unchanged, and nothing about what a run costs moved. - Nothing else moved: no input field, output column, event or price changed. ### 1.0.45 — 2026-09-11 - **The README opens with the one-click MCP pin instead of burying it at the bottom.** The pin link, the actor id, the one input field you have to set with a real example, and how to cap what a run may spend now sit in the first screen, so an agent reading this page finds them. The list of our other actors at the foot of the page names a renamed one by its current title again, and the store description leads with what the actor is — every charging sentence in it is word for word what it was. - **A maintenance build otherwise: nothing about your runs changes.** The private run-report this actor writes for our own support — counts only, never anything you typed — now also records what one charged event cost on the run, beside the count of them. Only we read that record. - **Nothing else you can see changed.** Your rows, your columns, your row statuses, your receipt row and your bill are exactly as they were — only delivered keyword rows are charged, and a pause is never charged. ### 1.0.44 — 2026-09-10 - **A seed lost to a connection problem at our end no longer says Google did not answer.** When this actor's own rotating connection pool has no exits left, the run used to treat it exactly like Google refusing: it retried onto the same dead pool, could spend a pause of a minute and a half to three minutes on it, and then told you Google had not answered your seed. It now recognises its own dead pool, stops using it for the rest of the run and continues on the normal connection, spends no pause on it, and the uncharged row says the problem is at our end and not with your input. At most one seed can be affected instead of every seed after it. - **Nothing else you can see changed.** Your rows, your columns, your row statuses, your receipt row and your bill are exactly as they were — only delivered keyword rows are charged, and a pause is never charged. ### 1.0.43 — 2026-09-09 - **The pause on a refused seed is now sized by what the pending seeds are worth.** The pause-and-try-again this actor takes on a refused seed used to run to the shared ceiling whatever the ask; it is now bounded by the value of the seeds still open, so a one-seed run pauses briefly and a wide run pauses longer. A run that has delivered nothing still keeps one short retry. - **Nothing about your rows, columns or bill changed.** Only delivered keyword rows are charged, and no pause is ever charged. ### 1.0.42 — 2026-09-09 - **A keyword Google turns away BEFORE the run's first result now gets the same patience as one it turns away after.** Until now the pause-and-try-again this actor takes on a refused keyword was only reachable once something had already been delivered. A keyword refused earlier than that was reported in seconds with an uncharged "please re-run shortly" row — while the run still held almost all of its time limit — and the very next keyword that answered was what closed the door on it. So two runs with the same keywords and the same block behaved differently purely because of the ORDER the keywords were in. Now, the moment a result arrives, any keyword still waiting on a refusal is given a pause of a minute and a half to three minutes and one more full attempt on a fresh connection first. All of them together, on the same shared ceiling, so a run can never spend its minutes twice over. - **The row for a keyword that was refused says whether the run waited.** A run that spent the minutes says so and asks for a later re-run; a run that could not wait keeps the plain words. Waiting is never charged. - **A 12-month curve the run ran out of TIME for no longer says Google refused it.** With "Attach the 12-month curve" on, a run that reached its time limit before the curve could be fetched told you Google had not served it. It now says the run ran out of time and points at the settings that fix it — "Timeline limit", or fewer seeds. A curve Google really did refuse still says exactly that. - **The run no longer names a cause it did not see.** "Google is rate-limiting broadly" and "Google blocked or refused every attempt" were written on runs whose failures could equally have been a dropped connection on our side. Both now state only what happened: results did not come back. And a run that stops on its time limit now names the limit that actually stopped it, instead of pointing you at a run-timeout setting that may not be the one that ended it. - **Nothing about your rows, columns or bill changed.** Only delivered keyword rows are charged; a seed that answered with nothing, was refused, or was never reached is never charged, and no pause is ever charged. ### 1.0.41 — 2026-09-07 - **A run where Google simply has no rising data for your seeds no longer reads as a fault.** Every seed you send is checked, and a seed with nothing rising under it comes back as one uncharged row saying so. The run then closed by telling you something had gone wrong and asking you to open an issue — about a run that did exactly what you asked and charged you nothing. It now closes with the count and nothing else. A wall Google put up, a request Google refused, a stop that cut your run short, and any seed the run cannot account for all still say so, and still point you at the Issues tab. - **When your maximum cost per run cuts a seed part-way down its rising list, the run now names the rows it could not pay for.** That seed used to be reported as one the run never reached, so a single-keyword run that delivered ten rows out of twenty-five said "1 seed left" while the run's own record counted the same seed as delivered. It now says how many rising rows the cap left behind, which is exactly what raising the cap buys back. Seeds the cap never reached are still counted as seeds. - **Nothing about your rows or your bill changed.** Only delivered keyword rows are charged; a seed that answered with nothing, was refused, or was never reached is never charged. ### 1.0.40 — 2026-09-06 - **A block of links pasted into the search terms box now stops the run with a message instead of running it.** Each seed is asked of Google Trends as a phrase. A whole block of links pasted into a single row used to be one seed with nothing rising under it. The run now ends immediately, uncharged, with a message saying how many links it found and that this box takes seed keywords, one per row. - **Your search text is never split apart.** Only you know whether "red running shoes" is one search or three, so nothing is guessed — a row holding words rather than links runs exactly as before. - Nothing else moved: no price, event, output column or charge changed, and only delivered results are charged. ### 1.0.39 — 2026-09-06 - **The run's own record now counts the keyword results your maximum cost per run left uncollected.** When the cost cap ran out part-way down a seed's rising list, the rows Google had already listed but the cap could not pay for were simply absent from the report this run writes back to us: a run that asked for twenty-six rows and delivered ten closed its books with fifteen named by nothing at all. They are now counted under the cost cap that stopped them, so a run that stops short of what a seed listed is visible to us without you having to report it. - **Nothing you can see changed.** Your rows, your columns, your receipt row and your bill are exactly as they were — only delivered rows are charged, and a row that was not delivered is not charged. ### 1.0.38 — 2026-09-05 - **A keyword Google turns away part-way through a run is now waited out, not reported in seconds.** When a run had already returned rows for one keyword and Google then refused the next one, this actor tried a few times over about a minute and shipped an uncharged "please re-run shortly" row for it — with most of the run's thirty-minute limit still unspent, asking you to spend the very minutes it was holding. That pause-and-try-again already existed, but only for a run that had returned nothing at all. Now any refused keyword gets it: the run waits a minute and a half to three minutes, moves to a fresh connection and works that keyword again before any such row ships. - **A final answer is still immediate.** A request Google refuses outright as invalid, and a keyword it answers with an empty rising list, are answers rather than weather: they are reported at once and never waited on, exactly as before. - **The waiting is bounded once for the whole run.** Every pause this actor takes — for a refused keyword, for a broad block, or for a twelve-month curve — draws on the same ceiling and the same share of the remaining time, so a run can never spend its minutes twice over. The time kept back to finish and report is untouched, a run with a short time limit behaves exactly as it did, and waiting is never charged. ### 1.0.37 — 2026-09-05 - **The 12-month curve now gets the same persistence the keyword list has.** When you turn "Attach the 12-month curve" on and Google refuses that request, the run used to give up on the curve for the whole seed after a single try — the rows shipped with an empty `timeline` column and nothing at all saying why. The curve is now fetched the way the rising list is: several tries on fresh connections, and, when the run still has the time for it, a pause of a minute or two before one more full attempt. - **A curve that still does not arrive is never a silent empty column.** Every row that was owed one now says so in its `message`, so an empty `timeline` is readable as "Google would not serve it on this run", not as "this query has no history". - **The rows themselves are unchanged, and so is the price.** A rising row is delivered and charged on its own merit; the curve is an extra field on it and has never carried a charge of its own. A request Google refuses outright — a region or category code it does not recognise — is still reported at once, with no waiting. ### 1.0.36 — 2026-09-05 - **The run's own account of what it asked for is now counted in keyword rows, not seeds.** Every run keeps a record of what was asked for, what was delivered and what came back with nothing. That record counted the ask as a number of SEEDS while counting the delivery in keyword ROWS, so a one-seed run that delivered twenty-five rows never added up — and a seed that quietly answered with nothing could hide inside the mismatch instead of being named. The ask is now restated seed by seed as Google answers: a seed with a rising list asks for the rows that list held, a seed that answered with nothing, was refused, or was never reached counts as one, and a cap of yours that cut a seed short is reported as the stop it is rather than quietly shrinking the ask. - **The count of seeds left behind by a stop no longer includes the seed that was cut.** When your maximum-charge cap trimmed a seed mid-list, that seed was counted both as delivered and as left behind. Its rows are unchanged — only the run's own record was double-counting it. - **A run moved to another server now says so in its record.** The hand-over already told you in the run log; the record called it nothing, which left the seeds still to come unexplained. - **Charges are unchanged.** Only delivered keyword rows are charged; a seed that answered with nothing, was refused, or was skipped is never charged. ### 1.0.35 — 2026-09-05 - **A first run now has room to wait out a short block.** Press Start on the untouched form and this actor fetches one real sample keyword. When Google is refusing broadly the run pauses for a minute and a half to three minutes, comes back on fresh connections and asks again — but the sample's own time limit was three minutes, shorter than one refused attempt plus one pause, so on the most common first run of all that wait could never be taken: the run reported "please re-run shortly" while the block was still lifting. The limit is now seven minutes, sized to hold one refused attempt, one full pause, a second attempt and the time the closing rows need. A sample Google answers still finishes in seconds; only a blocked one uses the extra time. - **How much of its remaining time a blocked run may spend waiting now follows the size of what you asked for.** A run with more keywords still to look up keeps exactly the limit it had — no more than half the time left — so a wide block still leaves the later keywords their share of the run. A run working a single keyword may spend what is left on its one pause, because nothing else is waiting for that time. - **A pause is taken only when the attempt after it can actually finish.** The check that approved a wait set aside less time than one whole keyword takes on this actor's connection ladder, so a run near its limit could take the pause and then leave its second attempt without the time to finish and report. It is now measured against a real attempt. - Nothing about your dataset or your bill changed: a pause is never charged, and only delivered keyword rows are. ### 1.0.34 — 2026-09-05 - **A run where Google had nothing to say now says so in the report it sends us** — counts and reason codes only, never your keywords or your rows. Until now a run whose every seed came back with no rising data reported zero keywords delivered and no reason at all, which reads exactly like a run that broke: we could not tell "Google answered and had nothing rising for these seeds" from a silent failure, so a run that worked perfectly could have been chased as a fault. Two counts now separate them — seeds Google had no rising list for, and seeds whose rising list none of your own filters matched — and both carry the same words you already see as the row's own status. - Nothing about your dataset changes: the same uncharged notice row per seed, the same status line, the same charges. Only delivered keyword rows are charged, as always. ### 1.0.33 — 2026-09-05 - **When Google is rate-limiting broadly, the run now waits it out instead of handing you the advice to wait.** A broad block used to end a run after five refused seeds — often five minutes into a thirty-minute run — and every row it left behind said "please re-run shortly; a rate-limit wave usually clears within minutes", about minutes the run itself still had in hand. The run now pauses for a minute and a half to three minutes, comes back on fresh connections and re-tries exactly the seeds that were refused, before it gives up on any of them. A run too short to hold the pause stops exactly as it did before, and a seed Google actually answered — no rising data, or a region or category it refuses outright — never waits at all. A pause is never charged; only delivered keyword rows are charged, as always. - **A short list gets the same patience.** The old stop needed five refusals in a row, so a one- to four-seed run — and the sample run on an untouched form — never got a second attempt at all. It does now. - **A seed that could not be answered says what was tried** — how many connections, over how many rounds and minutes, and how long the run waited — and asks for a later re-run only when the run really waited. It still asks for a re-run shortly when it could not. Those rows are uncharged either way, and a seed that answers on the second attempt no longer carries a stale "could not answer" row beside its results. - The run's own summary row and status line carry the same facts for the whole run. ### 1.0.32 — 2026-09-04 - **Setting a region, a time range or a filter and no keywords now runs the sample under your settings, instead of returning nothing.** Until now the sample seed only ran when the form was completely untouched, so anyone who picked a country or narrowed a filter and left the keywords empty got one guidance row and no results — a worse first run than clicking Start on the untouched form. Now the settings you chose are kept, everything you did not set takes the sample's own value, and a row limit above the sample's own 5 is treated as a ceiling rather than a request, so a sample can never grow into a bill you did not ask for. The sample rows are charged like any run; one extra `sample_note` row names the settings that were kept and is never charged. An input field name this actor does not recognise, a `searchTerms` list filled with blanks, and an unreadable region, time range or category all still get the guidance row they had. ### 1.0.31 — 2026-09-04 - **A keyword with too little search volume no longer costs the other results their 12-month curve.** Google answers a long-tail term below its volume floor with an empty result. A run collecting curves used to read that as trouble on the connection and stop attaching curves to everything after it. It now skips only that one keyword's curve and carries on with the rest. Rows, prices and charges are unchanged. ### 1.0.30 — 2026-09-04 - **A run refused for an input mistake now tells us which field was refused** — "Time range", "Geo", "Category" or "Search terms", the field name only and never the value you typed. A check that is too strict now reaches us as one thing to fix instead of looking like many unrelated typos. ### 1.0.29 — 2026-09-04 - **A region or category Google does not recognise is now told to you as such.** A refused request used to be retried on three routes, counted toward the "Google is rate-limiting broadly" stop, and reported with "please re-run shortly; a rate-limit wave usually clears within minutes" — for an input that would have been refused again every time. The row now says the request was refused and names the region and category fields to check. Nothing was charged, and genuine rate limits are unchanged. ### 1.0.28 — 2026-09-04 - **A run that stops before it starts now reports its outcome too** — a run refused for its memory setting, and a run given an input it cannot act on, now reach us the same way every other run does: counts and reason codes only, never your input or your rows. ### 1.0.27 — 2026-09-04 - **Every run now reports its own outcome to us** — counts and reason codes only, never your input or your rows — so a run that goes wrong reaches us even when nobody shares it. ### 1.0.26 — 2026-09-04 - **Run status lines fit the run page again; sample-run wording shortened.** ### 1.0.25 — 2026-09-04 **A run that resumes after a platform restart now recognises every row it already delivered, so nothing is delivered or charged twice.** Apify occasionally moves a running actor to another server. When that happens, the run re-reads its own dataset to remember what it already delivered. Until now it trusted the dataset's row count, which can lag for a moment after a restart; a lagging count could make the run start over and charge again for rows you already had, stop before the end, or stop the run outright as a precaution. The run now checks for real rows instead of trusting the count, and reads to the end whatever the count says. Rows, prices, charges and the status line on a normal run are exactly as before. ### 1.0.24 — 2026-09-04 - **A run that ends with a problem now says where to reach us.** A miss, an input error, an early stop or a failed run closes by pointing at the Issues tab and naming the reply time; a fully delivered run is left alone. - **One support promise across this page** — issues are answered in a couple of hours, always within a day. ### 1.0.23 — 2026-09-03 The two screenshots on this page now load from Apify's own storage instead of an outside website, and the two places that pointed at the free workflow templates no longer carry an outside address — the templates are still free, and our Apify profile points to them. Nothing about what this actor delivers or charges changed. ### 1.0.22 — 2026-09-02 The suite blocks at the bottom of this page now state the three delivery-conditional fees that start 16 September 2026 on sibling actors — keyword volume's fresh lookup, profile posts' profile lookup, and Google Jobs' search fee. Nothing changes on this actor: same price, same events, same rows. ### 1.0.21 — 2026-09-02 See the real thing before you run it. - **Two screenshots of an actual run** now sit on this page: the input form exactly as it looks when you open the actor, and the dataset table it fills — five rising Breakout queries for the seed `ai agents`, each with its real growth number. - **One link pins this actor in any AI agent** (Claude, Cursor, or any MCP client) — it is at the bottom of the page. - **The list of rows you are never charged for no longer names a row this actor stopped producing.** Starting with nothing set fetches a real one-seed sample, charged like any run, so there are no free placeholder rows left to list. - **The links to the rest of the shelf carry each actor's current name.** ### 1.0.20 — 2026-09-02 Start with the default form and get real rising queries instead of placeholder rows. - **A bare Start now runs a one-seed sample.** Click Start with nothing set (or send an empty input from the API) and the run fetches up to five rising queries for `ai agents` and returns their full rows, charged like any other rows. The placeholder "sample rows" are gone; what you see is what a real run returns. - **The sample stays small and quick by design:** one seed, five rows, and a three-minute window. On a bad minute you get one uncharged row saying Google Trends did not answer (re-run in a minute), never an empty dataset. - **The status line says when a run was the sample** and how to run your own seeds. - **Nothing else changed:** any input with seeds in it behaves exactly as before, and a mistyped field still gets a row naming the field instead of a sample. ### 1.0.19 — 2026-08-31 Sending `null` for a setting you do not want now means "use the default", instead of stopping the run before it starts. - **An optional setting sent as `null` now takes its default.** Agents, n8n templates and MCP callers routinely fill every field in a template and send `null` for the ones they have no value for. Until now Apify refused those runs before the container even started — you got a validation error, no run and no rows, and the fix was to know that you had to leave the key out entirely. Every optional setting on this actor now accepts `null` and reads it as "use the default", which is exactly what omitting it does. `searchTerms` is the one required setting and still needs real seeds. - **A `null` cap means the documented default, never the smallest allowed value.** Sending `null` for "Max results per keyword" gives you 25, not 1; `null` for "Curves per keyword" gives you 5; `null` for the category or the minimum growth gives you 0. - **The Time range field now also accepts a custom range typed straight in.** It is still the same dropdown with the same nine windows, but it no longer refuses anything else outright — which is what let it accept `null` at all. A value that is not one of those windows and is not a real date range like `2025-01-01 2025-06-01` is still refused, uncharged, with a message naming the windows you can use. ### 1.0.18 — 2026-08-31 A safeguard build. Nothing about what this actor delivers or charges today changed. - **The rows you get for nothing can never quietly become billable.** The sample rows, the input-guidance row, the "no rising data" notice rows and the run summary row are all uncharged because this actor bills a named event per delivered keyword, so writing a row costs nothing. That is not true of every billing setup: where a dataset row is itself the billed unit, rows meant to be free would land on your bill. The run now reads its own billing setup before it writes anything, and on such a setup it reports those seeds in the run status line and in the run's summary record (Key-value store → `OUTPUT`) instead of writing rows you would be charged for. On the current setup every one of those rows still ships exactly as before, and every delivered row still states what it cost. ### 1.0.17 — 2026-08-31 The sample run now ends with a summary row, exactly like every other run. - **A run with no search terms now writes the run's uncharged summary row too.** This page says the last row of every run is a summary row — and the sample run you get from an empty input was the one run that did not write one, so the first run most people ever start did not match the description. It now ends with the same `_summary` / `status: "run_summary"` / `charged: false` row, with `delivered: 0` and `chargedEvents` at zero: nothing was fetched and nothing was charged. The sample rows above it are unchanged, and a sample run that is moved to another server and resumed still ends with exactly one summary row. - The linked example dataset is described as one verified run of the current code — the same dataset, unchanged. ### 1.0.16 — 2026-08-30 The linked example dataset is re-shot from a run of the current code. Nothing about what this actor delivers or charges changed. - **The example dataset now shows every row a paid run returns** — 11 charged rising queries for `adidas`, one uncharged row for a seed with no rising data, and the new summary row last, unedited. ### 1.0.15 — 2026-08-30 Every run now ends with its own summary row, and worldwide rows say so. Nothing about what this actor charges changed. - **The last row of every run is an uncharged summary row.** `_summary: true`, `status: "run_summary"`: how many keyword rows were delivered, how many seeds returned nothing, why the run stopped and how many seeds are left, and `chargedEvents` — which equals the number of rows above it marked `charged: true`, so you can reconcile the invoice from the dataset alone. A run that is moved to another server and resumed gets exactly one summary, with the whole run's numbers. - **A row from a run with no location set now reads `"geo": "worldwide"` instead of an empty string.** A blank could not tell you whether the run was worldwide or the field had failed; the word can. Your input is unchanged — leave `geo` empty for worldwide, exactly as before. - **The status line describes what did not arrive, not how hard we tried.** A seed Google did not answer is now reported as "returned no data — never charged, details in ERRORS". ### 1.0.14 — 2026-08-30 Suite links now point at the full live shelf — every actor named in this README is a live store link. Nothing about what this actor delivers or charges changed. ### 1.0.13 — 2026-08-30 Review-fix build: one repair to resumed-run billing. - **A resumed run that cannot trust its own delivery record now stops rather than charging again.** Right after a run is moved or resurrected, the dataset read-back can momentarily lag behind what has already been charged. A run that trusted such a read would start the work over — fetching, delivering and charging a second time for rows you had already paid for. It now notices that its charges exceed what the record shows, stops cleanly without charging anything more, and says so. Re-running once the record has settled carries on normally. ### 1.0.12 — 2026-08-29 A run that runs out of time now stops cleanly, and a cost-capped run counts the seed it cut. - **A run close to its time limit now stops itself rather than being cut off mid-request.** A seed that had just enough time left to start could be killed by the platform partway through, ending the run without its status. The run now declines to start a fetch — or to wait out a rate-limit cooldown — that it cannot finish in time. It ends successfully with everything already delivered still delivered and charged, and the seeds it did not reach reported as left. Running out of our own time is never blamed on Google: no error is recorded and no "Google did not answer" row is written for a seed that was never actually asked. - **A cost cap that cuts a seed mid-list now counts that seed as left to do.** When your maximum cost per run stopped the last seed partway through its list, the status said "0 seed(s) left" — while telling you to raise the cap to fetch everything. A cut seed is genuinely unfinished (re-running it returns its full list), so it is now counted, and the number and the advice agree. - **Related topics: the answer in the FAQ was out of date.** It said Google's related-topics feed was returning empty data platform-wide. That is no longer true — the surface is delivered by the sibling actor [Google Trends · No Charge on Miss](https://apify.com/steadyfetch/google-trends-scraper), and the FAQ now points there. ### 1.0.11 — 2026-08-29 - A typo in an input field name now gets a helpful pointer instead of sample rows. When a run configures something but no search terms reach the actor — a misspelled field name, or settings with the keyword list left out — you get one uncharged row that names the field it did not recognise and the field it needed, rather than the sample output. - Running the actor with genuinely no input still returns the sample rows, exactly as before. - Added a live example dataset to the README: 12 rows from a verified run, including one seed that returned nothing and was not charged. ### 1.0.10 — 2026-08-27 - Hardening in the shared Google Trends engine this actor is built on: a reply that comes back valid but empty is now recognised as Google declining the request rather than accepted as a genuine empty answer, on every surface the engine can read. Such a reply is retried, and an answer that never arrives is reported as an uncharged miss. Rising and Breakout queries — the surface this actor reads — already behaved this way, so its own output is unchanged. ### 1.0.9 — 2026-08-27 Initial release. - Seed keywords in, Google Trends rising and Breakout queries out, one row per query. - `growthPercent` on every rising row, including the ones Google labels only `Breakout` — the number is in Google's payload and this actor ships it. - `isBreakout` reflects Google's own label and is never derived from the growth number. - Filters: `breakoutOnly`, `minGrowthPercent`, `maxResultsPerKeyword`, `geo`, `timeRange`, `category`, and an optional 12-month curve per rising query (`includeTimeline`). - Seeds with no rising data, seeds whose rows your filters removed, and fetches Google refused all ship as uncharged rows carrying `status` and `charged: false`. - Running the actor with no search terms returns sample rows without fetching anything. - Every seed on your list is attempted. A stretch of seeds that simply have no rising data is an answer, not a block, and no longer stops the run early with a rate-limit message. - The run message claims "Google blocked or refused every attempt" only when that is literally what happened — seeds that answered with an empty list are reported as their own outcome. - If the run ever breaks in an unexpected way it stops with a plain explanation and an `ERRORS` record instead of a bare crash: rows already delivered stay in your dataset, and nothing undelivered is charged. - A run that is interrupted and continues elsewhere, or that you resume after it has finished, never charges you twice for a keyword you already have and never adds a duplicate row. It carries on with the seeds it had not reached yet, and the closing message describes the whole run rather than only the part after the interruption. - A run's own time limit covers the whole run, so resuming one no longer restarts its clock. - In the rare case where a resumed run cannot check what it already delivered, it stops instead of guessing, charges nothing further, and tells you to re-run.