+150 XP

Die SaaS-Datenlandschaft kartieren: Quellen, Systeme und Owner

# Die SaaS-Datenlandschaft kartieren: Quellen, Systeme und Owner

Ein einzelner Free-Trial-Signup bei einem mittelgroßen SaaS-Unternehmen kann in weniger als zehn Sekunden Schreibvorgänge in sechs verschiedenen Systemen auslösen: ein Product-Analytics-Event, ein CRM-Lead-Datensatz, eine Billing-Account-Hülle, ein Marketing-Attributions-Touch, ein Flag zur Ticket-Berechtigung im Support und ein Sync-Job ins Data Warehouse. Keines dieser Systeme ist sich einig, wie der Kunde heißen soll. Das ist die SaaS-Datenlandschaft, und sie zu kartieren ist die erste Aufgabe für jeden, der in diesem Sektor Analytics, Finance oder Ops macht.

Warum Source Mapping wichtig ist, bevor Sie ein Dashboard anfassen

Die meisten SaaS-„Datenprobleme“ sind keine Analytics-Probleme. Es sind Ownership-Probleme. Eine Churn-Zahl sieht nicht deshalb falsch aus, weil das SQL schlecht ist, sondern weil Billing „Kunde“ als aktives Abonnement definiert, während Product darunter einen eingeloggten Workspace versteht.

Eine Source Map ist ein einfaches Artefakt: für jeden Datensatz, wer ihn besitzt, wo er liegt, wofür er genutzt wird und was ihn kaputt macht. Bevor Sie Metriken bauen, bauen Sie diese Map. Sie verhindert den mit Abstand häufigsten Fehlermodus in SaaS-Analytics: zwei Teams präsentieren im gleichen Board-Meeting unterschiedliche Zahlen für „dieselbe“ Metrik.

Die fünf zentralen Datenquellen in SaaS

1. Product Telemetry (Nutzungsdaten)

Das sind Daten auf Event-Ebene: Logins, Klicks, Feature Adoption, API-Calls, Session-Länge. Erfasst über Instrumentierungs-Tools wie Amplitude, Mixpanel oder Segment (eine Customer Data Platform, CDP, die Events an mehrere Ziele weiterleitet).

  • Owner: in der Regel Product oder Data Engineering.
  • Typische Bruchstelle: Instrumentation Drift. Ein Entwickler benennt ein Event um („signup_complete“ wird zu „user_created“) und drei Monate Trendlinien brechen still und leise weg. Es wird kein Fehler geworfen, die Daten bedeuten einfach klammheimlich etwas anderes.
  • Granularität: meist Event-Ebene, mit Zeitstempel, an eine User-ID oder Account-ID gebunden.

2. Billing- und Subscription-Daten

Liegen in Systemen wie Stripe, Chargebee oder Zuora. Das ist das System of Record für MRR (monthly recurring revenue), Plan-Tier, Seat-Anzahl, Rabatte und Zahlungsstatus.

  • Owner: Finance, manchmal RevOps.
  • Typische Bruchstelle: nicht übereinstimmende Kundenidentität zwischen Billing und CRM (ein Unternehmen wurde in Salesforce umbenannt, in Stripe aber nicht) sowie manuelle Rabatte, die nicht in die Reporting-Systeme zurückfließen.
  • Granularität: Account-/Subscription-Ebene, üblicherweise monatlich oder Event-getrieben (Upgrade, Downgrade, Kündigung).

3. CRM-Daten (Customer Relationship Management)

Salesforce- oder HubSpot-Datensätze: Leads, Opportunities, Deal-Stages, Vertragskonditionen, Verlängerungstermine. Das ist die Sales-Sicht auf den Kunden.

  • Owner: Sales Ops / RevOps.
  • Typische Bruchstelle: veraltete oder manuell eingetragene Felder. Ein Rep vergisst, die Deal-Stage zu aktualisieren; Forecasts auf CRM-Basis werden unzuverlässig. Außerdem doppelte Account-Datensätze, wenn mehrere Reps separate Einträge für dasselbe Unternehmen anlegen.

4. Support- und Success-Daten

