Alle relevanten KPIs deines Unternehmens an einem Ort.

Ein Dashboard ist kein Selbstzweck. Es ist ein Werkzeug, um Entscheidungen schneller, sicherer und auf besserer Datenbasis zu treffen. Genau hier scheitern die meisten Reporting-Projekte in mittelständischen Unternehmen: Sie entwickeln meistens Dashboards, die niemand öffnet, weil sie entweder zu viele Informationen zeigen, die falschen Informationen liefern oder die falsche Flughöhe besitzen.

Aus meiner Erfahrung aus den letzten Jahren von B2B-Projekten, lassen sich drei Qualitätsmerkmale ableiten, an denen du erkennst, ob ein Dashboard funktioniert:

Erstens muss das Übersichts-Dashbaord in der Lage sein, dir innerhalb von 30 Sekunden einen überblick zu verschaffen. Wer länger braucht, wird das Dashboard nicht regelmäßig nutzen.

Zweitens muss jede Kennzahl an eine konkrete Entscheidung gekoppelt sein. Eine Zahl, die niemand interpretiert, ist überflüssig und lenkt nur ab.

Drittens muss die Datenherkunft jeder Zahl dokumentiert sein, sonst beginnt jede Diskussion mit der Frage, ob die Zahl stimmt, statt mit der Frage, was sie bedeutet.

Auch wenn diese drei Kriterien banal klingen, in der Praxis werden sie ständig ignoriert. Meist, weil ein Dashboard nicht strategisch konzipiert wurde, sondern aus einer Sammlung verfügbarer Datenquellen entstanden ist. Genau das ist der Unterschied zwischen Reporting und Berichten: Reporting beantwortet Geschäftsfragen, Berichte zeigen Zahlen.

Die häufigste Frage in Erstgesprächen lautet: "Welches Tool empfiehlst du?" Die ehrliche Antwort ist: Es kommt darauf an. Ich habe Projekte mit Google Data Studio abgeschlossen, in denen Metabase die schlechtere Wahl gewesen wäre – und umgekehrt. Die Entscheidung sollte sich an drei Fragen orientieren:

Wo liegen deine Daten?

Wenn der Großteil deiner Daten im Google-Ökosystem entsteht (Google Ads, Google Analytics 4, Google Sheets, BigQuery), ist Looker Studio der natürliche Frontend-Layer. Die nativen Connectors sind ausgereift, die Lernkurve flach. Bei eigenen Datenbanken (PostgreSQL, MySQL, SQL Server) ist Metabase oft die bessere Wahl, weil es nativ SQL versteht und sich datennah verhält.

Wer arbeitet damit?

Looker Studio bzw. Data Studio ist visuell zugänglich und für Marketing-Teams ohne SQL-Kenntnisse schnell und intuitiv bedienbar (spätestens nach einer kurzen Einweisung von mir auf jeden Fall). Metabase setzt voraus, dass mindestens eine Person im Team SQL schreiben oder zumindest lesen kann. belohnt das aber mit deutlich komplexeren Analyse-Abfragen.

Wo soll es laufen?

Looker Studio läuft in der Google-Cloud, was bei sensiblen Daten schnell schwierig wird. Metabase kannst du hingegen selbst hosten (etwa als Docker-Container auf einem EU-Server), was bei strengen Compliance-Anforderungen ein klarer Vorteil ist.

In über 80 Prozent meiner KMU-Projekte ist die Antwort eine Kombination: BigQuery als Datawarehouse, Looker Studio als Standard-Frontend für Reports in Firmen-CI. Metabase oder eine Custom-Lösung für die Operative, die tiefere SQL-Auswertungen braucht. Diese Architekturen sind eigentlich die angenehmsteb Varianten.

In meiner Praxis taucht regelmäßig dasselbe Problem auf: Ein KMU nutzt ein spezialisiertes Branchen-Tool, sei es sein eigenes CRM, eine Telefonie-Plattform, ein ERP, eine Buchungssoftware. Für das es keinen fertigen Connector zu Looker Studio oder Metabase gibt.

