Data Engineering · Mobilitätsanbieter (DE)

Analytics-Plattform (BigQuery)

Eine produktionsreife Analytics-Plattform für eine Mobilitäts-App, von der Rohdaten-Normalisierung bis zum KI-gestützten Self-Service.

Rolle: Freelance Data Engineer · End-to-End-Verantwortung
Zeitraum: seit 2022 · langfristiges Teilzeit-Mandat

Kontext

Ausgangslage & Problem

Eine Mobilitäts-App erzeugt große Mengen an Produkt- und Trackingdaten: Firebase/GA4-Rohereignisse, Screen-Flows, Feature-Nutzung, Geräteinformationen, Conversion und Revenue. In ihrer Rohform sind diese Daten tief verschachtelt, treffen verspätet ein und unterscheiden sich zwischen iOS und Android. Ohne saubere Modellierung werden sie schnell unübersichtlich und für Fachbereiche nicht mehr nachvollziehbar.

Ziel war eine Datenplattform, die nicht nur Reports erzeugt, sondern tägliche Auswertungen reproduzierbar, qualitätsgesichert und für nicht-technische Stakeholder nutzbar macht. Daraus ist ein durchgängiges Ökosystem aus vier Säulen entstanden: ein dreischichtiges BigQuery-Warehouse, eine eigenständige Analytics-Pipeline für ein Dashboard-Personalisierungs-Feature, fünf eigene Looker-Studio-Visualisierungen und ein KI-gestützter Self-Service-Assistent.

Rolle

Meine Rolle & Rahmen

Alleinige End-to-End-Verantwortung über alle vier Säulen: Architektur, Datenmodellierung, ETL-Pipelines, Datenqualität, Visualisierung, KI-Integration sowie Deployment und Dokumentation.

Langfristiges Mandat seit 2022 mit rund 180 Dateien, davon etwa 120 SQL-Skripte. Der Fokus lag durchgehend auf hohem Automatisierungsgrad statt manueller Report-Arbeit.

Architektur

Entscheidungen & Trade-offs

Dreischichtiges Medallion-Modell (Foundation, Feature, Application) auf BigQuery.

Warum: Die klare Trennung von normalisierten Rohdaten, berechneten Metriken und Dashboard-Aggregaten hält die Pipelines wartbar, nachvollziehbar und unabhängig testbar.
Trade-off: Mehr Modellierungsdisziplin und Zwischenschichten gegen langfristige Klarheit und Wiederverwendbarkeit.

Idempotente Batch-ETLs über DELETE+INSERT bzw. TRUNCATE+INSERT.

Warum: Backfills und manuelle Re-Runs müssen jederzeit ohne Duplikate reproduzierbar sein, ohne dass der Zielzustand davon abhängt, wie oft ein ETL läuft.
Trade-off: Etwas teurere Schreiboperationen gegen verlässliche Wiederholbarkeit.

Mehrtägige Neuverarbeitung (T-2/T-3/T-4) statt einfacher T-1-Verarbeitung.

Warum: Firebase-Exporte treffen verspätet und teils unvollständig ein. Eine mehrtägige Neuverarbeitung stabilisiert die Zahlen automatisch, statt sie nachträglich von Hand zu korrigieren.
Trade-off: Jeder Lauf verarbeitet mehrere Tage neu, also höhere Rechenkosten gegen stabile, finale Zahlen.

Star-Schema mit synthetischem GENERATE_UUID()-Join-Key.

Warum: Ein gemeinsamer UUID-Schlüssel über die fünf Foundation-Tabellen macht die EAV-normalisierten Satelliten (Event-Parameter, User-Properties, Geo, Devices) sauber und konsistent joinbar.
Trade-off: Synthetischer Schlüssel pro Lauf statt natürlicher Schlüssel, dafür konsistente Joins über die gesamte Schicht.

Konsekutive Deduplizierung über einen config_hash für das Dashboard-Personalisierungs-Feature.

Warum: Ein MD5-Hash der Widget-Konfiguration verwirft konsekutive identische Zustände, behält aber legitime Wiederholungen nach einer Zwischenänderung. Das war nötig, weil iOS Konfigurations-Events bei jedem App-Start statt nur bei Änderung sendete und so rund 87 % Duplikate erzeugte.
Trade-off: Mehr Logik in der Pipeline (Lookback, Window-Funktionen) statt eines naiven Inserts.