Tickets aus Zendesk, Intercom oder Gainsight, NPS-Umfragen (Net Promoter Score), Health Scores. Das erfasst Kundenstimmung und Friktion.

  • Owner: Customer Success / Support.
  • Typische Bruchstelle: Health Scores auf Basis veralteter Usage-Snapshots, oder Ticketvolumen wird mit Unzufriedenheit verwechselt (ein Power User eröffnet viele Tickets, weil er das Produkt intensiv nutzt, nicht weil er unzufrieden ist).

5. Marketing- und Acquisition-Daten

Ad-Plattformen (Google Ads, LinkedIn), Web-Analytics (GA4) und Attributions-Tools. Erfasst die Inputs für CAC (customer acquisition cost): Spend, Channel, Kampagne, Conversion.

  • Owner: Marketing / Growth.
  • Typische Bruchstelle: Uneinigkeit über Attributionsmodelle (Last-Touch vs. Multi-Touch) und Cookie-/Consent-Einschränkungen durch GDPR (General Data Protection Regulation, das EU-Datenschutzrecht) oder CCPA (California Consumer Privacy Act), die den trackbaren Traffic schrumpfen lassen, besonders in Europa nach 2018 und zunehmend in den USA seit 2020.

Die Source Map bauen: ein praktisches Template

Eine brauchbare Source Map hat fünf Spalten. Hier ein komprimiertes Beispiel:

| Datensatz | System | Owner | Granularität | Häufiger Fehler |

|---|---|---|---|---|

| Product Events | Amplitude/Segment | Product Eng | Event-Ebene | Umbenannte/nicht getrackte Events |

| Subscriptions | Stripe/Chargebee | Finance | Account-Ebene | ID-Mismatch mit CRM |

| Deals/Accounts | Salesforce | RevOps | Account-Ebene | Manuelle Eingabe, Duplikate |

| Tickets/Health | Zendesk/Gainsight | CS | Ticket-Ebene | Veraltete Scores, vermischte Sentiment-Signale |

| Kampagnen/Spend | GA4/Ad-Plattformen | Marketing | Session/Kampagne | Konflikt der Attributionsmodelle, Consent-Lücken |

Die entscheidende Spalte, die die meisten Teams auslassen, ist „Häufiger Fehler“. Erst wenn Sie den Fehlermodus im Vorfeld benennen, können Sie ein Monitoring dafür bauen, statt ihn im Board Review zu entdecken.

Das Problem der Identity Resolution

Der Grund, warum diese fünf Systeme nicht von sich aus übereinstimmen: jedes nutzt einen anderen Key.

  • Product Telemetry keyt auf eine Device- oder User-ID.
  • Billing keyt auf eine Account-/Subscription-ID.
  • CRM keyt auf einen Company-/Contact-Datensatz.

Das zusammenzuführen heißt Identity Resolution und läuft meist über eine Customer-ID-Mapping-Tabelle, die im Data Warehouse gepflegt wird (Snowflake, BigQuery, Databricks sind 2026 die gängigen Plattformen).

Eine vereinfachte Mapping-Query sieht so aus:

sql
-- Vereinfachte Identity Resolution: Product Usage mit Billing-Account joinen
SELECT
    p.user_id,
    p.account_id AS product_account_id,
    b.subscription_id,
    b.crm_account_id,
    c.salesforce_account_name
FROM product_events p
LEFT JOIN billing_accounts b
    ON p.account_id = b.external_account_id
LEFT JOIN crm_accounts c
    ON b.crm_account_id = c.account_id
WHERE p.event_date >= CURRENT_DATE - INTERVAL '30 days';

Wenn product_account_id und crm_account_id nicht zuverlässig 1:1 zusammenpassen, ist jede nutzungsbasierte Churn- oder Expansion-Metrik weiter unten fragwürdig. Dieser Join, der still scheitert, ist eine der häufigsten Grundursachen für „die Dashboard-Zahlen passen nicht zusammen“-Vorfälle in SaaS-Unternehmen.

Als tiefergehende technische Referenz für diese Art von Pipeline-Disziplin ist das dbt Labs Glossar eine solide, kostenlose Einführung in die Analytics-Engineering-Konzepte, auf die in diesem Modul durchgehend Bezug genommen wird.

Wissenscheck

1. Eine Churn-Metrik sieht beim Billing-Team anders aus als beim Product-Team. Was ist laut Lektion die wahrscheinlichste Grundursache?

