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.

El archivo de la habilidad

---
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.

## Qué necesitas antes

- 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étodo

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.

## Qué produce esto

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.

## Dónde falla esto

- 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

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/organic-traffic-noise-floor

Qué necesitas antes

• 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étodo

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.

Qué produce esto

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.

Dónde falla esto

• 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

Usa esta skill en tu propia IA

El archivo es markdown simple, con el nombre y el disparador en su frontmatter. Cuando un asistente sabe cargar skills por su cuenta, es ese frontmatter lo que lee para decidir que esta le aplica.

Más en Analítica e informes