Die Standard-Antwort vieler Agenturen lautet dann: "Das geht nicht." was leider grober Unfug ist. Es bedeutet lediglich, dass eine andere Architektur nötig ist.

Hier setze ich n8n ein, eine Open-Source-Workflow-Engine, die ich als Bindeglied zwischen REST-APIs und den Datenbank bzw. Datawarehouses einsetze. Konkret läuft das so: n8n ruft in definierten Intervallen die REST-API des Quell-Tools ab, normalisiert die Daten und schreibt sie in eine Datenbank auf die Looker Studio oder Metabase zugreifen können.

Der Vorteil einer solchen Architektur: Sie ist transparent, selbst hostbar, datenschutzkonform und viel wichtiger: wartbar von deinem Team. Ich baue keine intransparenten ETL-Konstrukte mit proprietären Tools, die du im Zweifel nicht mehr ablösen kannst. Wenn du n8n-Workflows lassen sich recht intuitiv benutzen und so können wir auch im Sparring an den Workflows arbeiten.

Mir ist das wichtig, da eine der größten Gefahren in der Mittelstands-IT die Lock-in-Falle ist: Ein Setup, das nur eine bestimmte Person oder eine bestimmte Agentur warten kann. Das mag kurzfristig bequem sein und für die Agentur sicherlich eine garantierte Auftragslage versprechen. Aber keinem ist damit geholfen. Wirklich nicht!

Eine der häufigsten Anti-Patterns, die ich in KMU sehe: Das eine große Dashboard für alle. Das funktioniert eher selten. Geschäftsführung, Marketing, Sales, HR und Content-Teams haben grundlegend unterschiedliche Fragen und entsprechend brauchen sie unterschiedliche Dashboards.

Mein Ansatz für Stakeholder-spezifische Dashboards

Ich baue Dashboards immer entlang der Stakeholder und ihrer konkreten Fragen auf. Eine sinnvolle Architektur arbeitet dabei mit Layern, die sich an Rolle und Informationsbedarf orientieren:

Executive View (C-Level)

Maximal fünf bis sieben Kennzahlen. Umsatz, Lead-Pipeline und Volumen, HR-Insights und Alerts für Dinge die nicht warten können. Aktualisierung täglich. Visuell so reduziert, dass die Geschäftsführung in 30 Sekunden weiß, ob alles noch auf Kurs ist.

Marketing-View

Hier geht es um die Frage: Wie funktionieren unsere Kampagnen? Kanal-Performance, ROAS pro Kampagne, Conversion-Rate über den Funnel, Quellen-Attribution. Es muss möglich sein, alles nachzuverfolgen -> von der Kampagne über die Webseiten besucher bis hin zum echten Lead der im CRM landet.

Content- und Web-View

Die Teams, die sich um Inhalte und Website kümmern, wollen verstehen, wie Besucher mit den Seiten interagieren. Scrolltiefe, Verweildauer, Klickpfade, Content-Performance pro URL, interne Suche.

Operative-View

Tagesgenaue Detail-Tabellen, A/B-Test-Ergebnisse, Pixel-Status, Tracking-Healthchecks. Granularität bis auf Event-Ebene.Diese Architektur löst ein soziales Problem genauso wie ein technisches: Wer hat Zugriff auf was? Die Geschäftsführung will nicht in Operative-Daten ertrinken, das Operative-Team will nicht jeden Klick erklären müssen.

Mit klarer Trennung bekommt jeder Bereich genau die Tiefe, die er brauch, zugeschnitten auf die Fragen, die er tatsächlich stellt.

Ein Dashboard ist keine isolierte technische Frage. Es ist Teil deines Daten-Setups und damit meisten recht schnell DSGVO-relevant. Drei Punkte, die ich in jedem Projekt prüfe:

Erstens: Datenquellen-Kette

Wenn dein Dashboard Daten aus Google Analytics 4 zieht, hängt es an einer Verarbeitungskette, die nach dem EuGH-Urteil "Schrems II" (C-311/18, 2020) und der nachfolgenden Praxis der deutschen Datenschutzaufsichten kritisch betrachtet wird. Wer langfristig auf der sicheren Seite stehen will, prüft datenschutzfreundliche Alternativen wie etracker oder Matomo-> siehe meine Sub-Page zu DSGVO-konformem Tracking.

