+150 XP

Audit eines SaaS-Data-Stacks: eine diagnostische Tour

# Audit eines SaaS-Data-Stacks: eine diagnostische Tour

Eine VP of Analytics eines mittelständischen SaaS-Unternehmens öffnet vor einer Board-Sitzung zwei Dashboards. Das eine zeigt, dass die monatlich aktiven Nutzer um 12 % gewachsen sind. Das andere, gebaut auf demselben Event-Stream, zeigt 4 %. Beide sind seit Monaten „live“. Niemand hat es bemerkt, weil niemand die Pipeline auditiert hat, sondern alle nur deren Output konsumiert haben. Das passiert ständig, und deshalb sind Daten-Audits inzwischen ein fester Punkt in SaaS-Operating-Reviews.

Diese Lektion geht einen typischen SaaS-Data-Stack Schicht für Schicht durch und zeigt, was kaputtgeht, wie Sie es erkennen und was Sie regelmäßig prüfen sollten.

Die Anatomie eines SaaS-Data-Stacks

Die meisten SaaS-Unternehmen betreiben eine Variante dieser Pipeline:

1. Product Event Stream: Instrumentierung (über Tools wie Segment, Amplitude oder ein eigenes SDK), die Nutzeraktionen erfasst (signup_completed, feature_used, subscription_upgraded).

2. Ingestion Layer: leitet Events in die Speicherung, oft über eine CDP (Customer Data Platform) oder ein Streaming-Tool (Kafka, Fivetran).

3. Data Warehouse: der analytische Speicher (Snowflake, BigQuery, Databricks), in dem rohe und transformierte Daten liegen.

4. Transformation Layer: SQL-Modellierungstools (dbt ist das dominierende), die rohe Events in saubere, geschäftstaugliche Tabellen verwandeln.

5. BI Layer: Dashboards (Looker, Tableau, Mode), die Business-Nutzer tatsächlich zu sehen bekommen.

Jede Übergabe zwischen diesen Schichten ist eine Stelle, an der Vertrauen erodiert. Auditieren heißt, jede Nahtstelle zu prüfen, nicht nur das finale Dashboard.

Schicht 1: Event Stream und Schema Drift

Schema Drift bedeutet, dass sich die Struktur eingehender Daten ohne Vorwarnung ändert: Ein Feld wird umbenannt, ein Datentyp wechselt von String zu Integer, ein neues Event ersetzt ein altes, und nichts weiter unten in der Kette erfährt davon.

Beispiel: Engineering benennt plan_type bei einem Refactoring in subscription_tier um. Das Dashboard zur Upgrade-Conversion, gebaut auf plan_type, aktualisiert sich stillschweigend nicht mehr. Es wirft keinen Fehler, es friert einfach ein oder liefert Nulls, und oft merkt es wochenlang niemand.

Was zu prüfen ist:

  • Laufen Schema-Tests bei der Ingestion (z. B. Prüfung, ob erwartete Felder existieren und Typen passen)?
  • Gibt es einen Data Contract zwischen Product/Engineering und Analytics, also eine dokumentierte Vereinbarung über Event-Namen, Pflichtattribute und den Prozess zur Änderungsbenachrichtigung?
  • Wann wurde der Tracking Plan (die Master-Spezifikation, welche Events feuern sollen und was sie enthalten) zuletzt mit den tatsächlichen Events im Warehouse abgeglichen?

Eine praktische kostenlose Ressource für Disziplin beim Tracking Plan ist Segments Tracking-Plan-Dokumentation, ein brauchbares Template, auch wenn Sie Segment nicht nutzen.

Schicht 2: Ingestion und Orphaned Events

Orphaned Events sind Datensätze, die im Warehouse ankommen, aber mit nichts Sinnvollem verknüpft werden können: ein feature_used-Event ohne passende user_id oder eine User-ID, die in der Users-Tabelle nicht existiert, weil der Account gelöscht wurde oder sich das ID-Format geändert hat.

Orphaned Events sind relevant, weil sie Kennzahlen unbemerkt nach unten oder oben verzerren. Wenn 8 % Ihrer feature_used-Events keinem gültigen Account zugeordnet werden können (eine plausible Größenordnung aus Data-Quality-Audits, als Schätzung zu behandeln, die tatsächlichen Raten schwanken stark je nach Unternehmen), ist Ihre Feature-Adoption-Rate um etwa diesen Betrag falsch, in die Richtung, in die die verwaisten Daten verzerren.

