hzy24/validate-data – Datenvalidierung vor dem Teilen

/validate-data – Analyse vor dem Teilen validieren

Falls Sie unbekannte Platzhalter sehen oder prüfen möchten, welche Tools verbunden sind, lesen Sie CONNECTORS.md.

Überprüft eine Analyse auf Genauigkeit, Methodik und mögliche Verzerrungen, bevor sie an Stakeholder weitergegeben wird. Erstellt eine Vertrauenseinstufung und Verbesserungsvorschläge.

Verwendung

/validate-data <zu prüfende Analyse>

Die Analyse kann folgende Formate haben:

• Ein Dokument oder Bericht im Gespräch
• Eine Datei (Markdown, Notebook, Tabellenkalkulation)
• SQL-Abfragen und deren Ergebnisse
• Diagramme und deren zugrundeliegende Daten
• Eine Beschreibung der Methodik und der Ergebnisse

Arbeitsablauf

1. Methodik und Annahmen prüfen

Prüfen Sie:

• Fragenstellung: Beantwortet die Analyse die richtige Frage? Könnte die Frage anders interpretiert werden?
• Datenauswahl: Werden die richtigen Tabellen/Datensätze verwendet? Ist der Zeitraum angemessen?
• Populationsdefinition: Ist die analysierte Population korrekt definiert? Gibt es unbeabsichtigte Ausschlüsse?
• Metrikdefinitionen: Sind Metriken klar und konsistent definiert? Stimmen sie mit dem Verständnis der Stakeholder überein?
• Basislinie und Vergleich: Ist der Vergleich fair? Sind Zeiträume, Kohortengrößen und Kontexte vergleichbar?

2. Checkliste für die Qualitätssicherung vor der Auslieferung durchgehen

Arbeiten Sie die folgende Checkliste durch – Datenqualität, Berechnungen, Plausibilität und Darstellung.

3. Auf häufige Analysefehler prüfen

Systematisch gegen den detaillierten Fehlerkatalog unten prüfen (Join-Explosion, Survivorship Bias, unvollständiger Periodenvergleich, Nennerverschiebung, Durchschnitt von Durchschnitten, Zeitzonenkonflikte, Auswahlverzerrung).

4. Berechnungen und Aggregationen überprüfen

Wo möglich, stichprobenartig prüfen:

• Einige Schlüsselzahlen unabhängig nachberechnen
• Prüfen, ob Zwischensummen den Gesamtsummen entsprechen
• Prüfen, ob Prozentsätze (wo erwartet) 100 % ergeben (oder nahe dran sind)
• Bestätigen, dass YoY-/MoM-Vergleiche die korrekten Basiszeiträume verwenden
• Prüfen, ob Filter auf alle Metriken einheitlich angewendet werden

Wenden Sie die untenstehenden Techniken zur Plausibilitätsprüfung an (Größenordnungsprüfung, Kreuzvalidierung, Erkennung von roten Flaggen).

5. Visualisierungen bewerten

Falls die Analyse Diagramme enthält:

• Starten die Achsen bei geeigneten Werten (Null bei Balkendiagrammen)?
• Sind die Skalen über Vergleichsdiagramme hinweg konsistent?
• Beschreiben die Diagrammtitel genau, was dargestellt wird?
• Könnte die Visualisierung einen schnellen Leser in die Irre führen?
• Gibt es abgeschnittene Achsen, inkonsistente Intervalle oder 3D-Effekte, die die Wahrnehmung verzerren?

6. Erzählung und Schlussfolgerungen auswerten

Prüfen Sie, ob:

• Die Schlussfolgerungen durch die gezeigten Daten gestützt werden
• Alternative Erklärungen anerkannt werden
• Unsicherheit angemessen kommuniziert wird
• Die Empfehlungen logisch aus den Ergebnissen folgen
• Das Vertrauensniveau der Stärke der Evidenz entspricht

7. Verbesserungen vorschlagen

Geben Sie konkrete, umsetzbare Vorschläge:

• Zusätzliche Analysen, die die Schlussfolgerungen stärken würden
• Einschränkungen oder Vorbehalte, die genannt werden sollten
• Bessere Visualisierungen oder Darstellungen für wichtige Punkte
• Fehlender Kontext, den Stakeholder wissen möchten

8. Vertrauenseinstufung erstellen

Bewerten Sie die Analyse auf einer 3-stufigen Skala:

Bereit zum Teilen – Analyse ist methodisch einwandfrei, Berechnungen überprüft, Einschränkungen genannt. Kleinere Verbesserungsvorschläge, aber nichts Blockierendes.

Mit Einschränkungen teilen – Analyse ist weitgehend korrekt, hat aber spezifische Einschränkungen oder Annahmen, die den Stakeholdern mitgeteilt werden müssen. Nennen Sie die erforderlichen Einschränkungen.

Überarbeitung nötig – Es wurden spezifische Fehler, methodische Probleme oder fehlende Analysen gefunden, die vor dem Teilen behoben werden sollten. Nennen Sie die erforderlichen Änderungen in Prioritätsreihenfolge.

Ausgabeformat

## Validierungsbericht

### Gesamtbewertung: [Bereit zum Teilen | Mit Einschränkungen teilen | Überarbeitung nötig]

### Methodikprüfung
[Ergebnisse zu Ansatz, Datenauswahl, Definitionen]

### Gefundene Probleme
1. [Schweregrad: Hoch/Mittel/Niedrig] [Problembeschreibung und Auswirkung]
2. ...

### Stichprobenartige Berechnungsprüfungen
- [Metrik]: [Verifiziert / Abweichung gefunden]
- ...

### Visualisierungsprüfung
[Alle Probleme mit Diagrammen oder visueller Darstellung]

### Verbesserungsvorschläge
1. [Verbesserung und warum sie wichtig ist]
2. ...

### Erforderliche Einschränkungen für Stakeholder
- [Einschränkung, die mitgeteilt werden muss]
- ...

---

Checkliste für die Qualitätssicherung vor der Auslieferung

Führen Sie diese Checkliste durch, bevor Sie eine Analyse mit Stakeholdern teilen.

Datenqualitätsprüfungen

• Quellenverifizierung: Bestätigt, welche Tabellen/Datenquellen verwendet wurden. Sind sie die richtigen für diese Frage?
• Aktualität: Die Daten sind aktuell genug für die Analyse. Das „Stand“-Datum wurde vermerkt.
• Vollständigkeit: Keine unerwarteten Lücken in Zeitreihen oder fehlende Segmente.
• Null-Behandlung: Null-Raten in Schlüsselspalten wurden überprüft. Nullwerte werden angemessen behandelt (ausgeschlossen, imputiert oder gekennzeichnet).
• Deduplizierung: Bestätigt, dass keine Doppelzählungen durch schlechte Joins oder doppelte Quelldatensätze vorliegen.
• Filterprüfung: Alle WHERE-Klauseln und Filter sind korrekt. Keine unbeabsichtigten Ausschlüsse.

Berechnungsprüfungen

• Aggregationslogik: GROUP BY enthält alle nicht aggregierten Spalten. Die Aggregationsebene entspricht dem Analyse-Korn.
• Nennerkorrektheit: Raten- und Prozentberechnungen verwenden den richtigen Nenner. Die Nenner sind nicht Null.
• Datumsabgleich: Vergleiche verwenden die gleiche Zeitraumlänge. Teilzeiträume werden ausgeschlossen oder vermerkt.
• Join-Korrektheit: JOIN-Typen sind angemessen (INNER vs. LEFT). Viele-zu-viele-Joins haben keine Zählungen aufgebläht.
• Metrikdefinitionen: Metriken stimmen mit der Definition der Stakeholder überein. Abweichungen werden vermerkt.
• Zwischensummen: Teile ergeben dort das Ganze, wo erwartet. Wenn nicht, erklären Sie warum (z. B. Überlappungen).

Plausibilitätsprüfungen

