Wie man ein DSGVO-konformes Admin-Dashboard im Alleingang erstellt

Ein Solo-Entwickler braucht Metriken genauso sehr wie ein Team von 50 Personen. Vielleicht sogar mehr. Wenn du alleine das Backend, Frontend, Marketing und den Support verwaltest, kannst du es dir nicht leisten, zu raten, was passiert. Du musst sehen: wie viele Benutzer aktiv sind, welche Funktionen genutzt werden, ob das Backend die Last bewältigt, ob die Sprach-Pipeline abstürzt.

Ich habe ein vollständiges Admin-Dashboard für TAMSIV, ein E-Mail-Benachrichtigungssystem für kritische Vorfälle und ein DSGVO-konformes Analytics-Tracking aufgebaut. Hier erfährst du, wie das alles zusammenhängt und warum jeder Baustein unverzichtbar ist, wenn du alleine operierst.

Wichtige Punkte zum Merken:
- Ein Admin-Dashboard ist kein Luxus – es ist entscheidend für einen Solo-Entwickler in der Produktion
- GA4 mit Consent Mode ermöglicht DSGVO-Konformität, ohne Metriken zu opfern
- E-Mail-Benachrichtigungen (AlertService) erkennen Probleme, bevor die Benutzer es tun
- Das Cookie-Consent mit 3 Toggles und Versionierung ist das DSGVO-Minimum in Europa
- Das Dual-Tracking (GA4 + Supabase) deckt Web-Metriken UND Geschäftsmetriken ab

Warum braucht ein Solo-Entwickler ein Admin-Dashboard?

Die kurze Antwort: weil du kein SRE-Team, keinen Produktmanager, keinen Analysten hast. Du bist all das gleichzeitig. Und ohne Einblick in das, was in deiner App passiert, triffst du Entscheidungen blind.

Vor dem Dashboard entdeckte ich Probleme durch Benutzerfeedback (wenn sie sich die Mühe machten, zu schreiben). Ein Absturz der Sprach-Pipeline konnte stundenlang unbemerkt bleiben. Ein Anstieg der Anmeldungen wurde übersehen. Eine Funktion, die niemand nutzte, kostete mich weiterhin Wartungszeit.

Das Admin-Dashboard hat das geändert. Erreichbar unter /admin/dashboard auf tamsiv.com, gibt es mir eine Echtzeitansicht von allem, was wichtig ist:

• Benutzer: Tägliche Anmeldungen, aktive Benutzer (DAU/WAU/MAU), Retention
• Funktionen: Nutzung des Diktiergeräts, Erstellung von Aufgaben/Memos/Ereignissen, Gamification
• Infrastruktur: WebSocket-Latenz, STT-Fehlerrate, ausgelöste LLM-Fallbacks
• Business: Free → Pro-Konversionen, RevenueCat-Einnahmen, Abwanderungsrate

Wie erstellt man ein Admin-Dashboard mit Recharts und Supabase?

Das Dashboard ist mit Recharts erstellt, einer React-Grafikbibliothek, die auf D3.js basiert. Warum Recharts? Weil es sich nativ in React integriert, SSR unterstützt (wichtig für Next.js) und die Darstellung sauber ist, ohne komplexe Konfiguration.

Die Architektur ist einfach:

1. Daten: Alles kommt von Supabase über RPC-Funktionen. Jede Grafik hat ihre eigene RPC, die die Daten serverseitig aggregiert.
2. Statistikkarten: Oben im Dashboard zeigen Karten die KPIs in Echtzeit (Gesamtzahl der Benutzer, heute aktive Benutzer, erstellte Aufgaben usw.).
3. Zeitliche Grafiken: Kurven der täglichen Anmeldungen, Nutzung pro Funktion, Retentions-Histogramme.
4. Tabellen: Liste der letzten Ereignisse (Anmeldungen, Fehler, Warnungen).

Ein wichtiger Punkt: Die Supabase-RPCs verwenden Parameter mit dem Präfix p_ (Projektkonvention). Zum Beispiel p_start_date, p_end_date, p_metric_type. Diese RPCs führen die Aggregationsberechnungen direkt in PostgreSQL durch – viel leistungsfähiger, als Tausende von Zeilen clientseitig abzurufen.

Das Dashboard ist durch eine Admin-Rollenprüfung auf Next.js-Middleware-Ebene geschützt. Nur Benutzer mit der Rolle admin in Supabase Auth können darauf zugreifen.

Was ist der AlertService und warum ist er in der Produktion kritisch?

Das Dashboard ist für die Zeit, in der du vor deinem Bildschirm sitzt. Aber Vorfälle warten nicht darauf, dass du das Dashboard öffnest. Der AlertService ist mein automatisches Überwachungssystem, das mir eine E-Mail sendet, wenn etwas Ungewöhnliches passiert.

Hier sind die konfigurierten Warnungen:

• LLM-Fallback ausgelöst: Wenn das Hauptmodell (über OpenRouter) fehlschlägt und der Fallback übernimmt. Dies deutet auf ein Problem beim Anbieter oder eine Lastspitze hin.
• Wiederholte Fehler in der Sprach-Pipeline: Wenn STT oder TTS mehr als X Mal in Y Minuten fehlschlagen, erhalte ich eine E-Mail. Dies kann auf einen Deepgram-Ausfall oder ein OpenAI-Kontingentproblem hinweisen.
• Übermäßige Ratenbegrenzung: Wenn ein Benutzer oder eine IP den Ratenbegrenzer wiederholt auslöst, kann dies ein Missbrauch oder ein Bot sein.
• Anmeldefehler: Wenn der Anmeldevorgang (E-Mail oder QR-Code) für mehrere Benutzer fehlschlägt, liegt wahrscheinlich ein Fehler vor.

Die E-Mails werden über Resend gesendet, einen einfachen und zuverlässigen Transaktions-E-Mail-Dienst. Jede Warnung wird auch in einer Supabase-Tabelle für die Historie protokolliert – ich kann die Vorfallshistorie im Admin-Dashboard finden.

Wie implementiert man GA4 mit dem DSGVO-Consent Mode?

Die DSGVO (Datenschutz-Grundverordnung) ist für eine europäische Website nicht verhandelbar. Das bedeutet: kein Tracking ohne ausdrückliche Zustimmung. Google Analytics 4 unterstützt nativ den Consent Mode, einen Mechanismus, der sein Verhalten an die Zustimmung des Benutzers anpasst.

So funktioniert es auf tamsiv.com:

1. Initialisierung im "denied"-Modus: GA4 wird beim Start der Website geladen, aber mit analytics_storage: 'denied' und ad_storage: 'denied'. Es werden keine Daten gesammelt.
2. Explizite Zustimmung: Wenn der Benutzer die Analytics-Cookies im Banner akzeptiert, wird die Zustimmung über gtag('consent', 'update', { analytics_storage: 'granted' }) aktualisiert.
3. Modellierung: Mit dem Consent Mode verwendet Google die Modellierung, um die Daten von Benutzern zu schätzen, die nicht zugestimmt haben. Du erhältst zuverlässige Trends, auch wenn 50 % der Besucher das Tracking ablehnen.

Der GA4-Tag (G-VVLHW673V3) wird nur einmal beim ersten Laden der Seite initialisiert. Die Zustimmung wird in einem First-Party-Cookie gespeichert und bei jedem Besuch wiederhergestellt. Wenn der Benutzer seine Meinung ändert, kann er seine Präferenzen im Cookie-Banner ändern, das über die Fußzeile zugänglich ist.

Wie gestaltet man ein DSGVO-konformes Cookie-Consent?

Das Cookie-Banner von TAMSIV hat 3 Toggles, jeder mit einer bestimmten Rolle:

• Notwendig (immer aktiv, nicht deaktivierbar): Auth-Sitzung, Spracheinstellungen, Cookie-Zustimmung selbst. Ohne diese Cookies funktioniert die Website nicht.
• Analytics (standardmäßig deaktiviert): GA4, Supabase-Navigationsmetriken. Nur nach Zustimmung aktiv.
• Marketing (standardmäßig deaktiviert): Für die Zukunft geplant (Retargeting, Werbepixel). Derzeit deaktiviert, da nicht verwendet.

Ein oft übersehener Punkt: die Versionierung der Zustimmung. Wenn sich die Cookie-Richtlinie ändert (Hinzufügen eines neuen Trackers, Änderung der Zwecke), muss das Banner für alle Benutzer wieder erscheinen, auch für diejenigen, die bereits zugestimmt haben. Ich habe dies mit einer Versionsnummer implementiert, die im Zustimmungs-Cookie gespeichert ist. Wenn sich die Version ändert, wird das Banner erneut angezeigt.

Warum ein Dual-Tracking GA4 + Supabase verwenden?

GA4 ist hervorragend für Standard-Webmetriken: Seitenaufrufe, Absprungrate, Traffic-Quellen, Konversionen. Aber es gibt Metriken, die GA4 nicht oder nicht detailliert genug erfassen kann:

• Detaillierter Konversionspfad: Der genaue Weg eines Besuchers von der Landingpage zur Anmeldung, mit den Zwischeninteraktionen (CTA-Klick, FAQ öffnen, Sprachwechsel).
• Geschäftsmetriken: Anzahl der über das Web vs. die mobile App erstellten Aufgaben, Aufgabenabschlussrate, Gamification-Aktivität.
• Multi-Device-Attribution: Ein Benutzer, der die Website auf dem Desktop entdeckt und die App auf dem Handy herunterlädt. GA4 stellt diese Verbindung nicht her. Supabase, mit der Auth-UUID, schon.

Das Supabase-Tracking funktioniert mit einer anonymen UUID pro Besucher (generiert beim ersten Laden, im localStorage gespeichert). Jede signifikante Interaktion wird in einer Supabase-Tabelle protokolliert. Wenn sich der Besucher anmeldet, wird die anonyme UUID mit seinem Auth-Konto verknüpft – was es ermöglicht, den gesamten Pfad vom ersten Klick bis zur Anmeldung zu rekonstruieren.