Schnellprüfung, durchgerechnetes Beispiel:

Angenommen, Ihr Warehouse protokolliert in einem Monat 500.000 feature_used-Events. Ein Join gegen die Tabelle dim_users liefert 460.000 gematchte Zeilen.

orphan_rate = (500,000 - 460,000) / 500,000 = 8.0%

Eine Orphan Rate von 8 % ist eine typische Schwelle, ab der Teams zu untersuchen beginnen (manche setzen Alerting bei 2 bis 5 %, enger bei abrechnungskritischen Events). Unterhalb von rund 1 bis 2 % ist es häufig Hintergrundrauschen durch Timing-Verzögerungen (ein Nutzer handelt kurz bevor die Account-Löschung durchläuft). Darüber deutet es meist auf einen defekten Join Key oder einen Integrations-Bug hin.

Was zu prüfen ist:

  • Welcher Prozentsatz der Kern-Events lässt sich nicht auf eine gültige Entität (User, Account, Subscription) joinen?
  • Gibt es eine Dead Letter Queue (einen Ablagebereich für Events, deren Verarbeitung fehlschlägt), die auch tatsächlich jemand durchsieht?

Schicht 3: Warehouse sowie doppelte oder fehlende Datensätze

Zwei häufige Fehlerbilder auf dieser Schicht:

  • Duplikation: Die Retry-Logik einer API-Integration sendet dasselbe Event erneut und bläht Zählungen auf. Ein dreimal wiederholter Stripe-Webhook kann ein subscription_created-Event dreifach zählen, wenn es keinen Idempotency Key gibt (eine eindeutige Kennung, die verhindert, dass dasselbe Event zweimal verarbeitet wird).
  • Spät eintreffende Daten: Nutzungsevents aus einem Mobile SDK, das Daten bündelt und erst beim erneuten Öffnen der App synchronisiert, wodurch das gestrige Dashboard künstlich niedrig aussieht und Tage später „nach oben revidiert“ wird.

Was zu prüfen ist:

  • Zeilenzahlen der Schlüsseltabellen im Zeitverlauf: plötzliche Ausschläge nach oben oder unten gehören untersucht.
  • Gibt es dbt-Tests auf Eindeutigkeit und Not-Null-Constraints für Primary Keys?

Ein minimaler dbt-Test, der prüft, dass subscription_id eindeutig und nie null ist:

yaml
models:
  - name: fct_subscriptions
    columns:
      - name: subscription_id
        tests:
          - unique
          - not_null

Das ist eine Fünf-Minuten-Maßnahme, die eine ganze Klasse stiller Duplikations-Bugs davon abhält, je auf einem Dashboard zu landen.

Schicht 4: BI und veraltete Dashboards

Stale Dashboards sind Dashboards, die weiterhin laufen, weiterhin in Ordnung aussehen, aber ein kaputtes oder überholtes Datenmodell abbilden. Ursachen: Eine vorgelagerte Tabelle wird nicht mehr aktualisiert, ein Filter wurde auf einen alten Datumsbereich hartkodiert, oder die zugrunde liegende Metrikdefinition hat sich geändert, das Dashboard wurde aber nicht neu gebaut.

Eine Branchenumfrage von Monte Carlo (einem Anbieter für Data Observability) aus 2023 ergab, dass Datenteams in typischen Organisationen einen erheblichen Teil ihrer Zeit mit dem Löschen von Datenqualitätsbränden statt mit proaktiver Analyse verbringen; exakte Prozentwerte sind als anbietergemeldete Schätzungen zu behandeln, die Richtung ist in der Data-Engineering-Community aber gut belegt.

Was zu prüfen ist:

  • Dashboard-Owner und Datum der letzten Verifizierung: Hat ein Dashboard keinen benannten Owner, gehen Sie davon aus, dass es nicht gepflegt wird.
  • Freshness-Metadaten: Zeigt das BI-Tool an, wann die zugrunde liegenden Daten zuletzt aktualisiert wurden?
  • Konsistenz der Metrikdefinitionen: Ist „aktiver Nutzer“ einmal zentral definiert (idealerweise in einem Metrics Layer wie dbts Semantic Layer oder einem Tool wie Cube), oder wird es in jedem Dashboard ad hoc neu definiert?