• Größenordnung: Zahlen liegen in einem plausiblen Bereich. Umsatz ist nicht negativ. Prozentsätze liegen zwischen 0–100 %.
• Trendkontinuität: Keine unerklärten Sprünge oder Abfälle in Zeitreihen.
• Querverweise: Schlüsselzahlen stimmen mit anderen bekannten Quellen überein (Dashboards, frühere Berichte, Finanzdaten).
• Größenordnung: Gesamtumsatz liegt im richtigen Bereich. Benutzerzahlen entsprechen bekannten Werten.
• Randfälle: Was passiert an den Grenzen? Leere Segmente, Null-Aktivitätszeiträume, neue Entitäten.

Darstellungsprüfungen

• Diagrammgenauigkeit: Balkendiagramme beginnen bei Null. Achsen sind beschriftet. Skalen sind über Panels hinweg konsistent.
• Zahlenformatierung: Angemessene Genauigkeit. Einheitliches Währungs-/Prozentformat. Tausendertrennzeichen wo nötig.
• Titelklarheit: Titel geben die Erkenntnis an, nicht nur die Metrik. Datumsbereiche werden angegeben.
• Transparenz von Einschränkungen: Bekannte Einschränkungen und Annahmen werden explizit genannt.
• Reproduzierbarkeit: Eine andere Person könnte diese Analyse anhand der bereitgestellten Dokumentation nachvollziehen.

Häufige Datenanalysefehler

Join-Explosion

Das Problem: Ein Many-to-Many-Join multipliziert stillschweigend Zeilen und bläht Zählungen und Summen auf.

Wie man es erkennt:

-- Zeilenanzahl vor und nach dem Join prüfen
SELECT COUNT(*) FROM table_a;  -- 1.000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3.500 (Hilfe)

Wie man es verhindert:

• Überprüfen Sie immer die Zeilenanzahl nach Joins
• Wenn die Anzahl steigt, untersuchen Sie die Join-Beziehung (ist es wirklich 1:1 oder 1:many?)
• Verwenden Sie COUNT(DISTINCT a.id) anstelle von COUNT(*), wenn Sie Entitäten über Joins zählen

Survivorship Bias

Das Problem: Es werden nur Entitäten analysiert, die heute existieren, während gelöschte, abgewanderte oder gescheiterte ignoriert werden.

Beispiele:

• Analyse des Benutzerverhaltens „aktueller Benutzer“ übersieht abgewanderte Benutzer
• Betrachtung von „Unternehmen, die unser Produkt nutzen“ ignoriert diejenigen, die es evaluiert und verlassen haben
• Untersuchung von Eigenschaften „erfolgreicher“ Ergebnisse ohne „erfolglose“

Wie man es verhindert: Fragen Sie „Wer ist NICHT in diesem Datensatz?“, bevor Sie Schlussfolgerungen ziehen.

Unvollständiger Periodenvergleich

Das Problem: Ein Teilzeitraum wird mit einem vollständigen Zeitraum verglichen.

Beispiele:

• „Der Januar-Umsatz beträgt 500.000 € gegenüber 800.000 € im Dezember“ – aber der Januar ist noch nicht vorbei
• „Die Anmeldungen diese Woche sind gesunken“ – am Mittwoch geprüft, im Vergleich zu einer vollen vorherigen Woche

Wie man es verhindert: Filtern Sie immer auf vollständige Zeiträume oder vergleichen Sie denselben Tag des Monats / dieselbe Anzahl von Tagen.

Nennerverschiebung

Das Problem: Der Nenner ändert sich zwischen Perioden, wodurch Raten nicht vergleichbar werden.

Beispiele:

• Die Konversionsrate verbessert sich, weil die Zählung „berechtigter“ Benutzer geändert wurde
• Die Abwanderungsrate ändert sich, weil die Definition von „aktiv“ aktualisiert wurde

Wie man es verhindert: Verwenden Sie konsistente Definitionen über alle verglichenen Perioden hinweg. Notieren Sie etwaige Definitionsänderungen.

Durchschnitt von Durchschnitten

