Star Schema für Marketingdaten: Der praxisnahe Leitfaden

Lesezeit: 5 Minuten

Ein Star Schema für Marketingdaten ist ein dimensionales Konsummodell, das Transaktionsmetriken zentral in einer Faktentabelle hält und den Marketingkontext, also Kampagne, Kanal, Zeit und Zielgruppe, in flachen, denormalisierten Dimensionstabellen bereitstellt. Das Ergebnis: schnellere Abfragen, einfachere DAX-Ausdrücke in Power BI und ein Modell, das Marketing-Analysten ohne SQL-Kenntnisse selbst bedienen können.

Für den Einstieg empfiehlt sich eine transaktionale Kampagnen-Faktentabelle auf Event-Ebene (ein Datensatz pro Klick, Impression oder Conversion), ergänzt durch tägliche Snapshot-Fakten für aggregierte KPI-Berichte. Drei Entscheidungen müssen Sie dabei zuerst treffen:

Granularität festlegen: Event-Level für Attribution und Modellierung, täglicher Snapshot für Dashboard-Performance.
IDs vereinheitlichen: CRM-IDs, Tracking-IDs und Werbenetzwerk-IDs auf einen gemeinsamen Schlüssel mappen, bevor das Modell steht.
SCD-Strategie definieren: SCD Typ 2 für Kampagnen, Ad-Sets und Produkte, die sich attributionsrelevant ändern; SCD Typ 1 für kosmetische Korrekturen wie Tippfehler in Kampagnennamen.

Wichtige Erkenntnisse

Ein Star Schema für Marketingdaten liefert dann zuverlässige Ergebnisse, wenn Granularität, SCD-Policy und ID-Harmonisierung vor dem ersten Datensatz festgelegt sind.

Thema	Details
Granularität zuerst	Event-Level für Attribution, täglicher Snapshot für Dashboard-Performance. Beide Schichten von Anfang an einplanen.
SCD-Strategie	SCD Typ 2 für attributionsrelevante Änderungen an Kampagnen und Ad-Sets; SCD Typ 1 für kosmetische Korrekturen.
Star vs. Snowflake	Star Schema für interaktive BI-Abfragen bevorzugen; Snowflake nur bei tiefen Hierarchien oder häufigen Attribut-Updates.
Power BI Best Practice	Beziehungen immer 1:n von Dimension zu Fakten; Measures in Faktentabelle; Incremental Refresh für große Faktentabellen aktivieren.
IT-WINGS	IT-WINGS bietet Architektur-Audits, Implementierungsprojekte und Power BI-Seminare für den Aufbau von Marketingdaten-Modellen.

Inhaltsverzeichnis

Was ist ein Star Schema für Marketingdaten, und warum ist es die richtige Wahl?
Drei konkrete Schema-Patterns für Marketingdaten
Faktentabellen: Granularität und Faktentypen richtig wählen
Dimensionen gestalten: SCD-Strategien, Rollenspiel- und Junk-Dimensionen
Star Schema vs. Snowflake: Wann lohnt sich die Normalisierung?
Wie Sie Star Schemas in Power BI und modernen Datenplattformen umsetzen
Performance im Produktionsbetrieb: Partitionierung, Incremental Loads und Monitoring
Datenqualität und Datenschutz: Was Modellierer in Deutschland beachten müssen
Schrittweiser Aufbau eines Star Schemas für Marketingdaten: Checkliste und Feldlisten
IT-WINGS begleitet Sie beim Aufbau Ihres Marketingdaten-Modells
Quellen

Was ist ein Star Schema für Marketingdaten, und warum ist es die richtige Wahl?

Das Sternschema ist ein dimensionales Datenbankmodell mit einer zentralen Faktentabelle, die über Fremdschlüssel mit mehreren Dimensionstabellen verbunden ist. Die Faktentabelle enthält messbare Ereignisse oder Transaktionen, zum Beispiel Impressionen, Klicks, Kosten und Conversions. Die Dimensionstabellen liefern den beschreibenden Kontext: Kampagnenname, Kanal, Gerät, Zielgruppe, Datum, Geografie.

