31. Juli 2026
Braucht Marketing ein eigenes Data Warehouse? Meistens nicht — aber Zugang zum eigenen Wissen
Agenturen empfehlen derzeit auffällig oft ein «Marketing Data Warehouse». Was dabei entsteht, ist meistens ein weiteres Silo. Die Fragen, an denen Marketingteams wirklich scheitern, beantwortet es nicht.
In mehreren Gesprächen der letzten Monate lag dieselbe Empfehlung auf dem Tisch: Das Unternehmen brauche ein «Marketing Data Warehouse». Die Begründung klingt jedes Mal plausibel. Die Daten liegen verstreut in Google Ads, GA4, dem CRM, dem Newsletter-Tool, dem Shop. Niemand hat den Überblick. Also baut man eine zentrale Wahrheit, führt alles zusammen, und danach ist Ordnung. Die Diagnose stimmt. Die Therapie ist der Teil, über den zu wenig gesprochen wird.
Was tatsächlich gebaut wird
Ein Marketing Data Warehouse ist in der Praxis eine Kopie. Die Zahlen liegen weiterhin in Google Ads, GA4 und im CRM — und zusätzlich noch einmal in der neuen Datenbank. Damit sie dort aktuell bleiben, braucht es Pipelines, die regelmässig laufen, überwacht werden und bei jeder API-Änderung des Quellsystems nachgezogen werden müssen. Es braucht jemanden, der weiss, warum die Umsatzzahl im Warehouse und die im Shop um vier Prozent auseinanderliegen. Das Versprechen war das Ende der Silos. Das Ergebnis ist ein weiteres Silo, das nun mitgepflegt werden will — nur dass dieses Ihnen gehört und die Pflege in Ihrem Budget steht.
Das ist kein grundsätzlicher Einwand gegen Data Warehouses. Es ist ein Einwand gegen den Bau auf Vorrat. Ein Warehouse, das aus einer konkreten Frage entsteht, die anders nicht zu beantworten war, ist eine gute Investition. Ein Warehouse, das gebaut wird, weil «zentrale Datenhaltung» im Konzept gut aussieht, ist eine Wette darauf, dass die Fragen später schon kommen.
Die Branche selbst geht in die Gegenrichtung
Bemerkenswert ist, dass die Anbieter, die solche Systeme verkaufen, den Kopier-Ansatz gerade verlassen. Salesforce hat im April 2024 sein Zero Copy Partner Network gestartet — gemeinsam mit AWS, Databricks, Google Cloud und Snowflake — mit dem ausdrücklichen Ziel, Daten abzufragen und zu aktivieren, ohne sie zu duplizieren. Im Gartner Magic Quadrant für Customer Data Platforms 2026 ist mit Hightouch ein Anbieter als Leader gelistet, der als Reverse-ETL-Werkzeug begonnen hat, also mit genau der Gegenbewegung: Daten dort lassen, wo sie liegen, und sie von dort nutzbar machen. Wer Ihnen 2026 eine neue zentrale Kopie als Zukunftsarchitektur verkauft, verkauft Ihnen den Stand von vor einigen Jahren.
Die Frage, die ein Warehouse nie beantwortet
Der wichtigere Punkt ist ein anderer. Ein Data Warehouse enthält, was sich in Tabellen abbilden lässt: Klicks, Kosten, Konversionen, Zeitreihen. Damit beantwortet es Fragen der Form «wie viel» und «wann». Die Fragen aber, an denen Marketingteams im Alltag tatsächlich hängen bleiben, sehen anders aus. Warum haben wir diese Zielgruppe damals gewählt? Was war das Ergebnis der Kampagne im letzten Frühjahr, und was haben wir daraus gelernt? Welche Aussagen dürfen wir über dieses Produkt machen und welche nicht? Wie hat der Kunde auf den letzten Vorschlag reagiert? Was steht in unseren Markenrichtlinien zu genau diesem Fall?
Keine dieser Antworten steht in einer Tabelle. Sie stehen in Briefings, Protokollen, Post-Mortems, Richtlinien, Angeboten, E-Mail-Verläufen und Präsentationen. Dieses Material ist das eigentliche Firmenwissen — und es ist der Teil, den ein Data Warehouse konstruktionsbedingt nicht aufnimmt. Ein Unternehmen kann ein technisch einwandfreies Warehouse betreiben und trotzdem jedes Mal bei null anfangen, wenn eine neue Agentur, ein neuer Mitarbeiter oder ein KI-System fragt, warum die Dinge sind, wie sie sind.
Wofür RAG das passende Werkzeug ist
Genau für diese Datenklasse ist Retrieval-Augmented Generation gebaut. Ein Retrieval-Layer durchsucht Ihre Dokumente, findet die relevanten Passagen und übergibt sie einem Sprachmodell als Kontext. Damit wird Firmenwissen für KI-Systeme adressierbar: Ein Agent, der eine Kampagne vorbereitet, kann nachlesen, was beim letzten Mal nicht funktioniert hat. Ein Mitarbeiter bekommt die Passage aus der Richtlinie statt einer erfundenen Auskunft. Wann sich das rechnet und wann nicht, haben wir in RAG-System für Ihr KMU: Wann es sich lohnt — und wann nicht durchgerechnet; die dortigen fünf Fragen gelten unverändert.
Wo RAG das falsche Werkzeug ist — und das ist wichtig
Hier muss man ehrlich bleiben, auch wenn es die These schwächt: RAG ersetzt kein Data Warehouse. Für Aggregationen, exakte Summen, Zeitreihenvergleiche und alles, was gerechnet statt gelesen werden muss, ist semantische Suche das falsche Verfahren. Retrieval sucht nach inhaltlicher Ähnlichkeit, nicht nach Vollständigkeit — ein Vektorindex kann nicht garantieren, dass er alle relevanten Datensätze gefunden hat, und ohne diese Garantie ist jede Summe wertlos. Wer die Quartalszahl aus einem Vektorspeicher zieht, erhält eine plausible Zahl, keine richtige. Für strukturierte Daten ist der Weg über eine Abfrage gegen die Datenbank richtig, und die Fachliteratur zu diesem Thema ist sich in dem Punkt einig. Wer Ihnen RAG als Ersatz für Reporting verkauft, hat entweder das Verfahren nicht verstanden oder verkauft bewusst zu viel.
Die Reihenfolge, die wir empfehlen
Aus dieser Aufteilung folgt eine andere Reihenfolge als die übliche. Erstens: Zugang zu den Zahlen schaffen, die bereits existieren. Google Ads, GA4, das CRM und die meisten relevanten Systeme lassen sich über Schnittstellen abfragen; mit dem Model Context Protocol gibt es dafür inzwischen einen offenen Standard, über den KI-Systeme direkt auf solche Quellen zugreifen können, ohne dass die Daten vorher irgendwohin kopiert werden. Zweitens: das unstrukturierte Firmenwissen erschliessen — Briefings, Protokolle, Richtlinien, Auswertungen — dort liegt der Teil, der heute in keinem System steht. Drittens: die Kennzahlen definieren, bevor die Technik steht. Was genau heisst «Lead»? Der Streit über diese Definition ist der eigentliche Grund, warum Zahlen aus zwei Systemen nie übereinstimmen, und er löst sich nicht dadurch, dass man beide in eine dritte Datenbank kopiert. Viertens: ein Warehouse erst dann bauen, wenn eine konkrete Frage es erzwingt — typischerweise, wenn wirklich über Systemgrenzen hinweg gerechnet werden muss und die Abfrage gegen die Einzelquellen nicht mehr trägt. Dann ist es die richtige Entscheidung, und dann kennen Sie auch das Schema, das Sie brauchen.
Ein Test für das nächste Agenturgespräch
Wenn im Pitch die Zahl fällt, dass 85 Prozent aller Datenprojekte scheitern, fragen Sie nach der Quelle. Diese Zahl wandert seit Jahren durch Präsentationen und Fachartikel. Ihr Ursprung ist ein Tweet des damaligen Gartner-Analysten Nick Heudecker aus dem Jahr 2017, in dem er die frühere Schätzung von 60 Prozent als «zu konservativ» bezeichnete und die reale Quote auf «näher bei 85 Prozent» korrigierte. TechRepublic griff die Aussage im November 2017 auf; der Tweet selbst ist inzwischen gelöscht. Eine Gartner-Studie mit dieser Zahl gibt es nicht. Das ist kein Beleg dafür, dass Datenprojekte gut laufen — die Erfahrung spricht dagegen, und Gartner sagt in einer regulären Pressemitteilung vom Februar 2024 voraus, dass bis 2027 80 Prozent der Governance-Initiativen im Datenbereich scheitern werden. Aber wer eine Zahl aus einem gelöschten Tweet als Studienergebnis präsentiert, hat sie nicht geprüft. Und wer die Zahlen im Pitch nicht prüft, prüft sie in Ihrem Projekt auch nicht.
Wann ein Marketing Data Warehouse richtig ist
Damit das nicht als Pauschalablehnung stehen bleibt: Es gibt klare Fälle dafür. Wenn Sie über mehrere Quellsysteme hinweg rechnen müssen und die Abfragen gegen die Einzelsysteme das nicht mehr hergeben. Wenn Sie Historie brauchen, die Ihre Quellsysteme nicht aufbewahren — die meisten Werbeplattformen halten Rohdaten nur begrenzt vor, und was gelöscht ist, kommt nicht zurück. Wenn Sie Modelle rechnen, die auf konsistenten Zeitreihen beruhen; für Marketing-Mix-Modeling ist eine saubere strukturierte Datenbasis Voraussetzung, nicht Beiwerk. Und wenn regulatorische Anforderungen eine nachvollziehbare, eingefrorene Datenhaltung verlangen. In diesen Fällen ist das Warehouse kein zusätzliches Silo, sondern beantwortet eine Frage, die anders nicht zu beantworten ist.
Das Fazit in einem Satz
Die Frage ist nicht, ob Sie ein Data Warehouse brauchen, sondern welche Frage Sie beantwortet haben wollen — und für die Fragen, an denen Marketingteams heute tatsächlich hängen, ist die Antwort meistens nicht eine weitere Kopie Ihrer Zahlen, sondern Zugang zu dem Wissen, das Sie längst besitzen und bisher niemand abrufen kann. Wenn Sie ein bestehendes Angebot für ein Marketing Data Warehouse gegenlesen lassen möchten, bevor Sie unterschreiben: Sprechen Sie uns an. Wir sagen Ihnen auch, wenn das Warehouse in Ihrem Fall die richtige Entscheidung ist.
Quellen:
Salesforce, Zero Copy Partner Network (Ankündigung April 2024, salesforce.com/data/connectivity/zero-copy/) · Gartner Magic Quadrant for Customer Data Platforms 2026 (Hightouch als Leader; Marktübersicht via cxtoday.com) · TechRepublic, «85% of big data projects fail», 10.11.2017 (Ursprung der Zahl: gelöschter Tweet von Nick Heudecker) · Gartner Newsroom, Pressemitteilung vom 28.02.2024 zur Prognose, dass bis 2027 80 Prozent der Data-and-Analytics-Governance-Initiativen scheitern (Titel und URL geprüft, Volltext hinter Bot-Schutz nicht abrufbar) · Fachliteratur zu den Grenzen von Retrieval bei strukturierten Daten, Übersicht bei AI21 Labs, «RAG for Structured Data».