Zweitens: Personenbezug im Dashboard

Sobald ein Dashboard personenbezogene Daten anzeigt (E-Mail-Adressen, Lead-Detailansichten), greift Art. 32 DSGVO – technische und organisatorische Maßnahmen müssen dokumentiert werden. Zugriffsbeschränkungen, Verschlüsselung, Logging.

Drittens: Auftragsverarbeitung

Wenn ein Tool-Anbieter Zugriff auf deine Daten hat, braucht es einen AV-Vertrag nach Art. 28 DSGVO. Das wird in der Praxis häufig vergessen und ist im Schadensfall teuer.

Diese Punkte adressiere ich in jedem Projekt strukturiert. Sie sind kein nachgelagerter Compliance-Step, sondern Teil der Architektur-Entscheidung.

Der häufigste Fehler bei Reporting-Projekten ist nicht die Konzeption oder der Aufbau. Es ist die Phase nach dem Launch. Ein Dashboard wird ausgerollt, alle nicken anerkennend und nach drei Wochen schaut niemand mehr hinein.

Aus meinen Projekten weiß ich: Dashboards setzen sich nur durch, wenn sie an konkrete Entscheidungsroutinen gekoppelt sind. Das bedeutet praktisch: Ein wöchentliches Marketing-Meeting beginnt mit dem Marketing-Dashboard. Eine monatliche Geschäftsleitungsrunde beginnt mit dem Executive-View. A/B-Test-Reviews finden auf dem Operative-Dashboard statt. Und das passiert nicht als "Zwang", sondern einfach, weil es die Teams entlastet, das Dashboard aufzurufen!

Im Growth-Retainer arbeite ich deshalb nicht nur an der technischen Weiterentwicklung des Dashboards, sondern auch an seiner Integration in eure Arbeitsweise. Welche Insights führen zu welcher Aktion? Welche KPI löst welche Eskalation aus? Wer hat die Verantwortung, wenn eine Zahl ins Rote rutscht? Das sind Fragen, die ein Tool allein nicht beantwortet, aber ohne sie bleibt jedes Reporting Theorie.Mein Ziel ist nicht, dir ein schönste Dashboard mit vielen Zahlen zu bauen. Mein Ziel ist, dass dein Team in sechs Monaten anders entscheidet als heute: auf besserer Datenbasis, schneller, und mit weniger Diskussion. Wenn das gelingt, hat sich das Projekt gerechnet.

Tracking ist kein einmaliges Projekt. Es ist ein kontinuierlicher Prozess, der mit jedem neuen Marketing-Kanal, jeder neuen Kampagne und jeder Browser-Änderung erneut justiert werden muss. Genau das wird in der Praxis am häufigsten ignoriert.

Drei Routinen, die ich in jedem Setup verankere – egal wie groß oder klein das Projekt ist:

Datenabgleich

Tracking-Zahlen gegen Backend-Daten prüfen. Wenn dein Shop-System 540 Bestellungen meldet und dein Tracking 380, weißt du, dass etwas nicht stimmt – aber nur, wenn jemand regelmäßig hinschaut.

Pixel-Health-Check

Eine kurze Übersicht, ob alle relevanten Pixel zuverlässig feuern und ob die Zahlen in der erwarteten Größenordnung liegen. Aufwand: ein automatisierter Report.

DSGVO-Review

Mindestens einmal pro Jahr wird geprüft, ob neue rechtliche Vorgaben Anpassungen am Tracking-Setup erfordern. Die Rechtsprechung verändert sich – dein Setup muss mitziehen.

Diese Routinen sind weder spektakulär noch teuer. Aber sie sind der Unterschied zwischen einem Tracking-Setup, das drei Jahre lang stabil läuft, und einem, das nach sechs Monaten wieder mehr Fragen als Antworten produziert. Wenn du Wert auf langfristige Datenqualität legst, gehört diese Kontinuität zum Projekt dazu – nicht als Add-on, sondern als integraler Teil.