Der entscheidende Unterschied zur normalisierten Datenbankstruktur liegt in der Denormalisierung der Dimensionstabellen. Statt einer Produkthierarchie über drei Tabellen (Produkt → Kategorie → Warengruppe) stehen alle Attribute in einer einzigen, breiten Dimensionstabelle. Das erzeugt zwar Redundanz, aber genau diese Redundanz macht Abfragen schneller und DAX-Berechnungen in Power BI einfacher.

Databricks beschreibt das Star Schema als dimensionales Modell, das für Data-Warehousing und BI-Workloads konzipiert ist: wenige Joins, klare Kardinalitäten, direkte Filterbarkeit. Für Marketingdaten ist das besonders wertvoll, weil Analysten täglich mit wechselnden Filterkombinationen arbeiten, etwa nach Kanal, Kampagne und Zeitraum gleichzeitig.

Ralph Kimball hat das Konzept des dimensionalen Modellierens in den 1990er-Jahren systematisiert und damit die Grundlage für moderne BI-Architekturen gelegt. Sein Prinzip: Fakten messen, Dimensionen beschreiben. Wer Marketingdaten modelliert, folgt noch heute dieser Logik.

Warum Denormalisierung für BI sinnvoll ist: Power BI und Tableau sind nativ auf flache, star-ähnliche Modelle ausgelegt. Weniger Joins bedeuten schnelleres Rendering und einfachere Measures. Microsoft empfiehlt das Star Schema explizit als Best Practice für Power BI-Semantikmodelle, weil es Abfragen und DAX-Berechnungen vereinfacht und die Performance verbessert. Der Trade-off: höherer Speicherbedarf und mehr Pflegeaufwand bei Attributänderungen. In modernen Cloud-Umgebungen ist Speicher günstig; die hauptsächlichen Kosten entstehen durch Compute.

Drei konkrete Schema-Patterns für Marketingdaten

Nicht jedes Marketingprojekt braucht dasselbe Modell. Drei Patterns decken die häufigsten Anforderungen ab.

Pattern A: Event-Faktentabelle (Ereignisebene)

Jede Zeile repräsentiert ein einzelnes Ereignis: einen Klick, eine Impression, eine Conversion. Typische Spalten:

event_id, event_timestamp, user_id, session_id
campaign_id, channel_id, ad_id, creative_id
cost, revenue, conversion_flag, attribution_model
device_id, geo_id, date_id

Dieses Pattern eignet sich für Attribution, Pfadanalyse und maschinelles Lernen. Das Datenvolumen ist hoch, die Abfrageperformance bei ungefilterten Scans entsprechend niedrig. Partitionierung nach event_timestamp ist Pflicht.

Pattern B: Session- und Visit-Fakten (Sitzungsebene)

Hier aggregiert jede Zeile alle Ereignisse einer Sitzung: Seitenaufrufe, Klicks, Verweildauer, Conversion-Status. Sinnvoll, wenn Session-Metriken wie Absprungrate oder durchschnittliche Sitzungsdauer im Vordergrund stehen und keine ereignisgenaue Attribution benötigt wird. Das Volumen ist deutlich geringer als bei Pattern A.

Pattern C: Aggregated Snapshot (täglich oder monatlich)

Tägliche oder monatliche Vorkalkulationen pro Kampagne und Kanal: Impressionen, Klicks, Kosten, Conversions, Cost-per-Click, Return on Ad Spend. Ideal für Executive-Dashboards und historische KPI-Schnellsichten. Abfragen sind extrem schnell, weil das Volumen minimal ist.

Merkmal	Event-Fakten	Session-Fakten	Aggregated Snapshot
Granularität	Ein Datensatz pro Ereignis	Ein Datensatz pro Sitzung	Ein Datensatz pro Tag/Kanal
Datenvolumen	Sehr hoch	Mittel	Gering
Abfrageperformance	Niedrig (ohne Partitionierung)	Mittel	Sehr hoch
Typische Metriken	Klicks, Impressionen, Attributions-Score	Sitzungsdauer, Absprungrate, Conversions	CPC, ROAS, CTR, Gesamtkosten

Profi-Tipp: Der Hybrid aus Event-Fakten und täglichem Snapshot ist in der Praxis die stärkste Kombination. Event-Level-Daten bleiben für Attribution und Modellierung erhalten; der Snapshot beschleunigt alle Dashboard-Abfragen um ein Vielfaches. Bauen Sie beide Schichten von Anfang an ein, statt den Snapshot nachträglich hinzuzufügen.

