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.

The skill file

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

## What you need first

- 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

## Method

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.

## What this produces

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.

## Where this goes wrong

- 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

---

From the QuQi skill library - https://www.quqi.io/skills/organic-traffic-noise-floor

What you need first

• 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

Method

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.

What this produces

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.

Where this goes wrong

• 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 this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in Analytics & reporting