Ich habe diese Datentöpfe selbst gebaut. Meistens braucht es sie nicht.

Ich habe einen Teil meines Berufslebens damit verbracht, Daten zusammenzuführen. Kampagnensteuerung über DV360 und Campaign Manager, Auswertungen über Systemgrenzen hinweg, Pipelines, die morgens liefen, damit mittags jemand eine Zahl hatte. Ich sage das vorweg, weil das Folgende sonst nach Bequemlichkeit klingt: Wenn mir heute ein Unternehmen erzählt, die Agentur empfehle ein «Marketing Data Warehouse», ist meine erste Frage nicht, wie man es baut. Sie lautet, welche Frage damit beantwortet werden soll.

Die Antwort fällt erstaunlich oft vage aus. Man wolle «endlich eine zentrale Sicht». Die Daten seien «überall verstreut». Beides ist wahr. Nur folgt aus einer richtigen Diagnose nicht automatisch die richtige Therapie.

Was in so einem Projekt tatsächlich entsteht

Ein Marketing Data Warehouse ist eine Kopie. Die Zahlen bleiben in Google Ads, in GA4, im CRM, im Shop — und liegen danach zusätzlich noch einmal in einer neuen Datenbank. Damit diese Kopie nicht altert, braucht es Strecken, die regelmässig laufen. Die brechen, wenn ein Anbieter seine Schnittstelle ändert. Sie brauchen jemanden, der sie repariert. Und irgendwann sitzt man in einer Sitzung, in der die Umsatzzahl aus dem Warehouse und die aus dem Shop um vier Prozent auseinanderliegen, und diskutiert eine Stunde darüber, welche stimmt.

Angetreten war man, um Silos abzuschaffen. Entstanden ist ein weiteres — mit dem Unterschied, dass dieses nun Ihnen gehört und seine Pflege in Ihrem Budget steht.

Ich halte das nicht grundsätzlich für falsch. Ich halte es für falsch, wenn es auf Vorrat passiert. Ein Warehouse, das aus einer konkreten Frage entsteht, die anders nicht zu beantworten war, ist gut angelegtes Geld. Eines, das gebaut wird, weil «zentrale Datenhaltung» in einem Konzept solide aussieht, ist eine Wette darauf, dass die Fragen später schon kommen werden.

Die Frage, die in keiner Tabelle steht

Der Punkt, der mir wichtiger ist, kommt aus dem Unterricht. Wenn ich in Kursen frage, woran Teilnehmende in ihrem Alltag tatsächlich hängen bleiben, höre ich nie «uns fehlt die Klickzahl». Ich höre Fragen dieser Art: Warum haben wir diese Zielgruppe damals gewählt? Was kam bei der Kampagne im letzten Frühling heraus, und was haben wir daraus gelernt? Was dürfen wir über dieses Produkt behaupten und was nicht? Wie hat der Kunde auf den letzten Vorschlag reagiert?

Keine dieser Antworten steht in einer Tabelle. Sie stehen in Briefings, in Protokollen, in Richtlinien, in Auswertungen, die jemand nach der Kampagne geschrieben hat und die seither niemand mehr geöffnet hat. Das ist das eigentliche Firmenwissen. Und es ist genau der Teil, den ein Data Warehouse konstruktionsbedingt nicht aufnimmt, weil er sich nicht in Spalten abbilden lässt.

Man kann also ein technisch tadelloses Warehouse betreiben und trotzdem jedes Mal bei null anfangen, sobald eine neue Mitarbeiterin, eine neue Agentur oder ein KI-System fragt, warum die Dinge sind, wie sie sind.

Für diese Datenklasse gibt es ein passendes Werkzeug: einen Retrieval-Layer über die eigenen Dokumente, der die relevanten Stellen findet und einem Sprachmodell als Kontext übergibt. Damit wird das Wissen adressierbar, das heute in Ordnern liegt. Das ist der Schritt, der in den meisten Firmen mehr verändert als eine weitere Kopie der Klickzahlen.

Wo ich der eigenen These widerspreche

Hier muss ich gegen die eigene Zuspitzung anschreiben, sonst wird sie unredlich. Ein Retrieval-System ersetzt kein Data Warehouse. Semantische Suche findet Ähnliches, nicht Vollständiges — und ohne die Garantie, alle relevanten Datensätze erwischt zu haben, ist jede Summe wertlos. Wer eine Quartalszahl aus einem Vektorindex zieht, bekommt eine plausible Zahl, keine richtige. Für alles, was gerechnet statt gelesen werden muss, führt der Weg über eine Abfrage gegen strukturierte Daten.

Es sind zwei Werkzeuge für zwei Datenklassen. Der Fehler im Agenturpitch ist nicht das Warehouse an sich. Es ist die Annahme, dass sich mit einer zentralen Zahlensammlung ein Wissensproblem lösen lässt.

Ein Test, den ich jedem mitgebe

Wenn im Gespräch der Satz fällt, 85 Prozent aller Datenprojekte scheiterten, fragen Sie nach der Quelle. Ich habe das nachverfolgt: Die Zahl geht auf einen Tweet des damaligen Gartner-Analysten Nick Heudecker aus dem Jahr 2017 zurück, in dem er die frühere Schätzung von 60 Prozent als zu konservativ bezeichnete. TechRepublic griff das im November 2017 auf. Der Tweet ist gelöscht. Eine Gartner-Studie mit dieser Zahl existiert nicht.

Das heisst nicht, dass Datenprojekte gut laufen — meine Erfahrung sagt das Gegenteil. Es heisst, dass jemand eine Zahl aus einem gelöschten Tweet als Studienergebnis präsentiert und dabei nicht nachgesehen hat. Wer die Zahlen in der eigenen Präsentation nicht prüft, prüft sie in Ihrem Projekt auch nicht. Das ist billiger zu erkennen als ein abgebrochenes Projekt nach acht Monaten.

Verwandt: Attribution zählt Klicks. Marketing-Mix-Modeling zählt Wirkung. — dort geht es um die Frage, welche Zahl überhaupt welche Aussage trägt. Die ausführliche Fassung mit der Empfehlung zur Reihenfolge steht im Blog von digital opua: Braucht Marketing ein eigenes Data Warehouse?