Für die Datenintegration aus verschiedenen Quellen in ein einheitliches Schema empfiehlt sich ein klares ID-Mapping bereits im Staging-Layer.

Faktentabellen: Granularität und Faktentypen richtig wählen

Die Wahl der Granularität ist die wichtigste Entscheidung beim Aufbau einer Faktentabelle. Sie legt fest, was genau eine Zeile repräsentiert, und bestimmt damit alle nachgelagerten Abfragemöglichkeiten.

Vier Entscheidungsparameter helfen bei der Wahl:

Reporting-Latenz: Brauchen Sie Echtzeit-Daten oder reichen tägliche Aktualisierungen?
Abfragemuster: Werden hauptsächlich Aggregate abgefragt oder einzelne Ereignisse?
Datenvolumen: Wie viele Ereignisse entstehen täglich?
Attributionserfordernisse: Ist Multi-Touch-Attribution geplant? Dann ist Event-Level Pflicht.

Die vier Faktentypen im Überblick:

Transaktionale Faktentabelle: Ein Datensatz pro Ereignis. Für Marketingdaten: jeder Klick, jede Impression, jede Conversion. Maximale Flexibilität, höchstes Volumen.

Periodischer Snapshot: Zustand zu einem festen Zeitpunkt, täglich oder monatlich. Für Marketingdaten: tägliche Kampagnenleistung pro Kanal. Gut für Trendanalysen.

Akkumulierender Snapshot: Ein Datensatz pro Prozessinstanz, der sich über Zeit aktualisiert. Für Marketingdaten: der Lebenszyklus eines Leads vom ersten Kontakt bis zur Conversion, mit Zeitstempeln für jeden Meilenstein.

Faktenlose Faktentabelle: Erfasst Ereignisse ohne Metriken. Für Marketingdaten: Kampagnen-Exposures, bei denen nur das Auftreten eines Ereignisses relevant ist, nicht ein Messwert.

Typische Metriken in einer Marketing-Faktentabelle: Impressionen, Klicks, Kosten, Umsatz, Conversions, View-Throughs, Assisted Conversions und Attributions-Scores. Für Event-Tracking auf Website-Ebene kommen Seitenaufrufe, Scroll-Tiefe und Formular-Abschlüsse hinzu.

Die Faustregel: Starten Sie mit Event-Level für Attribution und Modellierung, und bauen Sie Snapshot-Fakten als Performance-Schicht für Dashboards darüber.

Dimensionen gestalten: SCD-Strategien, Rollenspiel- und Junk-Dimensionen

Dimensionstabellen sind mehr als Lookup-Tabellen. Wie Sie sie historisieren und strukturieren, entscheidet darüber, ob Ihr Modell auch in zwölf Monaten noch korrekte Antworten liefert.

Zeitdimension

Eine kanonische Datumstabelle ist das Fundament jedes Star Schemas. Sie enthält alle granularen Attribute: Datum, Wochentag, Kalenderwoche, Monat, Quartal, Jahr, Feiertags-Flag, Geschäftsjahr-Flag. Einmal aufgebaut, ändert sie sich nie. Verknüpfen Sie alle Faktentabellen über einen date_id-Schlüssel damit.

Kampagnen- und Kanal-Dimension mit SCD

Kampagnen ändern sich: Budget wird angepasst, Targeting verändert, Kampagnenname korrigiert. Hier greifen die Strategien für langsam veränderliche Dimensionen (Slowly Changing Dimensions):

SCD Typ 1: Überschreiben. Kein Verlauf. Geeignet für kosmetische Korrekturen wie Tippfehler im Kampagnennamen.
SCD Typ 2: Neue Zeile mit Gültigkeitszeitraum (valid_from, valid_to, is_current). Pflicht für attributionsrelevante Änderungen: Budgetanpassungen, Targeting-Wechsel, Kanalzuordnung. So bleibt die historische Performance korrekt zugeordnet.
SCD Typ 3: Zusätzliche Spalte für den vorherigen Wert. Selten sinnvoll; nur wenn genau ein Vorgängerwert relevant ist.