Wissenscheck

1. Im Eingangsszenario zeigten zwei Dashboards, die auf demselben Event-Stream basierten, monatelang unterschiedliche MAU-Wachstumszahlen, ohne dass es auffiel. Was veranschaulicht das vor allem?

2. Warum ist Schema Drift im Vergleich zu einem typischen Software-Bug besonders gefährlich?

3. Ein Feld mit dem Namen `plan_type` wird bei einem Engineering-Refactor in `subscription_tier` umbenannt, und ein Downstream-Dashboard wird ohne Fehlermeldung nicht mehr aktualisiert. Was ist die wirksamste langfristige Lösung, um eine Wiederholung zu verhindern?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten zu den Schichten eines typischen SaaS-Data-Stacks, wie in der Lektion beschrieben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten dazu, warum es wichtiger ist, „jede Nahtstelle“ eines Data-Stacks zu prüfen, als nur das finale Dashboard zu kontrollieren.

Wählen Sie alle richtigen Antworten aus.

Die wiederkehrende Audit-Checkliste aufbauen

Ein Audit ist keine einmalige Aufräumaktion, es ist eine Taktung. Eine praktikable Quartals-Checkliste:

Event Stream

  • Tracking Plan mit den Live-Events im Warehouse abgleichen.
  • Bestätigen, dass Benachrichtigungen über Schemaänderungen tatsächlich bei Analytics ankommen und nicht nur in Engineering-Slack-Channels.

Ingestion

  • Orphan Rate für die Top 5 geschäftskritischen Events berechnen.
  • Volumentrend der Dead Letter Queue prüfen.

Warehouse

  • Uniqueness-/Not-Null-Tests auf den Primary Keys der Kern-Fact-Tables (Subscriptions, Invoices, Usage) laufen lassen.
  • Stichprobenartig Zeilenzahl-Trends auf unerklärte Ausschläge prüfen.

BI Layer

  • Dashboard-Ownership auditieren: Jedes Dashboard braucht einen benannten Owner oder wird archiviert.
  • Die 10 wichtigsten Management-Dashboards gegen Source-of-Truth-SQL-Queries verifizieren.
  • Bestätigen, dass Metrikdefinitionen an einer zentralen Stelle liegen und nicht über Tools hinweg dupliziert sind.

Governance

  • Dokumentieren, wer Schemata ändern darf, wer neue Events freigibt, wer über Breaking Changes informiert wird.

Das deckt sich weitgehend mit dem, was der Bereich Data Observability die „fünf Säulen“ nennt (Freshness, Distribution, Volume, Schema, Lineage), ein von Monte Carlo bekannt gemachtes Framework, auf das heute branchenweit Bezug genommen wird; siehe diesen gut zugänglichen Überblick von dbt Labs zu Data Testing.

🎬 [VIDEO: "Data Observability Explained" - youtube.com/@MonteCarloData - eine kompakte Tour durch das Framework aus Freshness, Volume, Schema, Distribution und Lineage, angewandt auf reale Pipelines]

Key Takeaways

  • Schema Drift, Orphaned Events und Stale Dashboards sind die drei häufigsten Vertrauenskiller in SaaS-Data-Stacks; jeder gehört zu einer anderen Schicht (Event Stream, Ingestion, BI).
  • Die Orphan Rate ist eine quantifizierbare, nachverfolgbare Kennzahl: Berechnen Sie sie als (Events gesamt − joinbare Events) / Events gesamt und setzen Sie eine Alert-Schwelle (üblich sind 2 bis 5 %, höher für explorative Events, niedriger für abrechnungskritische).
  • Jedes Dashboard braucht einen Owner und ein Datum der letzten Verifizierung; Dashboards ohne Owner sind die Standardquelle für veraltete, widersprüchliche Kennzahlen.
  • Tests gehören nach vorne in die Kette, nicht nur ins BI: Uniqueness- und Not-Null-Tests im Transformation Layer (per dbt oder Äquivalent) fangen Duplikation ab, bevor sie in einem Board-Deck landet.
  • Audits sind eine Taktung, keine Aufräumaktion: Bauen Sie eine Quartals-Checkliste für Event Stream, Ingestion, Warehouse, BI und Governance und weisen Sie jeder Schicht eine explizite Verantwortlichkeit zu.

Zurück

SaaS-Analytics benchmarken: was gut aussieht