Kurz gesagt: BI-Werkzeuge sind für Transaktionsdaten gebaut – eine Zeile pro Vorgang, numerische Felder, additive Kennzahlen. Umfragedaten verletzen fast jede dieser Annahmen. Das Ergebnis ist kein etwas ungenaues Dashboard, sondern ein falsches. Dieser Text sammelt die fünf Bruchstellen, die in der Praxis am meisten Zeit kosten, und ordnet ein, wann sich Eigenbau lohnt und wann nicht.
Die Ausgangslage
Ein Kunde bringt einen Datensatz aus der Marktforschung. Eine .sav-Datei, vielleicht ein CSV mit einem Codebuch als Excel daneben. Die Anfrage klingt harmlos: „Können Sie uns daraus ein Dashboard bauen? So wie das für die Vertriebszahlen.“
Technisch ist der Import in zehn Minuten erledigt. Die Probleme beginnen danach – und sie sind nicht offensichtlich, weil das Dashboard funktioniert. Es zeigt Zahlen. Nur eben die falschen.
Bruchstelle 1: Labels sind keine Daten
In einem SPSS-Datensatz steht in der Spalte q3 der Wert 2. Was 2 bedeutet, steht nicht in den Daten, sondern in den Metadaten: Variablenlabel („Wie zufrieden sind Sie insgesamt?“) und Wertelabels (1 = sehr zufrieden … 5 = sehr unzufrieden).
Der Standard-CSV-Export wirft beides weg. Übrig bleibt eine Spalte namens q3 mit Zahlen von 1 bis 5. Das Dashboard zeigt dann einen Durchschnitt von 2,4 für „q3“ – fachlich wertlos und für den Endnutzer nicht interpretierbar.
Der übliche Behelf ist eine manuell gepflegte Mapping-Tabelle. Sie funktioniert genau bis zur nächsten Welle, in der eine Antwortoption dazukommt.
Bruchstelle 2: Gewichte, und was ohne sie passiert
Das ist der teuerste Punkt, weil er unsichtbar ist.
Stichproben bilden die Grundgesamtheit selten exakt ab – Jüngere antworten seltener, bestimmte Regionen sind überrepräsentiert. Die Marktforschung korrigiert das über eine Gewichtungsvariable: Jeder Fall bekommt einen Faktor, oft zwischen 0,3 und 3,0. Erst gewichtet entspricht das Ergebnis der Grundgesamtheit.
Ein COUNT oder AVERAGE in DAX oder SQL ignoriert diese Spalte. Das Ergebnis ist nicht ungefähr richtig, sondern systematisch verzerrt – oft um mehrere Prozentpunkte, und zwar in eine Richtung, die niemand bemerkt, weil es keine Vergleichszahl gibt.
Nachbauen lässt es sich: gewichtete Mittelwerte über SUMX, gewichtete Anteile über Hilfsmaße. Die Schwierigkeit ist nicht die eine Kennzahl, sondern die Konsistenz. Sobald zwanzig Kennzahlen und mehrere Filterkontexte im Spiel sind, ist die Frage nicht mehr ob eine Stelle ungewichtet bleibt, sondern welche – und wer es merkt.
Bruchstelle 3: Mehrfachantworten passen nicht ins Datenmodell
„Welche dieser Marken kennen Sie?“ – Mehrfachnennung möglich. Im Datensatz landet das als Batterie von Dummy-Variablen: q7_1 bis q7_12, jeweils 0 oder 1.
Für ein BI-Tool sind das zwölf unabhängige Spalten. Fachlich sind es eine Frage. Der Unterschied zeigt sich beim Prozentwert: Die Basis ist die Anzahl der Befragten, nicht die Anzahl der Nennungen – die Anteile summieren sich also korrekterweise auf über 100 %. Wer sie normalisiert, weil die Summe „falsch aussieht“, produziert eine Zahl, die es in keinem Bericht der Welt gibt.
Sauber lösen lässt sich das durch Entpivotieren in eine lange Tabelle mit separater Basis-Berechnung. Das ist machbar – und es ist Arbeit, die pro Fragebatterie neu anfällt.
Bruchstelle 4: Signifikanz existiert im BI-Stack nicht
Der Markenwert steigt von 42 % auf 45 %. Ist das eine Entwicklung oder Rauschen?
Bei n = 500 und diesen Werten: Rauschen. Die Antwort erfordert einen Signifikanztest, der Stichprobengrößen, Gewichtung und – bei mehreren Vergleichen – eine Alpha-Korrektur berücksichtigt. Kein BI-Werkzeug bringt das mit. Man kann es in R oder Python rechnen und das Ergebnis einspielen, aber dann ist es ein statischer Anhang, kein Bestandteil der interaktiven Auswertung: Sobald der Nutzer filtert, stimmen die hinterlegten Signifikanzen nicht mehr.
Für den Endkunden ist das der gefährlichste Punkt, weil das Dashboard genau so aussieht, als wäre die Frage beantwortet. Ein Balken, der drei Punkte höher ist, wird gelesen wie ein Anstieg – auch wenn er keiner ist.
Bruchstelle 5: Wellen sind keine Zeitreihe
Ein Tracker mit acht Wellen sieht nach Zeitreihe aus, verhält sich aber nicht so. Zwischen den Wellen ändern sich Dinge: Eine Skala wird gedreht, eine Antwortoption kommt hinzu, die Gewichtung wird auf neue Zensusdaten umgestellt, ein Item wird umformuliert.
Wer stumpf über welle gruppiert, zeichnet Linien über Brüche hinweg, die methodisch keine sind. Sauber wäre eine Versionierung des Fragebogeninstruments mit dokumentierten Brüchen – ein Konzept, das im BI-Datenmodell schlicht nicht vorgesehen ist.
Warum das kein Werkzeugfehler ist
Nichts davon spricht gegen Power BI, Tableau oder Qlik. Diese Werkzeuge sind exzellent für das, wofür sie gebaut wurden: Transaktions- und Bewegungsdaten, additive Kennzahlen, saubere Sternschemata. Umfragedaten sind eine andere Datengattung – mit Metadaten, die zur Semantik gehören, nicht-additiven Basen und einer Fehlerrechnung, die in die Darstellung gehört.
Man kann diese Gattung im BI-Stack nachbilden. Die ehrliche Frage ist, was das kostet – nicht beim ersten Projekt, sondern beim fünften, wenn jeder Kunde eine leicht andere Fragebogenlogik mitbringt und jede Welle die Mappings anfasst.
Eine brauchbare Faustregel
Eigenbau lohnt sich, wenn es bei einem Datensatz bleibt, die Struktur stabil ist, keine Gewichtung im Spiel ist und niemand Signifikanz braucht. Das trifft auf einmalige Auswertungen und einfache Zufriedenheitsabfragen durchaus zu.
Eigenbau wird teuer, sobald mindestens zwei davon zutreffen: wiederkehrende Wellen, mehrere Datenlieferanten mit unterschiedlichen Formaten, Gewichtung, Mehrfachantworten in größerem Umfang, oder Endnutzer, die selbst filtern sollen. Dann wächst der Wartungsaufwand nicht linear, sondern mit der Anzahl der Kombinationen.
Der Punkt, an dem es in der Praxis kippt, ist meist nicht der Aufbau – sondern die dritte Welle, in der jemand fragt, warum die Zahl von damals heute anders aussieht.
Der Mittelweg: eine Schicht davor
Zwischen „alles in DAX nachbauen“ und „BI ersetzen“ liegt eine dritte Möglichkeit, die in der Praxis am besten funktioniert: eine Schicht, die Forschungsdaten korrekt hält – Labels, Gewichte, Basen, Signifikanz, Wellenlogik – und die Ergebnisse an den bestehenden Stack weiterreicht.
Der BI-Stack bleibt, wo er ist, und macht, was er gut kann. Was er nicht kann, passiert davor. Für Beratungen ist das die interessantere Variante, weil der Kunde seine Investition behält und die Implementierung trotzdem stattfindet.
Zum Schluss, in eigener Sache
Genau diese Schicht ist DataLion: Forschungsdaten mit Labels, Gewichtung, korrekten Basen, Signifikanz und Wellenlogik – abfragbar per Dashboard, per API und per KI, gehostet in Deutschland. Wir ersetzen keinen BI-Stack, wir liefern in ihn hinein.
Und der Vollständigkeit halber: Wir verkaufen keine Feldarbeit, keine Panels und keine Studien. Wir konkurrieren weder mit den Instituten, die die Daten erheben, noch mit den Partnern, die sie implementieren.
Wenn Sie als BI- oder Analytics-Beratung regelmäßig auf diese Datengattung stoßen: Für Implementierungspartner haben wir eine eigene Seite.