Ein konkretes Beispiel aus der Praxis: Eine Google-Ads-Kampagne wechselt ihr Zielgruppen-Targeting. Mit SCD Typ 2 bleibt die Performance vor dem Wechsel der alten Zielgruppe zugeordnet; die neue Zeile trägt das neue Targeting. Ohne SCD Typ 2 würden historische Conversions falsch attribuiert.

Rollenspiel-Dimensionen

Wenn dieselbe Dimensionstabelle mehrfach in einer Faktentabelle vorkommt, spricht man von Rollenspiel-Dimensionen. Beispiel: Eine Kundentabelle tritt als Käufer und als Empfänger auf. Lösung: Erstellen Sie benannte Views oder Aliase der Dimensionstabelle (dim_customer_buyer, dim_customer_recipient), die auf dieselbe physische Tabelle zeigen. So vermeiden Sie Redundanz und behalten klare Semantik.

Junk-Dimensionen und degenerierte Dimensionen

Junk-Dimensionen bündeln niedrigkardinalige Flags und Indikatoren, die keine eigene Dimension rechtfertigen: is_retargeting, is_brand_keyword, device_type, match_type. Statt vier separate Dimensionstabellen mit je zwei Werten zu bauen, fasst eine Junk-Dimension alle Kombinationen zusammen.

Eine degenerierte Dimension ist ein Schlüssel in der Faktentabelle ohne eigene Dimensionstabelle, zum Beispiel die order_number oder session_id. Sie dient als Drill-through-Schlüssel, braucht aber keine eigene Tabelle.

Profi-Tipp: Wenden Sie SCD Typ 2 konsequent für alle Attribute an, die Einfluss auf Attribution oder Budgetzuordnung haben. Für alles andere reicht Typ 1. Ein Hybrid aus beiden spart Speicher und hält die Modellkomplexität niedrig.

Star Schema vs. Snowflake: Wann lohnt sich die Normalisierung?

Der Kernunterschied ist schnell erklärt: Ein Star Schema denormalisiert Dimensionen für maximale Abfrageperformance. Ein Snowflake-Schema normalisiert sie weiter, zum Beispiel eine separate Tabelle für Kampagnenkategorien, die mit der Kampagnentabelle verknüpft ist. Das spart Speicher und erhöht die Konsistenz, erzeugt aber mehr Joins.

Laut Coursera liegt der Trade-off zwischen Performance (Star) und Storage-Effizienz sowie Konsistenz (Snowflake). In modernen Cloud-Architekturen ist Speicher günstig; Compute ist der eigentliche Kostentreiber. Das verschiebt die Entscheidung klar zugunsten des Star Schemas für BI-Workloads.

DataCamp empfiehlt das Star Schema für schnelle BI-Abfragen und interaktive Dashboards, das Snowflake-Schema dagegen für hierarchische Daten mit häufigen Attribut-Updates und hoher Kardinalität.

Praktische Heuristiken für Marketingdaten:

Star wählen, wenn interaktive Dashboards, Ad-hoc-Abfragen und schnelle Filter im Vordergrund stehen.
Snowflake erwägen, wenn Dimensionen sehr tiefe Hierarchien haben (z. B. Geo: Land → Bundesland → Stadt → PLZ) oder Attribute sich häufig ändern und Konsistenz wichtiger ist als Abfragegeschwindigkeit.
Hybridansatz empfohlen: Normalisierter Staging- und Core-Layer für Governance, denormalisierter Consumption-Mart für BI. ThoughtSpot und andere BI-Anbieter bestätigen, dass dieser Schichtenansatz Balance zwischen Governance und Performance liefert.

Für Marketingdaten in Deutschland gilt: Die meisten Reporting-Anforderungen, von Google-Ads-Performance bis Social-Media-KPIs, profitieren vom Star Schema. Snowflake-Elemente sind allenfalls im Geo-Bereich oder bei sehr komplexen Produkthierarchien sinnvoll.

Wie Sie Star Schemas in Power BI und modernen Datenplattformen umsetzen

Power BI: Semantikmodell-Best-Practices

Microsoft empfiehlt für Power BI-Semantikmodelle explizit das Star Schema. Konkrete Umsetzungsregeln:

Beziehungen: Immer 1:n von Dimension zu Faktentabelle, nie bidirektionale Kreuzfilter ohne konkreten Grund. Bidirektionale Filter verlangsamen das Modell und erzeugen schwer nachvollziehbare Filterflüsse.
Measures: Alle berechneten Kennzahlen gehören in die Faktentabelle oder in eine dedizierte Measure-Tabelle, nie in Dimensionstabellen.
Incremental Refresh: Für große Faktentabellen mit täglichen Ereignissen ist Incremental Refresh in Power BI Pflicht. Definieren Sie RangeStart und RangeEnd als Parameter und konfigurieren Sie die Aktualisierungsrichtlinie im Power BI Service.
Aggregationstabellen: Power BI unterstützt automatische Aggregationen. Legen Sie eine vorberechnete Aggregationstabelle an und verknüpfen Sie sie mit der Detailtabelle. Power BI wählt automatisch die richtige Ebene.

ELT/ETL-Schichtenmodell

Das bewährte Muster für Marketingdaten: Staging → Canonical Core → Consumption Star Marts. Im Staging landen Rohdaten aus Google Ads, Meta, CRM und Web-Analytics unverändert. Der Canonical Core normalisiert und vereinheitlicht IDs. Der Consumption-Mart denormalisiert für BI.

CI/CD für Datenmodelle: Nutzen Sie dbt (Data Build Tool) für versionierte, testbare Transformationen. Jede Modelländerung durchläuft automatische Tests auf referenzielle Integrität und Zeilenzahlen, bevor sie in Produktion geht.

Plattformspezifika

Databricks eignet sich für orchestrierte Transformations-Pipelines mit Apache Spark, besonders wenn Rohdaten aus vielen heterogenen Quellen kommen und komplexe Transformationslogik benötigen.
BigQuery ist stark bei serverlosem Scan-Workloads mit sporadischen, hohen Lastspitzen. Die spaltenorientierte Speicherung macht es ideal für Faktentabellen mit vielen Spalten und selektiven Abfragen.
Snowflake bietet kontrollierte Compute-Isolation über separate Warehouses, was bei parallelen Teams mit unterschiedlichen Workloads die Kosten planbar hält. Laut einem Plattformvergleich unterscheiden sich BigQuery und Snowflake vor allem im Kostenmodell: BigQuery rechnet nach gescannten Bytes, Snowflake nach genutzten Compute-Sekunden.

Profi-Tipp: Denken Sie das Modell in Schichten und setzen Sie Materialized Views oder Aggregationstabellen genau dort ein, wo BI-Performance kritisch ist. Nicht jede Schicht braucht Materialisierung; der Consumption-Mart für Dashboards fast immer.

Performance im Produktionsbetrieb: Partitionierung, Incremental Loads und Monitoring

Ein Star Schema, das in der Entwicklung schnell läuft, kann in Produktion mit wachsendem Datenvolumen zum Kostentreiber werden. Vier Hebel halten es skalierbar.

Partitionierung

Faktentabellen partitionieren Sie primär nach event_date oder event_timestamp. In BigQuery reduziert eine Datumspartition den gescannten Datenumfang drastisch, wenn Abfragen immer einen Zeitfilter enthalten. In Snowflake und Azure Synapse ergänzen Clustering-Keys auf häufig gefilterten Spalten wie campaign_id oder channel_id die Partitionierung.

Aggregationstabellen vs. On-the-fly-Aggregation

Vorkalkulierte Aggregationstabellen lohnen sich, wenn dieselben Aggregationen täglich von vielen Nutzern abgefragt werden. Tägliche Kampagnenleistung pro Kanal ist ein klassischer Kandidat. On-the-fly-Aggregation ist flexibler, aber teurer bei großen Faktentabellen.

Incremental Loads

Idempotente Ladevorgänge sind Pflicht: Jeder Load-Lauf muss dasselbe Ergebnis liefern, egal wie oft er ausgeführt wird. Nutzen Sie Watermarking (letzter verarbeiteter Zeitstempel) oder Change Data Capture (CDC) für Marketing-Events. Für tägliche Snapshots reicht ein MERGE-Statement, das vorhandene Zeilen aktualisiert und neue einfügt.