Das Problem: Das Mitteln von vorberechneten Durchschnitten liefert falsche Ergebnisse, wenn sich die Gruppengrößen unterscheiden.

Beispiel:

• Gruppe A: 100 Benutzer, durchschnittlicher Umsatz 50 €
• Gruppe B: 10 Benutzer, durchschnittlicher Umsatz 200 €
• Falsch: Durchschnitt der Durchschnitte = (50 € + 200 €) / 2 = 125 €
• Richtig: Gewichteter Durchschnitt = (10050 € + 10200 €) / 110 = 63,64 €

Wie man es verhindert: Aggregieren Sie immer aus Rohdaten. Mitteln Sie niemals voraggregierte Durchschnitte.

Zeitzonenkonflikte

Das Problem: Verschiedene Datenquellen verwenden unterschiedliche Zeitzonen, was zu Fehlausrichtungen führt.

Beispiele:

• Ereigniszeitstempel in UTC vs. benutzerseitige Daten in Ortszeit
• Tägliche Zusammenstellungen mit unterschiedlichen Stichtagszeiten

Wie man es verhindert: Standardisieren Sie alle Zeitstempel vor der Analyse auf eine einzige Zeitzone (UTC empfohlen). Dokumentieren Sie die verwendete Zeitzone.

Auswahlverzerrung bei der Segmentierung

Das Problem: Segmente werden durch das zu messende Ergebnis definiert, was eine zirkuläre Logik erzeugt.

Beispiele:

• „Benutzer, die die Einführung abgeschlossen haben, haben eine höhere Bindung“ – offensichtlich haben sie sich selbst ausgewählt
• „Power-User generieren mehr Umsatz“ – sie wurden zu Power-Usern, INDEM sie Umsatz generierten

Wie man es verhindert: Definieren Sie Segmente basierend auf Eigenschaften vor der Behandlung, nicht auf Ergebnissen.

Andere statistische Fallen

• Simpson-Paradoxon: Trend kehrt sich um, wenn Daten aggregiert vs. segmentiert werden
• Korrelation als Kausalität dargestellt ohne unterstützende Evidenz
• Kleine Stichprobengrößen, die zu unzuverlässigen Schlussfolgerungen führen
• Ausreißer, die Durchschnitte unverhältnismäßig beeinflussen (sollten stattdessen Mediane verwendet werden?)
• Mehrfachtesten / Cherry-Picking signifikanter Ergebnisse
• Vorausschau-Bias: Verwendung zukünftiger Informationen zur Erklärung vergangener Ereignisse
• Gecherrypickte Zeiträume, die eine bestimmte Erzählung begünstigen

Plausibilitätsprüfung von Ergebnissen

Größenordnungsprüfungen

Überprüfen Sie für jede Schlüsselzahl in Ihrer Analyse, ob sie den „Riechtest“ besteht:

Metriktyp	Plausibilitätsprüfung
Benutzerzahlen	Entspricht dies bekannten MAU/DAU-Werten?
Umsatz	Liegt dies in der richtigen Größenordnung im Vergleich zum bekannten ARR?
Konversionsraten	Liegt dies zwischen 0 % und 100 %? Stimmt es mit Dashboard-Werten überein?
Wachstumsraten	Ist ein monatliches Wachstum von 50 %+ realistisch oder ein Datenproblem?
Durchschnitte	Ist der Durchschnitt angesichts der bekannten Verteilung vernünftig?
Prozentsätze	Ergeben Segmentprozentsätze ~100 %?

Kreuzvalidierungstechniken

1. Berechnen Sie dieselbe Metrik auf zwei verschiedene Arten und prüfen Sie, ob sie übereinstimmen
2. Stichprobenartig einzelne Datensätze prüfen – wählen Sie ein paar spezifische Entitäten aus und verfolgen Sie deren Daten manuell
3. Mit bekannten Benchmarks vergleichen – gegen veröffentlichte Dashboards, Finanzberichte oder frühere Analysen abgleichen
4. Reverse Engineering – wenn der Gesamtumsatz X beträgt, ergibt der Umsatz pro Benutzer multipliziert mit der Benutzeranzahl ungefähr X?
5. Grenzprüfungen – was passiert, wenn Sie auf einen einzelnen Tag, einen einzelnen Benutzer oder eine einzelne Kategorie filtern? Sind diese Mikroergebnisse sinnvoll?