Click-to-Order-Attribution über mehrere Zeitfenster statt einer Conversion-Zahl.

Warum: Widget-Klicks werden mit Bestelldaten in 1h-, 24h- und 7d-Fenstern verknüpft. Das gibt ein realistischeres Bild der Wirkung als eine einzelne, kontextlose Conversion-Rate.
Trade-off: Komplexere Joins inklusive Konvertierung zwischen BYTES und Base64-String, weil die Kundennummer in den Systemen unterschiedlich gespeichert ist.

Eigene Looker-Studio-Community-Visualizations statt Standard-Charts.

Warum: Standard-Charts decken fachliche Sichten wie Feature-Flows mit Screenshots, Plattform-Status-Badges und Figma-Deep-Links nicht ab. Eigene Visualisierungen in Vanilla-JS (dscc) liefern genau die benötigte Darstellung.
Trade-off: Eigener Build- und GCS-Deployment-Aufwand gegen volle Kontrolle über Darstellung und Interaktion.

KI-Self-Service über einen Slack-Assistenten (n8n + Claude) mit eingebettetem Schema.

Warum: Fachbereiche stellen Fragen in natürlicher Sprache; der Assistent kennt das vollständige BigQuery-Schema und generiert passende SQL- und Visualisierungsvorschläge. So landet nicht jede Frage beim Data-Team.
Trade-off: Laufende API-Kosten (rund 0,02 bis 0,05 USD pro Anfrage) und Prompt-Pflege gegen spürbare Entlastung des Data-Teams.

Umsetzung

Technische Highlights

Dreischichtiges Data-Warehouse auf Google BigQuery (Foundation, Feature, Application) mit rund 120 SQL-Skripten
Zehn deployte Scheduled Queries (03:30 bis 05:00) mit dokumentierten Abhängigkeiten, Idempotenz und Laufzeitschätzungen
Normalisierung tief verschachtelter Firebase/GA4-Rohdaten in ein Star-Schema (EAV für Event-Parameter und User-Properties)
Session-Rekonstruktion und Screen-Flow über Window-Funktionen (30-Minuten-Timeout, Islands-Pattern für Standort und Session)
State-akkumulierende User-Property-Snapshots, sodass Nutzer nie aus der Historie verschwinden
Eigenständige Dashboard-Analytics-Pipeline mit config_hash-Deduplizierung und Click-to-Order-Attribution (1h/24h/7d)
16 idempotente Backfill- und Migrationsskripte plus isolierte QA-Pipeline mit 13 automatisierten Validierungstests
Fünf eigene Looker-Studio-Community-Visualizations in Vanilla-JS (dscc) mit Light/Dark-Theming und GCS-Deployment
KI-Self-Service-Assistent (n8n + Claude) in Slack, self-hosted auf Cloud Run und Cloud SQL inklusive Deployment-Scripts

Stack

Eingesetzte Technologien

BigQuerySQLETLFirebase / GA4Looker StudioJavaScriptn8nAnthropic ClaudeCloud RunGCP

Ergebnis

Wirkung

Das Ergebnis ist eine automatisierte Analytics-Plattform, die die gesamte Wertschöpfungskette abdeckt: von der Rohdaten-Normalisierung über reproduzierbare, qualitätsgesicherte Pipelines bis zu Self-Service-Auswertung und KI-gestützter Datenabfrage.

Das Mandat wird seit 2022 langfristig und verlässlich betreut. Es zeigt End-to-End-Verantwortung über vier Säulen hinweg und einen hohen Automatisierungsgrad statt manueller Report-Arbeit.

Reflexion

Was ich heute anders entscheiden würde

Die Datenstand-Logik (T-2/T-3/T-4) würde ich heute von Anfang an strikter zwischen Code und Dokumentation synchron halten, damit Offsets über alle Schichten eindeutig nachvollziehbar bleiben.

Einzelne KPI-Konzepte wie die Verweildauer-Effizienz oder der Dashboard-Funnel sind bewusst als dokumentierte Konzepte stehen geblieben, bis die nötige Transaktions- und Screen-Flow-Integration verfügbar ist. Diese Trennung zwischen umgesetzten und konzeptionell vorbereiteten KPIs kommuniziere ich transparent.

Klingt nach einem Profil, das zu deinem Projekt passt?

Verfügbarkeit anfragen Weitere Projekte