Dieses Dual-Tracking gibt mir zwei ergänzende Lesarten: GA4 für Makro-Trends (woher kommen die Besucher, welche Seiten funktionieren) und Supabase für Mikro-Einblicke (welcher typische Pfad führt zu einer Konversion).

Welche Metriken sollten für eine mobile App priorisiert werden?

Wenn du anfängst, bist du versucht, alles zu messen. Schlechte Idee – du ertrinkst in Daten, ohne etwas zu tun. Hier sind die Metriken, die ich im TAMSIV-Dashboard priorisiere:

1. DAU (Daily Active Users): Der Puls der App. Wenn es sinkt, stimmt etwas nicht.
2. Retentionsrate T1/T7/T30: Wie viele Benutzer zurückkehren. Dies ist die wichtigste Metrik für ein Produktivitäts-Produkt.
3. Abschlussrate der ersten Aufgabe: Schaffen es neue Benutzer, ihre erste Aufgabe zu erstellen? Wenn nicht, hat das Onboarding ein Problem.
4. Konversion Free → Pro: Der Kern des Geschäfts. Wie viele kostenlose Benutzer werden zahlende Benutzer und nach wie vielen Tagen Nutzung.
5. Fehlerrate der Sprach-Pipeline: Der Prozentsatz der Sprachkonversationen, die fehlschlagen. Sollte unter 2 % bleiben.

Jede dieser Metriken hat ihre eigene Grafik im Dashboard, mit einem Trend über 7 und 30 Tage. Ein System von farbigen Schwellenwerten (grün/orange/rot) ermöglicht es mir, auf einen Blick zu sehen, ob alles in Ordnung ist.

Wie haben E-Mail-Benachrichtigungen meine Produktion gerettet?

Konkretes Beispiel: An einem Samstagabend erhielt ich eine E-Mail "Fallback LLM ausgelöst – 12 Mal in 15 Minuten". Das Hauptmodell auf OpenRouter war überlastet. Ohne Warnung hätte ich es am Montag entdeckt, wenn ich die Metriken angesehen hätte. Dank der Warnung habe ich überprüft, ob der Fallback korrekt funktionierte (er funktionierte) und konnte bei Bedarf proaktiv kommunizieren.

Ein weiteres Beispiel: Eine Spitze der Ratenbegrenzung auf einer bestimmten IP. Bei der Untersuchung entdeckte ich ein automatisiertes Skript, das versuchte, massenhaft Konten zu erstellen. Der Ratenbegrenzer hatte seine Arbeit getan, aber die Warnung ermöglichte es mir, die IP zu blockieren und den Schutz zu verstärken.

Der AlertService ist mein Sicherheitsnetz. Er ersetzt nicht die Überwachung (ich verwende auch Railway-Logs für das Backend), aber er warnt mich vor den kritischsten Vorfällen, ohne dass ich aktiv überwachen muss.

FAQ

Braucht man ein Admin-Dashboard schon beim Start?

Nicht unbedingt am Tag 1, aber sobald du Benutzer in der Produktion hast, ja. Ich habe es einige Wochen vor dem Start gebaut und es hat mich mehrmals gerettet. Konfiguriere zumindest die E-Mail-Benachrichtigungen – das ist dringender als das visuelle Dashboard.

Ist GA4 DSGVO-konform ohne Zustimmung?

Nein. Selbst mit dem Consent Mode im "denied"-Modus sendet GA4 anonyme Pings an Google. Um 100 % konform zu sein, musst du ein Cookie-Banner anzeigen und GA4 erst nach Zustimmung laden, oder den Consent Mode verwenden, der das Verhalten anpasst. Der Consent Mode ist die von Google empfohlene Lösung und wird von den meisten europäischen Datenschutzbehörden akzeptiert.

Warum Recharts statt Chart.js oder D3 direkt?

Recharts ist ein React-Wrapper um D3. Der Vorteil: Die Grafiken sind deklarative React-Komponenten, kein imperativer Code. Das ist in einem Next.js-Projekt natürlicher. Chart.js funktioniert auch, erfordert aber mehr Integrationscode mit React.

Wie viel kostet das E-Mail-Benachrichtigungssystem mit Resend?

Der kostenlose Plan von Resend beinhaltet 3000 E-Mails pro Monat. Für Warnungen (einige Dutzend pro Monat im Normalbetrieb) ist das mehr als ausreichend. Die Kosten sind also null für ein kleines Projekt in der Produktion.

Überlappt das Supabase-Tracking nicht mit GA4?

Nein, sie messen unterschiedliche Dinge. GA4 ist hervorragend für Web-Traffic (Quellen, Verhalten, Konversionen). Supabase misst das Verhalten in der App (erstellte Aufgaben, genutzte Funktionen, Multi-Device-Pfade). Die beiden sind komplementär, nicht redundant.