- Problem
- Über Ausgaben für bezahlte Kundengewinnung wurde anhand von Zahlen entschieden, die in fünf getrennten Anbieter-Dashboards lagen und sich widersprachen.
- Ergebnis
- Ein Warehouse, fünf Quellen, in Schichten modelliert und im Fünfzehn-Minuten-Takt in die Dashboards geladen, die das Unternehmen tatsächlich öffnet.
- Meine Rolle
- Alleiniger Entwickler, über drei Monate, von den Grundlagen in Azure und Kubernetes bis zu den Dashboards.
- Stand
- In Produktion ausgeliefert und im Einsatz.
Das Problem
Der Kunde ist ein deutsches Finanzdienstleistungsunternehmen für Ärztinnen und Ärzte sowie andere Heilberufe: Beratung zur Praxisgründung, Finanzierung und Konten, wobei der Antrag online läuft und nicht am Schalter einer Filiale.
Dieses Geschäftsmodell legt ungewöhnlich viel Gewicht auf bezahlte Kundengewinnung. Wer als Ärztin oder Arzt entscheidet, wie eine Praxis finanziert wird, kauft nicht spontan und nicht in einer einzigen Sitzung, und zwischen einer Anfrage und tatsächlich ausgezahltem Geld liegen Wochen. Also betrieb das Marketing vier bezahlte Kanäle und eine Website, während die Finanzierungsseite Leads, Opportunities und gewonnene wie verlorene Abschlüsse in Salesforce führte.
Die beiden Hälften trafen nie aufeinander, und das ist die übliche Gestalt dieses Problems: Jede Werbeplattform meldet ihre eigenen Conversions, in ihrem eigenen Dashboard, gegen ihr eigenes Attributionsfenster, und jede beansprucht dieselbe Ärztin für sich. Salesforce wusste, welche Anträge tatsächlich abgeschlossen wurden, und wusste nichts darüber, was deren Gewinnung gekostet hatte. Die eigentlich wichtige Frage, welcher Kanal Kundschaft hervorbringt statt bloß Anfragen, hatte damit nirgends im Unternehmen eine Antwort.
Eine viel einfachere ebenso wenig. Wenn heute Morgen keine Anfragen mehr eingehen, liegt das am Markt, an der Kampagne oder an einem kaputten Formular.
Was gebaut wurde
Eine durchgängige Analyseplattform, von den Anbieter-APIs bis zu den Dashboards, die das Unternehmen tatsächlich öffnet. Airbyte, selbst betrieben auf Kubernetes, übernimmt Extraktion und Laden; Snowflake ist das Warehouse, mit nach Schichten getrennten Schemas und Rechten, die an Rollen statt an Personen hängen; dbt transformiert in Schichten und endet in Marts und einer semantischen Schicht; Tableau liest ausschließlich aus diesen Marts.
Die Salesforce-Seite umfasst Leads, Opportunities, gewonnene und verlorene Abschlüsse sowie Nutzer. Die Paid-Media-Seite umfasst Google Ads, LinkedIn Ads und Facebook Ads neben der Website-Aktivität, sodass Ausgaben und Ergebnis endlich in denselben Tabellen liegen und sich verknüpfen lassen.
Die gesamte Kette aktualisiert sich alle fünfzehn Minuten, inkrementell überall dort, wo dbt es zulässt, sodass die Dashboards den heutigen Morgen beschreiben und nicht den gestrigen Tag.
Die Verarbeitungskette
- dann
Quellen
CRM und bezahlte Werbung, jeweils mit eigener API und eigener Vorstellung davon, was eine Conversion ist.
- Salesforce
- Google Ads
- LinkedIn Ads
- Facebook Ads
- Website
- dann
Airbyte
Extraktion und Laden, selbst betrieben auf Kubernetes in der Azure-Umgebung des Kunden.
- dann
Snowflake
Das Warehouse. Schemas nach Schichten getrennt, Rechte an Rollen vergeben.
- dann
dbt
Transformation in Schichten, endend in Marts und einer semantischen Schicht.
- staging
- intermediate
- marts
- semantic layer
Tableau
Berichte, aktualisiert im Fünfzehn-Minuten-Takt.
Fünf Quellen, ein Warehouse, ein Satz Definitionen, alle fünfzehn Minuten aktualisiert. Die Form ist in einem bestimmten Punkt entscheidend: Nichts unterhalb von Snowflake spricht mit einer Anbieter-API, sodass eine Änderung am Attributionsfenster bei Google oder Meta keine Zahl in einem Vorstandsbericht unbemerkt verschieben kann.
Entscheidungen
Selbst betrieben, weil der Kunde seine Infrastruktur ohnehin selbst betrieb.
Airbyte bietet einen verwalteten Dienst an, und der wäre schneller aufgesetzt gewesen. Er wäre hier auch die falsche Antwort gewesen. Azure war vorhanden, ebenso eine Betriebshaltung, die Systeme in der eigenen Umgebung hält, und das ist im Finanzdienstleistungsbereich keine Geschmacksfrage. Der verwaltete Dienst hätte bedeutet, gleich im ersten Projekt eine Ausnahme von einer Regel zu erbitten, die es aus guten Gründen gibt, um ein paar Tage Einrichtung zu sparen. Der Eigenbetrieb auf ihrem Kubernetes kostete mehr von meiner Zeit und nichts von ihrem Vertrauen.
Jede Zahl in einem Bericht stammt aus dem Warehouse, nie aus einer Anbieter-API.
Nichts unterhalb von Snowflake spricht mit Google, Meta, LinkedIn oder Salesforce. Das klingt nach einem Implementierungsdetail und ist der Grund, warum man der Plattform trauen kann: Werbeplattformen ändern ihre Attributionsfenster und schreiben Vergangenes um, und ein Dashboard, das sie live abfragt, würde am Dienstag stillschweigend eine andere Zahl zeigen als am Montag, ohne dass irgendetwas im System sagen könnte, warum. Extrahierte Daten sind ein Beleg dafür, was der Anbieter zu dem Zeitpunkt gesagt hat, als er es gesagt hat.
Definitionen existieren einmal, in einer semantischen Schicht.
Ohne sie wird ein qualifizierter Lead in einem berechneten Feld in Tableau definiert, noch einmal in einem dbt-Modell und ein drittes Mal im Kopf derjenigen Person, die die Präsentation des letzten Quartals gebaut hat. Die drei widersprechen sich, der Widerspruch fällt in einer Besprechung auf statt in einem Code-Review, und die Diskussion dreht sich darum, wessen Zahl stimmt, statt darum, was zu tun ist. Die Definition an einer einzigen Stelle abzulegen, aus der alles andere liest, macht diese Art von Besprechung unmöglich.
Rechte werden an Rollen vergeben, nie an Personen.
Die Snowflake-Schemas trennen Rohdaten, transformierte Daten und Berichtsschicht, und die Rechte hängen an Rollen, die Personen innehaben, statt an den Personen selbst. Andersherum funktioniert es tadellos, bis die dritte Person dazukommt, und ab da kann niemand mehr sagen, wer was sehen darf, ohne jede Rechtevergabe einzeln zu lesen. Im Finanzdienstleistungsbereich ist das nicht bloß unordentlich.
Fünfzehn Minuten, nicht Echtzeit.
Streaming stand zur Verfügung und war es nicht wert. Nichts in diesem Trichter bewegt sich schneller als eine Viertelstunde, und der Preis für Echtzeit wird dauerhaft in Komplexität bezahlt. Fünfzehn Minuten wurden gewählt, weil das der Punkt ist, an dem ein Einbruch bei den Anfragen noch am selben Morgen sichtbar wird statt am nächsten Tag, und das erwies sich als wichtiger, als irgendjemand erwartet hatte.
Bewusst kein maschinelles Lernen.
Attribution ist genau das Problem, für das Menschen nach einem Modell greifen, und in diesem System steckt nirgends eines. Es war kein Vorhersageproblem, es war ein Definitions- und Verknüpfungsproblem: festlegen, was als Kontakt zählt, das mit dem Fachbereich abstimmen und es jedes Mal gleich berechnen. Ein Modell hätte eine Antwort geliefert, die niemand hätte prüfen können und die nicht wahrer gewesen wäre als die, die eine sorgfältige Verknüpfung liefert. Die interessante Ingenieursarbeit ist hier Data Engineering, nicht KI, und etwas anderes zu behaupten wäre der einfachste Weg gewesen, es schlechter zu machen.
Was dabei herauskam
Drei Monate, eine Person
Von nichts zu einer Plattform, auf der das Unternehmen läuft.
Alleiniger Entwickler über die gesamte Kette: das Kubernetes-Deployment, die Konnektoren, das Warehouse samt Sicherheitsmodell, jede dbt-Schicht und die Berichte darüber. Klar gesagt, weil es der ehrliche Umfang ist, und weil es zugleich die deutlichste Einschränkung der Bauweise ist. Siehe unten.
15 Minuten
Der Abstand zwischen einem Ereignis und dem Moment, in dem jemand es sehen kann.
Die gesamte Kette aktualisiert sich im Fünfzehn-Minuten-Takt, inkrementell überall dort, wo dbt es zulässt. Diese Zahl ist der Grund, warum die Plattform ein Problem entdeckt hat, nach dem niemand gesucht hatte: Die Anfragen brachen ein, der Einbruch war noch am selben Morgen sichtbar statt in einem Wochenbericht, und die Ursache lag an der Website und nicht am Markt. Den Ausschlag gab, dass beide Hälften des Bildes an einer Stelle lagen, nicht irgendetwas Raffiniertes.
Kein Modell
Das Schwierige war, sich zu einigen, was eine Zahl bedeutet, nicht sie vorherzusagen.
Vier Werbeplattformen mit einem CRM zu verknüpfen wird üblicherweise als Attributionsproblem beschrieben und als Modellierungsaufgabe behandelt. Hier war es ein Definitionsproblem. Sobald ein Kontakt, ein Lead und ein abgeschlossener Antrag jeweils einmal definiert und jedes Mal gleich berechnet wurden, beantwortete sich die Frage, welcher Kanal Kundschaft statt Anfragen hervorbringt, von selbst.
Was es nicht leistet
- Es arbeitet im Batch, nicht im Streaming. Fünfzehn Minuten sind die Untergrenze, und alles, was eine schnellere Antwort braucht, wird von dieser Plattform nicht bedient.
- Die Attribution folgt einer mit dem Fachbereich abgestimmten Regel, nicht einem Multi-Touch-Modell, das Anteile schätzt. Das macht sie prüfbar und diskutierbar statt raffiniert, was hier der richtige Kompromiss war und es nicht für jeden wäre.
- Die Daten fließen in eine Richtung. Erkenntnisse landen in Tableau und wandern nicht nach Salesforce zurück, sodass niemand, der im CRM an einem Lead arbeitet, sieht, was das Warehouse über ihn weiß.
- Eigenbetrieb ist ein laufender Aufwand, der in Aufmerksamkeit bezahlt wird. Der Cluster, die Konnektoren und deren Aktualisierungen sind echte fortlaufende Arbeit, bewusst gegen Kontrolle eingetauscht. Ein verwalteter Dienst verlagert diese Arbeit zu jemand anderem und die Daten aus der eigenen Umgebung heraus.
- Die Pipeline ist nur so stabil wie die APIs darunter. Wenn ein Anbieter einen Endpunkt ändert oder ein Werbekonto umgebaut wird, braucht ein Konnektor Pflege, und das ist kein Ereignis, das man planen kann.
- Gebaut wurde sie von einer Person in drei Monaten, was schnell ist und zugleich bedeutet, dass der Bus-Faktor während des Baus bei eins lag. Alles liegt in Code und unter Versionskontrolle statt in einem Notebook oder einer Konsole, das ist die Absicherung, aber es ist nicht dasselbe wie ein zweiter Entwickler.
Wo es steht
In Produktion ausgeliefert und im Einsatz. 2025 allein über drei Monate gebaut, von den Grundlagen in Azure und Kubernetes bis zu den Dashboards, die das Unternehmen öffnet.
Es steckt weder KI noch maschinelles Lernen darin. Es ist Data Engineering, Analytics Engineering und Business Intelligence, und genau das hat das Problem verlangt.