GSC surge refresh signal¶
One of five non-exclusive signals that drive the GT/GKP refresh decision. Fires when the keyword's recent GSC impressions diverge sharply from its prior baseline — the most common reason to request a fresh GT/GKP pull.
What it is¶
A keyword whose last 3 months of GSC impressions average is more than 50% off (in either direction) from the prior 3 months gets flagged. The strength of the surge contributes to gt_priority (and conditionally to gkp_priority).
Signal name in the signals[] array: "surge".
How it's computed¶
At processing.py:KB-ANCHOR:refresh-signal-gsc-surge:
| Step | Rule |
|---|---|
| Floor | processed_keyword_volume >= 50 AND ≥ 6 months of GSC data exist |
| Ratio | abs(avg(recent_3) - avg(prior_3)) / avg(prior_3) |
| Trigger | ratio > 0.5 (i.e. > 50% change) |
| Strength | min(ratio, 5.0) — capped at 5× |
| GT contribution | min(3.0, strength × consistency) (consistency from surge-consistency multiplier) |
| GKP contribution | min(2.0, strength × 0.7) only if GSC's latest month is ≥ 2 months stale (otherwise GKP hasn't seen the surge yet) |
Why this choice¶
Empirically tuned on real data. Distributions of GSC month-over-month changes show that real shifts dominate noise above ~50%; below that, most flagged keywords were oscillating without a true regime change. The volume ≥ 50 floor exists because relative-change ratios explode for near-zero-volume keywords (a jump from 2 to 6 impressions is a 200% surge, but it's noise).
The asymmetric GT-vs-GKP contribution (3.0 vs 2.0) reflects that GT is the better source for short-window verification, while GKP confirms longer-term shifts — and the 2-month GSC-lag check on GKP exists because GKP itself lags 1–2 months behind real-time, so requesting it sooner is wasted.
Edge cases¶
- First 6 months of a keyword's life — the signal never fires; not enough history to compare windows.
- Recovery after a dip — a 50%+ recovery from a depressed baseline also fires (the signal is sign-agnostic). This is intentional: a recovering brand keyword needs a refreshed GT/GKP to update the forecast just as much as a surging one.
- Stable but noisy keywords — the
volume ≥ 50floor catches most false positives. The remaining ones get caught by the priority formula's volume scaling which downweights low-volume contributions.
See also¶
- Refresh surge consistency multiplier — the sub-multiplier for single-spike surges
- Refresh priority formula — how this signal's contribution combines with the others
- Refresh signals overview — the field that stores the output
- Archive:
_archive/refresh_detection.md