# Changelog of Keyword Comparison & Seasonality 📈 (Google Trends, 1 scale) (`tagadanar/keyword-comparison-seasonality`) Actor

- **URL**: https://apify.com/tagadanar/keyword-comparison-seasonality/changelog.md
- **Full Actor documentation**: https://apify.com/tagadanar/keyword-comparison-seasonality.md

## Changelog

### 2026-09-14

- **A brief Google Trends rate limit no longer fails the run.** The retries used
  to spend themselves in about ten seconds, so a short throttle ended the run
  red. The request now keeps trying for up to about a minute on fresh
  connections, with real waits in between, and a network hiccup is retried
  instead of ending the run on the first try.
- The comparison timeline is fetched first and on its own, so a throttle on the
  optional related-queries requests can no longer take the comparison down with it.
- When Google really does refuse, the run says so plainly (temporary, nothing
  charged, retry in a few minutes) and no longer tells you to enable a proxy
  setting that does not exist. A run that hit its own time limit, and one that
  could not reach Google at all, are each named as such.

### 0.1.2 (2026-08-29)

- Every run now ends with a status message that says what happened. It is built
  by a pure function from explicit counters, so it can only talk about the
  keywords after Google actually served the shared comparison timeline and the
  run read it. The 5-keyword cap, an own-scale fallback, a tie at the top of the
  shared scale and a widget that did not answer are each named rather than left
  silent.
- README: the Related actors section now also points at Trending Searches Today,
  which already linked back here.

### 0.1.0

First release.

Compares 2 to 5 keywords on one shared Google Trends scale and reports each
keyword's season: peak months, low months, a 0 to 100 seasonality strength,
year-over-year direction, and the rising related queries.

Two things worth knowing about how it works, because they change what the numbers
mean:

- The comparison comes from one request carrying every keyword, which is what
  makes the values comparable. The `sharedScale` field is the check that it
  really happened.
- The seasonality comes from a second pass, one request per keyword alone. On a
  shared scale a dominant keyword flattens the rest into whole numbers, and a
  pattern read off that is rounding, not a season.

When a number cannot honestly be produced, the record says why in
`seasonalityNote` or `yearOverYearNote` instead of guessing.