Das Rauschniveau Ihres Traffics bestimmen

Organischer Traffic bewegt sich von Woche zu Woche aus Gründen, die niemand steuert: Wochentagsmix, Feiertage, ein langsamer Crawl, ein Reporting-Werkzeug, das seine eigenen Zahlen nachträglich korrigiert. Ein Team, das die eigene Varianz nie gemessen hat, untersucht jeden Rückgang, was Tage verbrennt und allen beibringt, Alarme zu ignorieren, auch den einen, der zählt. Beschreiben Sie die normale Schwankung einmal je Segment und leiten Sie die Schwellen daraus ab statt aus einer runden Zahl, die jemandem gefallen hat.

Die Skill-Datei

---
name: organic-traffic-noise-floor
description: Nutzen Sie dies, wenn ein wöchentlicher Rückgang eine Untersuchung auslöst und niemand sagen kann, ob die Bewegung außerhalb der normalen Schwankung liegt.
---

# Das Rauschniveau Ihres Traffics bestimmen

Organischer Traffic bewegt sich von Woche zu Woche aus Gründen, die niemand steuert: Wochentagsmix, Feiertage, ein langsamer Crawl, ein Reporting-Werkzeug, das seine eigenen Zahlen nachträglich korrigiert. Ein Team, das die eigene Varianz nie gemessen hat, untersucht jeden Rückgang, was Tage verbrennt und allen beibringt, Alarme zu ignorieren, auch den einen, der zählt. Beschreiben Sie die normale Schwankung einmal je Segment und leiten Sie die Schwellen daraus ab statt aus einer runden Zahl, die jemandem gefallen hat.

## Was Sie vorher brauchen

- 13 Monate tägliche Klicks oder Sessions je Reporting-Segment
- ein Änderungsprotokoll bekannter Einmalereignisse, damit sie aus der Basislinie ausgeschlossen werden können
- die Meldeverzögerung und das Korrekturverhalten Ihrer Datenquelle

## Methode

1. Arbeiten Sie in ganzen Wochen ab einem festen Wochentag. Wochentagseffekte sind regelmäßig größer als die Bewegungen, die Menschen eskalieren, und Tagesvergleiche produzieren sie immer wieder neu.
2. Schneiden Sie zuerst bekannte Einmalereignisse anhand des Änderungsprotokolls aus der Historie. Eine Migrationswoche in der Basislinie stehen zu lassen weitet das Rauschniveau und verbirgt echte Probleme noch ein Jahr danach.
3. Berechnen Sie je Segment die prozentuale Veränderung von Woche zu Woche über die bereinigte Historie und nehmen Sie ein hohes Perzentil der absoluten Veränderung, das 90. ist ein vernünftiger Ausgangspunkt, als Schwelle für dieses Segment.
4. Wiederholen Sie die Rechnung im Jahresvergleich für dieselbe Woche, damit Saisonalität mitgeführt statt bekämpft wird. Ein Dezemberrückgang, der sich jeden Dezember wiederholt, ist kein Befund.
5. Setzen Sie Schwellen je Segment statt site-weit. Kleine Segmente rauschen bauartbedingt stärker, deshalb überflutet Sie eine einzige gemeinsame Schwelle entweder mit Alarmen aus den kleinen oder schweigt durch einen echten Rückgang im großen hindurch.
6. Ergänzen Sie eine Persistenzregel: zwei aufeinanderfolgende Wochen über der Schwelle oder eine Woche über einer deutlich höheren. Einzelne Wochenausschläge sind meist Artefakte, besonders in Daten, die nachträglich korrigiert werden.
7. Berechnen Sie das Rauschniveau alle sechs Monate neu und nach jeder Änderung an Tracking oder Segmentierung, und schreiben Sie die aktuellen Schwellen in den Report selbst, damit niemand sie sich merken muss.

## Was dabei herauskommt

Eine Tabelle der Alarmschwellen je Segment mit dem verwendeten Perzentil, den aus der Basislinie ausgeschlossenen Ereignissen und der Persistenzregel, zweimal jährlich aufgefrischt.

## Wo es schiefgeht