Watermarking: einfach, robust für append-only Quellen.
CDC: notwendig, wenn Quelldaten nachträglich korrigiert werden (z. B. Conversion-Korrekturen aus dem CRM).
Full-Refresh: nur für kleine Dimensionstabellen üblich.

Monitoring und Observability

Query-Logs auswerten: Welche Abfragen verbrauchen die meisten Slots oder Credits?
Kostenmonitoring: In BigQuery über den Billing-Export in ein separates Dataset; in Snowflake über QUERY_HISTORY.
Tracking-Lücken erkennen: Ein tägliches Error-Dashboard, das fehlende Datenlieferungen und unerwartete Zeilenzahlabweichungen meldet, verhindert stille Datenfehler.

Das erkennt Tracking-Ausfälle, bevor sie im nächsten Meeting auffallen.*

Datenqualität und Datenschutz: Was Modellierer in Deutschland beachten müssen

Marketingdaten enthalten personenbezogene Informationen: User-IDs, IP-Adressen, Gerätekennungen, Kaufhistorien. In Deutschland gelten die Anforderungen der DSGVO, und sie wirken sich direkt auf das Datenmodell aus.

PII-Handling im Modell

Erheben Sie nur den minimalen Satz personenbezogener Daten, der für den jeweiligen Zweck notwendig ist (Datensparsamkeit nach Art. 5 DSGVO).
Pseudonymisieren oder hashen Sie User-IDs bereits im Staging-Layer, bevor Daten in den Consumption-Mart fließen.
Speichern Sie Löschfristen als Metadaten im Modell und implementieren Sie automatische Löschroutinen für abgelaufene Datensätze.

Privacy-by-Design bei Attributionslogs

Attributionslogs auf Event-Level enthalten häufig Gerätekennungen und Session-IDs, die als pseudonyme Identifikatoren gelten. Trennen Sie Identitätsdaten (Klartexte, E-Mail-Adressen, Namen) in separate Tabellen mit strengeren Zugriffskontrollen. Der Consumption-Mart für Dashboards bleibt vollständig anonymisiert.

Recht auf Vergessenwerden

Implementieren Sie einen Löschmechanismus, der auf Anfrage alle Datensätze eines Nutzers über alle Faktentabellen und Dimensionen hinweg entfernt oder anonymisiert. Ein zentrales ID-Register, das alle Vorkommen einer User-ID dokumentiert, macht diesen Prozess handhabbar.

Datenqualität: Tracking-Health und ID-Mapping

Instrumentierungstests: Prüfen Sie täglich, ob alle erwarteten Event-Typen ankommen.
ID-Mapping-Automatisierung: CRM-IDs und Tracking-IDs müssen zuverlässig zusammengeführt werden. Fehlende Mappings erzeugen Attributionslücken.
Tracking-Health-Checks: Vergleichen Sie Rohdaten aus dem Tag-Management-System mit den verarbeiteten Daten im Warehouse.

Profi-Tipp: Trennen Sie Identitätsdaten konsequent in eigene, streng zugangskontrollierte Tabellen. Der Consumption-Layer für BI-Analysten enthält ausschließlich pseudonymisierte oder anonymisierte Schlüssel. Das vereinfacht DSGVO-Compliance und reduziert das Risiko versehentlicher Datenweitergabe.

Schrittweiser Aufbau eines Star Schemas für Marketingdaten: Checkliste und Feldlisten

Ein reproduzierbares Vorgehen verhindert, dass das Modell in der Mitte des Projekts neu gedacht werden muss.

Schrittfolge

Datenaufnahme: Quellen identifizieren (Google Ads, Meta Ads, CRM, Web-Analytics), Verbindungen herstellen, Rohdaten in Staging laden.
Kanonisierung: Datumsformate, Währungen und Kampagnennamen vereinheitlichen. Fehlende Werte dokumentieren.
Key-Mapping: CRM-IDs, Tracking-IDs und Werbenetzwerk-IDs auf einen gemeinsamen Schlüssel mappen. Mapping-Tabelle versionieren.
SCD-Policy festlegen: Für jede Dimension entscheiden: Typ 1 oder Typ 2. Dokumentieren.
Consumption-Mart erstellen: Faktentabelle und Dimensionen nach Star-Schema-Pattern aufbauen, denormalisiert für BI.
Validierung und Monitoring: Automatische Tests, Performance-Benchmarks, Dokumentation.

