Establishing Your Traffic Noise Floor

Organic traffic moves week to week for reasons nobody controls: day-of-week mix, bank holidays, a slow crawl, a reporting tool revising its own numbers. A team that has never measured its own variance investigates every dip, which burns days and teaches everyone to ignore alerts, including the one that matters. Characterise normal variation once per segment and set thresholds from that rather than from a round number somebody liked the sound of.

Le fichier de compétence

---
name: organic-traffic-noise-floor
description: Use when a weekly dip triggers an investigation and nobody can say whether the move is outside normal variance.
---

# Establishing Your Traffic Noise Floor

Organic traffic moves week to week for reasons nobody controls: day-of-week mix, bank holidays, a slow crawl, a reporting tool revising its own numbers. A team that has never measured its own variance investigates every dip, which burns days and teaches everyone to ignore alerts, including the one that matters. Characterise normal variation once per segment and set thresholds from that rather than from a round number somebody liked the sound of.

## Ce qu’il vous faut d’abord

- 13 months of daily clicks or sessions per reporting segment
- a change log of known one-off events so they can be excluded from the baseline
- the reporting delay and revision behaviour of your data source

## Méthode

1. Work in whole weeks from a fixed weekday. Day-of-week effects are routinely larger than the movements people escalate, and daily comparisons will keep manufacturing them.
2. Strip known one-off events out of the history first, using the change log. Leaving a migration week in the baseline widens the floor and hides real problems for a year afterwards.
3. Compute week-on-week percentage change across the cleaned history per segment and take a high percentile of the absolute change, the 90th being a reasonable starting point, as that segment threshold.
4. Repeat the calculation year on year for the same week so seasonality is carried rather than fought. A December fall that repeats every December is not a finding.
5. Set thresholds per segment rather than sitewide. Small segments are noisier by construction, so a single shared threshold either floods you with alerts from the small ones or stays silent through a real fall in the large one.
6. Add a persistence rule: two consecutive weeks past the threshold, or one week past a much larger one. Single-week spikes are usually artefacts, particularly in data that revises after the fact.
7. Recompute the floor every six months and after any tracking or segmentation change, then write the current thresholds into the report itself so nobody has to remember them.

## Ce que ça produit

A per-segment table of alert thresholds with the percentile used, the events excluded from the baseline and the persistence rule, refreshed twice a year.

## Là où ça dérape

- Setting one sitewide threshold, so the small segments cry wolf and the large one stays quiet through a genuine decline
- Including the last two or three days of Search Console data, which are incomplete and always look like a fall
- Treating the threshold as a significance test, when it is a triage rule for where to look and not evidence that anything caused anything
- Rebuilding the baseline over a period that already contained a sustained decline, which normalises the decline into the definition of normal

---

Extrait de la bibliothèque de compétences QuQi - https://www.quqi.io/fr/skills/organic-traffic-noise-floor

Ce qu’il vous faut d’abord

• 13 months of daily clicks or sessions per reporting segment
• a change log of known one-off events so they can be excluded from the baseline
• the reporting delay and revision behaviour of your data source

Méthode

1. 01 Work in whole weeks from a fixed weekday. Day-of-week effects are routinely larger than the movements people escalate, and daily comparisons will keep manufacturing them.
2. 02 Strip known one-off events out of the history first, using the change log. Leaving a migration week in the baseline widens the floor and hides real problems for a year afterwards.
3. 03 Compute week-on-week percentage change across the cleaned history per segment and take a high percentile of the absolute change, the 90th being a reasonable starting point, as that segment threshold.
4. 04 Repeat the calculation year on year for the same week so seasonality is carried rather than fought. A December fall that repeats every December is not a finding.
5. 05 Set thresholds per segment rather than sitewide. Small segments are noisier by construction, so a single shared threshold either floods you with alerts from the small ones or stays silent through a real fall in the large one.
6. 06 Add a persistence rule: two consecutive weeks past the threshold, or one week past a much larger one. Single-week spikes are usually artefacts, particularly in data that revises after the fact.
7. 07 Recompute the floor every six months and after any tracking or segmentation change, then write the current thresholds into the report itself so nobody has to remember them.

Ce que ça produit

A per-segment table of alert thresholds with the percentile used, the events excluded from the baseline and the persistence rule, refreshed twice a year.

Là où ça dérape

• Setting one sitewide threshold, so the small segments cry wolf and the large one stays quiet through a genuine decline
• Including the last two or three days of Search Console data, which are incomplete and always look like a fall
• Treating the threshold as a significance test, when it is a triage rule for where to look and not evidence that anything caused anything
• Rebuilding the baseline over a period that already contained a sustained decline, which normalises the decline into the definition of normal

Utiliser cette compétence dans votre propre IA

Le fichier téléchargé est un simple markdown dont l'en-tête porte le nom et le déclencheur. Quand un assistant sait charger des compétences tout seul, c'est cet en-tête qu'il lit pour décider que celle-ci s'applique.

Plus dans Analyse et rapports