2. Warum sollte ein Team eine Source Map bauen, bevor es Metriken oder Dashboards baut?

3. Ein Entwickler benennt das Event „signup_complete“ im Product-Analytics-Tool in „user_created“ um, und es wird kein Fehler geworfen. Was zeigt dieses Szenario?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Antworten zu einer „Source Map“, wie sie in der Lektion beschrieben wird.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Antworten zu Product Telemetry (Nutzungsdaten) in SaaS-Unternehmen.

Wählen Sie alle richtigen Antworten aus.

Wer besitzt was: ein Governance-Realitätscheck

Ownership-Streitigkeiten sind bei SaaS-Daten die Regel, nicht die Ausnahme. Einige Muster, die man kennen sollte:

  • Product-Led-Growth-Unternehmen (PLG) (Motion à la Notion, Figma) haben tendenziell Product als Eigentümer der maßgeblichsten Kundendefinition, weil Nutzung das Geschäft treibt. Billing sitzt oft weiter unten und ist dünner.
  • Sales-Led Enterprise SaaS (klassische Salesforce-Motion) hat tendenziell das CRM als „Source of Truth“ für Account-Identität, während Product Telemetry als ergänzend behandelt wird.
  • Data-Governance-Councils, ab einer bestimmten Größe üblich (Series C+ oder börsennotierte Unternehmen), formalisieren das, indem sie pro Domäne einen Data Steward benennen: eine namentlich benannte Person, die für Definitionen verantwortlich ist, nicht nur für Data-Quality-Tooling.

Governance-Frameworks, die man beim Namen kennen sollte: DAMA-DMBOK (Data Management Body of Knowledge) ist das Standard-Referenzframework für Rollen und Verantwortlichkeiten in der Data Governance, nützlich, wenn Sie ein formales Vokabular für diese Ownership-Gespräche brauchen.

🎬 [VIDEO: "Data Governance Explained" - youtube.com - suchen Sie nach aktuellen DAMA- oder Data-Council-Talks, die Stewardship- und Ownership-Modelle in modernen SaaS-Datenstacks erklären]

Wo das in der Praxis bricht: drei reale Muster

1. Das umbenannte Event. Engineering liefert ein Refactoring aus und benennt trial_started in trial_activated um. Das Activation-Dashboard von Growth läuft flach. Zwei Wochen lang merkt es niemand, weil kein Alert an das Volumen dieses Events gehängt war.

2. Der Identity Drift zwischen Billing und CRM. Ein Kunde wird von einem anderen Unternehmen übernommen, in Salesforce umbenannt, aber der Stripe-Account zeigt weiter den alten Firmennamen. Das Revenue-Reporting „pro Kunde“ zählt die tatsächliche Logo-Zahl zu niedrig.

3. Der Attributionskrieg. Marketing berichtet CAC über Last-Touch-Attribution; Finance berichtet CAC als fully-loaded Spend geteilt durch neue Logos. Beide sind nach ihrer eigenen Definition „korrekt“. Ohne dokumentierte Source Map wird daraus eine wiederkehrende, unproduktive Diskussion statt einer fünfminütigen Abstimmung.

Key Takeaways

  • SaaS-Daten kommen aus fünf zentralen Systemen: Product Telemetry, Billing, CRM, Support/Success und Marketing. Jedes hat einen eigenen Owner, eine eigene Granularität und einen typischen Fehlermodus.
  • Bauen Sie eine Source Map (Datensatz, System, Owner, Granularität, häufiger Fehler), bevor Sie Metriken bauen. Das ist der schnellste Weg, widersprüchliche Zahlen in Leadership-Meetings zu vermeiden.
  • Identity Resolution, also das Zusammenführen unterschiedlicher ID-Schemata über Systeme hinweg, ist die häufigste Grundursache für „die Zahlen passen nicht“-Vorfälle.
  • Ownership folgt dem Geschäftsmodell: PLG-Unternehmen verankern sich in Produktdaten, Sales-Led-Unternehmen in CRM-Daten. Wissen Sie, in welchem Modell Sie stecken, bevor Sie entscheiden, wessen Zahl maßgeblich ist.
  • Governance-Frameworks wie DAMA-DMBOK liefern ein formales Vokabular (Data Steward, System of Record), um Ownership-Streitigkeiten zu klären, statt sie jedes Quartal neu auszufechten.