Rote Flaggen, die eine Untersuchung erfordern

• Jede Metrik, die sich gegenüber dem Vormonat um mehr als 50 % ohne offensichtlichen Grund geändert hat
• Zählungen oder Summen, die exakte runde Zahlen sind (deutet auf ein Filter- oder Standardwertproblem hin)
• Raten, die exakt 0 % oder 100 % betragen (kann auf unvollständige Daten hinweisen)
• Ergebnisse, die die Hypothese perfekt bestätigen (die Realität ist normalerweise chaotischer)
• Identische Werte über Zeiträume oder Segmente hinweg (deutet darauf hin, dass die Abfrage eine Dimension ignoriert)

Dokumentationsstandards für Reproduzierbarkeit

Vorlage für Analysedokumentation

Jede nicht-triviale Analyse sollte Folgendes enthalten:

## Analyse: [Titel]

### Frage
[Die spezifische Frage, die beantwortet wird]

### Datenquellen
- Tabelle: [schema.table_name] (Stand: [Datum])
- Tabelle: [schema.other_table] (Stand: [Datum])
- Datei: [Dateiname] (Quelle: [woher sie stammt])

### Definitionen
- [Metrik A]: [Genau, wie sie berechnet wird]
- [Segment X]: [Genau, wie die Zugehörigkeit bestimmt wird]
- [Zeitraum]: [Startdatum] bis [Enddatum], [Zeitzone]

### Methodik
1. [Schritt 1 des Analyseansatzes]
2. [Schritt 2]
3. [Schritt 3]

### Annahmen und Einschränkungen
- [Annahme 1 und warum sie vernünftig ist]
- [Einschränkung 1 und ihre potenziellen Auswirkungen auf die Schlussfolgerungen]

### Wichtigste Ergebnisse
1. [Ergebnis 1 mit unterstützenden Belegen]
2. [Ergebnis 2 mit unterstützenden Belegen]

### SQL-Abfragen
[Alle verwendeten Abfragen mit Kommentaren]

### Einschränkungen
- [Dinge, die der Leser wissen sollte, bevor er daraufhin handelt]

Codedokumentation

Für jeden Code (SQL, Python), der wiederverwendet werden könnte:

"""
Analyse: Monatliche Kohortenbindung
Autor: [Name]
Datum: [Datum]
Datenquelle: events-Tabelle, users-Tabelle
Zuletzt validiert: [Datum] – Ergebnisse stimmen mit Dashboard innerhalb von 2 % überein

Zweck:
    Berechnung monatlicher Benutzerbindungskohorten basierend auf dem ersten Aktivitätsdatum.

Annahmen:
    - „Aktiv“ bedeutet mindestens ein Ereignis im Monat
    - Schließt Test-/interne Konten aus (user_type != 'internal')
    - Verwendet UTC-Daten durchgehend

Ausgabe:
    Kohortenbindungsmatrix mit cohort_month-Zeilen und months_since_signup-Spalten.
    Werte sind Bindungsraten (0–100 %).
"""

Versionskontrolle für Analysen

• Speichern Sie Abfragen und Code in der Versionskontrolle (git) oder einem gemeinsamen Dokumentsystem
• Notieren Sie das Datum des verwendeten Datenschnappschusses
• Wenn eine Analyse mit aktualisierten Daten erneut ausgeführt wird, dokumentieren Sie, was sich geändert hat und warum
• Verlinken Sie zu früheren Versionen von wiederkehrenden Analysen für Trendvergleiche

Beispiele

/validate-data Überprüfen Sie diese vierteljährliche Umsatzanalyse, bevor ich sie an die Geschäftsleitung sende: [Analyse]

/validate-dat

…

[abgeschnitten für die Übersetzung]