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.

O ficheiro da competência

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

## O que precisa primeiro

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

## O que isto produz

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.

## Onde isto corre mal

- 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

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/organic-traffic-noise-floor

O que precisa primeiro

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

O que isto produz

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.

Onde isto corre mal

• 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

Use esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em Métricas e relatórios