- Eine einzige site-weite Schwelle zu setzen, sodass die kleinen Segmente ständig Alarm schlagen und das große durch einen echten Rückgang hindurch stumm bleibt
- Die letzten zwei oder drei Tage der Search-Console-Daten einzubeziehen, die unvollständig sind und immer wie ein Rückgang aussehen
- Die Schwelle als Signifikanztest zu behandeln, obwohl sie eine Triage-Regel dafür ist, wo man nachsieht, und kein Beleg dafür, dass irgendetwas irgendetwas verursacht hat
- Die Basislinie über einen Zeitraum neu zu bilden, der bereits einen anhaltenden Rückgang enthielt, was den Rückgang zur Definition des Normalen macht

---

Aus der QuQi-Skill-Bibliothek - https://www.quqi.io/de/skills/organic-traffic-noise-floor

Was Sie vorher brauchen

• 13 Monate tägliche Klicks oder Sessions je Reporting-Segment
• ein Änderungsprotokoll bekannter Einmalereignisse, damit sie aus der Basislinie ausgeschlossen werden können
• die Meldeverzögerung und das Korrekturverhalten Ihrer Datenquelle

Methode

1. 01 Arbeiten Sie in ganzen Wochen ab einem festen Wochentag. Wochentagseffekte sind regelmäßig größer als die Bewegungen, die Menschen eskalieren, und Tagesvergleiche produzieren sie immer wieder neu.
2. 02 Schneiden Sie zuerst bekannte Einmalereignisse anhand des Änderungsprotokolls aus der Historie. Eine Migrationswoche in der Basislinie stehen zu lassen weitet das Rauschniveau und verbirgt echte Probleme noch ein Jahr danach.
3. 03 Berechnen Sie je Segment die prozentuale Veränderung von Woche zu Woche über die bereinigte Historie und nehmen Sie ein hohes Perzentil der absoluten Veränderung, das 90. ist ein vernünftiger Ausgangspunkt, als Schwelle für dieses Segment.
4. 04 Wiederholen Sie die Rechnung im Jahresvergleich für dieselbe Woche, damit Saisonalität mitgeführt statt bekämpft wird. Ein Dezemberrückgang, der sich jeden Dezember wiederholt, ist kein Befund.
5. 05 Setzen Sie Schwellen je Segment statt site-weit. Kleine Segmente rauschen bauartbedingt stärker, deshalb überflutet Sie eine einzige gemeinsame Schwelle entweder mit Alarmen aus den kleinen oder schweigt durch einen echten Rückgang im großen hindurch.
6. 06 Ergänzen Sie eine Persistenzregel: zwei aufeinanderfolgende Wochen über der Schwelle oder eine Woche über einer deutlich höheren. Einzelne Wochenausschläge sind meist Artefakte, besonders in Daten, die nachträglich korrigiert werden.
7. 07 Berechnen Sie das Rauschniveau alle sechs Monate neu und nach jeder Änderung an Tracking oder Segmentierung, und schreiben Sie die aktuellen Schwellen in den Report selbst, damit niemand sie sich merken muss.

Was dabei herauskommt

Eine Tabelle der Alarmschwellen je Segment mit dem verwendeten Perzentil, den aus der Basislinie ausgeschlossenen Ereignissen und der Persistenzregel, zweimal jährlich aufgefrischt.

Wo es schiefgeht

• Eine einzige site-weite Schwelle zu setzen, sodass die kleinen Segmente ständig Alarm schlagen und das große durch einen echten Rückgang hindurch stumm bleibt
• Die letzten zwei oder drei Tage der Search-Console-Daten einzubeziehen, die unvollständig sind und immer wie ein Rückgang aussehen
• Die Schwelle als Signifikanztest zu behandeln, obwohl sie eine Triage-Regel dafür ist, wo man nachsieht, und kein Beleg dafür, dass irgendetwas irgendetwas verursacht hat
• Die Basislinie über einen Zeitraum neu zu bilden, der bereits einen anhaltenden Rückgang enthielt, was den Rückgang zur Definition des Normalen macht

Diese Skill in Ihrer eigenen KI nutzen

Die Datei ist einfaches Markdown, mit Name und Auslöser im Frontmatter. Wo ein Assistent Skills selbst laden kann, liest er genau dieses Frontmatter, um zu entscheiden, dass diese hier passt.

Mehr in Analytics & Reporting