Beispiel-Feldlisten

Tabelle	Schlüsselspalten	Metriken / Attribute
`fact_marketing_events`	`event_id`, `date_id`, `campaign_id`, `channel_id`, `user_id`, `device_id`, `geo_id`	`cost`, `revenue`, `clicks`, `impressions`, `conversions`, `attribution_score`
`dim_campaign`	`campaign_id`, `valid_from`, `valid_to`, `is_current`	`campaign_name`, `campaign_type`, `budget`, `target_audience`, `channel`
`dim_date`	`date_id`	`date`, `week`, `month`, `quarter`, `year`, `is_holiday`, `fiscal_quarter`
`dim_channel`	`channel_id`	`channel_name`, `channel_type`, `platform`, `paid_flag`

Checkliste für die Auslieferung

Zeilenzahlen zwischen Quelldaten und Faktentabelle abgleichen.
Referenzielle Integrität prüfen: Fremdschlüssel in der Faktentabelle sollten in der zugehörigen Dimension vorhanden sein.
Measure-Reconciliation: KPIs im Dashboard gegen Quelldaten validieren.
Performance-Benchmark: Typische Dashboard-Abfragen unter fünf Sekunden.
Dokumentation: Datenwörterbuch, SCD-Policy, Löschfristen.

Für konkrete KPI-Dashboard-Implementierungen zeigt die IT-WINGS-Praxis, wie Validierungschecks in den Auslieferungsprozess integriert werden.

Profi-Tipp: *Lassen Sie vor dem Go-Live eine Reconciliation-Suite laufen, die alle Report-KPIs automatisch gegen die Quelldaten prüft. Abweichungen über einem definierten Schwellenwert blockieren den Release. Das verhindert, dass fehlerhafte Daten in Produktions-Dashboards landen.

Was wirklich zählt: Eine persönliche Einschätzung

Die meisten Probleme mit Marketingdaten-Modellen entstehen nicht beim Schema-Design, sondern davor: unklare Granularität, fehlende ID-Harmonisierung, keine SCD-Policy. Wer diese drei Entscheidungen zu Beginn trifft und dokumentiert, spart sich später Wochen an Korrekturen.

Was ich in der Praxis immer wieder sehe: Teams bauen zuerst Dashboards und modellieren das Datenschema nachträglich. Das führt zu Modellen, die zwar kurzfristig funktionieren, aber bei der nächsten Anforderung auseinanderfallen. Ein Star Schema, das von Anfang an auf Attribution, SCD und Privacy-by-Design ausgelegt ist, trägt deutlich länger.

Der Hybridansatz, also Event-Level-Fakten für Modellierung und tägliche Snapshots für Dashboards, ist kein Kompromiss, sondern die technisch sauberste Lösung. Er trennt Analysezwecke sauber und hält Compute-Kosten kontrollierbar.

Und noch etwas: Datenschutz ist kein nachgelagertes Compliance-Thema. Wer PII-Handling und Löschfristen ins Modell einbaut, bevor die ersten Daten fließen, hat später deutlich weniger Aufwand als jemand, der ein bestehendes Modell nachträglich DSGVO-konform machen muss.

IT-WINGS begleitet Sie beim Aufbau Ihres Marketingdaten-Modells

Als Digital Analytics Agentur verbindet IT-WINGS präzises Tracking, belastbare BI-Modelle und messbares Performance Marketing zu einem durchgängigen Ansatz. Für Teams, die ein Star Schema für Marketingdaten aufbauen oder ein bestehendes Modell prüfen wollen, bieten wir Architektur-Audits, Implementierungsprojekte und Power BI-Workshops an.

Unser Vorgehen folgt der Logik: erst sauber messen, dann verständlich sichtbar machen, dann gezielt handeln. Ob Sie ein Dashboarding-Projekt starten, ein Power BI-Seminar für Ihr Team buchen oder eine vollständige BI-Implementierung beauftragen wollen: Sprechen Sie uns an und erfahren Sie, wie wir Ihr Marketingdaten-Modell auf ein tragfähiges Fundament stellen.

Quellen

Empfehlung

Der IT-WINGS Blog -
Immer auf dem neusten Stand bleiben