Der Dashflow Messansatz: Warum die Customer Journey auf den Server gehört

Eine Customer Journey muss die Lücke zwischen dem ersten Ad-Klick und einem Abschluss überstehen, der Monate später erfolgt. Werbeplattformen kennen den Klick, das CRM kennt den Umsatz. Zwischen diesen beiden Datensätzen liegt ein Identitätsproblem, und die Art, wie ein Setup es löst, entscheidet über fast alles Weitere: wie viele Daten Ad-Blocker überstehen, wie lange Attribution in Safari hält, ob Traffic ohne Conversion überhaupt sichtbar ist und wie viele Offline-Conversions sich den Werbeplattformen wieder zuordnen lassen.

Dafür gibt es zwei architektonische Antworten. Entweder liegt die Journey im Browser und wird im Moment des Formularabsendens übergeben, oder sie wird bei jeder Interaktion serverseitig erfasst und erst danach mit dem CRM-Datensatz verknüpft. Dieser Beitrag beschreibt den zweiten Weg, so wie Dashflow ihn umsetzt, und vergleicht ihn mit einem sauber gebauten Beispiel für den ersten: der Open-Source-Bibliothek Intake.

1. Der Ansatz: alles erfassen, serverseitig

Im Zentrum steht die Datenqualität: so viel wie möglich messen, die Erfassung auf den Server verlagern und am Ende eine Multi-Touch-Attribution haben, die mit CRM-Ergebnissen verbunden ist. Drei Mechaniken tragen das.

Die _ga-Cookie-ID wird zur Dimension. GA4 (Google Analytics 4) speichert eine anonyme Client-ID im _ga-Cookie. Wir schreiben diesen Wert in eine nutzerbezogene GA4 Custom Dimension. Damit trägt jedes Event, das GA4 aufzeichnet, diese Kennung. Das Ergebnis ist die vollständige Interaktionshistorie pro anonymem Besucher, nicht deren Zusammenfassung.

Click-IDs werden an dieselbe Kennung gebunden. Click-IDs der Werbeplattformen wie gclid und fbclid laufen ebenfalls in Custom Dimensions, verknüpft mit demselben _ga-Wert. Da jeder Klick als eigenes Event ankommt, bleibt die komplette Click-ID-Historie eines Besuchers erhalten. Setups, die nur die jüngste Click-ID behalten, können damit die letzte Anzeigeninteraktion bespielen; eine vollständige Historie bespielt alle.

Alles läuft über Server-Side Tagging. Wir setzen einen serverseitigen Google Tag Manager (sGTM) über Stape auf einer eigenen First-Party-Subdomain auf. Diese eine Entscheidung löst drei Probleme gleichzeitig:

• Ad-Blocker. Requests gehen an eine First-Party-Subdomain statt an einen bekannten Tracking-Endpunkt. Die Events werden also nicht mehr aussortiert, bevor sie überhaupt gesendet werden.
• Cookie-Vergabe. Cookies kommen über Set-Cookie-Response-Header vom Server und nicht mehr aus JavaScript. Genau an diesem Unterschied setzen die Privacy-Mechanismen der Browser an.
• Cookie-Laufzeit. Serverseitig gesetzte Cookies halten ein Jahr und länger, statt der sieben Tage, die Intelligent Tracking Prevention (ITP) einem per Skript gesetzten Cookie zugesteht.

Die technischen Hintergründe dazu stehen im Beitrag über Server-Side Tracking für zuverlässige Datenerfassung.

2. Warum GA4 als Datenbank dient

Ein Analytics-Produkt als Datenspeicher zu nutzen, wirkt ungewöhnlich, bis die Alternativen durchgerechnet sind. Die Begründung:

• Time to Value. GA4-Daten kommen über eine REST-API. Das Reporting startet wenige Tage nach der Tracking-Anpassung und nicht nach einem Warehouse-Projekt.
• Die Session-Logik existiert bereits und passt zum Interface. GA4-Sessions sind definiert, dokumentiert und identisch mit dem, was ein Marketing-Team in den GA4-Berichten sieht. Wer die Session-Logik auf Rohdaten-Exporten neu baut, produziert Zahlen, die dem Interface widersprechen, und jede Abweichung wird zum Meeting.
• Tagesgenaue Auflösung deckt rund 95 % der Fragen im Marketing Measurement ab. Budgetverteilung, Kanalbeitrag und CAC je Kampagne brauchen keine stündliche Granularität.
• Der BigQuery-Export fehlt oft oder ist unvollständig. Die Informationen stecken zwar im Export, aber viele Unternehmen haben ihn nie aktiviert, nicht synchronisiert oder ohne historischen Backfill laufen. Das ist zusätzliche Aufbauzeit, bevor die erste Erkenntnis entsteht.
• Kein zweiter Tracking-Stack, der bezahlt werden muss. GA4, GTM und CRM sind in fast jedem Unternehmen bereits vorhanden. Eine zusätzliche Customer Data Platform für ein Identitätsproblem bedeutet, Infrastruktur zu finanzieren und zu betreiben, die vorhandene Systeme dupliziert.

Verarbeitung, Mapping und Modellierung passieren anschliessend in unserem Backend, wo sie sich ändern lassen, ohne das Tracking anzufassen.

3. Setup in drei Schritten

Die Umsetzung ist bewusst klein gehalten, denn jedes zusätzliche bewegliche Teil ist ein Teil, das beim nächsten Website-Relaunch bricht.

1. Eine nutzerbezogene Custom Dimension in GA4 anlegen, zum Beispiel user_id, uid oder ga4_id. Der Scope muss auf User stehen, nicht auf Event.
2. Das JavaScript über den GTM ausspielen. Ein Custom-HTML-Tag liest das _ga-Cookie und schreibt es in den dataLayer, ausgelöst per Tag-Sequencing nach dem GA4-Konfigurationstag. Weil der Tag erst nach dem GA4-Tag feuert, bleibt die Erfassung innerhalb der bestehenden Consent-Logik. Die Tracking-Anleitung dokumentiert Tag, Trigger und Variable.
3. Dieselbe ID ins CRM schreiben. Ein verstecktes Formularfeld, zum Beispiel ga4_id in einem HubSpot-Formular, übernimmt den Cookie-Wert beim Absenden. Ein Workflow kopiert die Property anschliessend vom Kontakt auf den Deal. Die CRM-Anleitung enthält ein Beispielskript, das sowohl Legacy-Formulare als auch mehrstufige iFrame-Formulare abdeckt.

Parallel dazu wird das Server-Side Tagging eingerichtet, entlang der Stape-Anleitung.

4. Was die Pipeline daraus macht

Nach diesen drei Schritten läuft die Verknüpfung automatisch. Dashflow-Pipelines führen Webtraffic, Kanal- und Kostendaten sowie CRM-Einträge in einem Datensatz zusammen, bauen darauf Attributionsmodelle und schreiben das Ergebnis als flache Parquet-Tabellen in den Blob Storage. Jedes BI-Tool, das Parquet lesen kann, also Power BI, Tableau, Qlik oder Metabase, greift direkt darauf zu. Die Felder sind in der öffentlichen Datenmodell-Dokumentation beschrieben.

5. Wie Identity Resolution funktioniert

Die Zuordnung von Cookie zu CRM-Datensatz scheitert in zwei Richtungen, und beide kommen in normalem Traffic vor.

Eine Person kann mehrere Formulare mit unterschiedlichen E-Mail-Adressen oder Telefonnummern absenden, wodurch für einen einzigen Menschen mehrere CRM-Datensätze entstehen. Dieselbe Person kann ausserdem mehrere _ga-IDs tragen, etwa durch ein zweites Gerät, einen geleerten Browser oder eine abgelaufene Safari-Session.

Ein einzelner Join-Key löst keinen der beiden Fälle. Die Dashflow-Pipeline matcht bidirektional: CRM-Datensätze werden über Kennungen hinweg zusammengeführt und Kennungen über CRM-Datensätze hinweg. Eine Journey über zwei Geräte und zwei Formularabsendungen fällt damit zu einem Kunden zusammen.

6. Die clientseitige Alternative: wie Intake.js funktioniert

Intake ist eine Open-Source-JavaScript-Bibliothek für Quellenerkennung und Attribution, rund 14 kB gzipped und ohne Runtime-Abhängigkeiten, ausgeliefert als UMD-, ESM- und GTM-kompatibler Build. Sie erkennt UTM-Parameter, organische Suche, Referral und Direkteinstiege, erfasst 11 Click-IDs, pflegt eine Touchpoint-Kette für First-, Last-, lineare, U-förmige und zeitverfallende Attribution, berücksichtigt Signale des Consent Mode v2 und schreibt die erfassten Werte beim Absenden in versteckte Formularfelder. Auch die GA4-Client-ID liest sie aus dem _ga-Cookie in den eigenen Speicher.

Für eine kleine Website ohne Server-Infrastruktur, mit kurzem Sales-Zyklus und dem Bedarf, Attribution noch diese Woche auszurollen, ist dieses Design eine sinnvolle Wahl und sauber umgesetzt.

Die Grenzen sind Folgen der Architektur und keine Mängel der Umsetzung. Das Projekt dokumentiert sie offen in seinem Limitations-Guide. Ein Cookie fasst rund 4 KB, deshalb ist die Touchpoint-Kette auf 50 Touchpoints begrenzt. Click-IDs werden mit einem Wert pro Parameter gespeichert und bei jedem Seitenaufruf aus der URL zusammengeführt, eine zweite gclid überschreibt also die erste. Cookies werden über document.cookie gesetzt, und Safari kürzt solche Cookies per Intelligent Tracking Prevention auf sieben Tage, unabhängig von der halbjährigen Laufzeit, die die Bibliothek anfordert. Gesetzt werden sie ohne explizites SameSite-Attribut, worauf die Dokumentation mit Blick auf iFrames hinweist. Und wird Consent verweigert, entstehen gar keine Cookies: Die Attribution fällt auf Parameter-Weitergabe per URL innerhalb einer einzelnen Session zurück.

Der tiefere Unterschied liegt nicht darin, was erfasst wird, sondern wann es den Browser verlässt. Intake erfasst die GA4-Client-ID ebenfalls, doch der Wert bleibt im Cookie liegen, bis ein Formularabsenden ihn hinausträgt. Alles, was ein Besucher vor der Conversion tut, und alles, was ein Besucher ohne Conversion tut, bleibt im Browser und verschwindet mit ihm.

7. Direkter Vergleich

Vergleichsdimension	Intake (clientseitig)	Dashflow (serverseitiges GA4 + Stape)
Architektur	Clientseitige JavaScript-Bibliothek (~14 kB) im Browser des Nutzers	Serverseitiger GTM über Stape-Proxy, der das _ga-Cookie bei jeder Interaktion erfasst
Robustheit gegen Ad-Blocker	Anfällig; Skript-Requests und Parameter werden häufig blockiert	Robust; Daten laufen über eigene First-Party-Subdomains
Cookie-Laufzeit (Safari ITP)	Sechs Monate per Konfiguration, von Safari ITP auf sieben Tage gekürzt	Ein Jahr und länger über serverseitige Set-Cookie-Response-Header
Touchpoint-Speicherung	Auf 50 Touchpoints im Browser-Speicher begrenzt	Unbegrenzte Historie, da das _ga-Cookie bei jeder Interaktion in eine GA4 Custom Dimension geschrieben wird
Erfassung von Click-IDs (gclid, fbclid)	Ein Wert pro Parameter, vom nächsten Klick überschrieben	Jede historische Click-ID pro Nutzer erfasst und in einer GA4 Custom Dimension mit _ga verknüpft
Cross-Domain und iFrames	Durch Cross-Origin-Isolation des DOM eingeschränkt	Der native GA4-Linker dekoriert URLs und erhält _ga über iFrame-Grenzen hinweg
HubSpot-Anbindung	Erfasst die GA4-Client-ID ebenfalls, übergibt sie aber erst beim Formularabsenden über versteckte Felder	Schreibt die unveränderliche _ga-ID in den HubSpot-Datensatz für den automatisierten Abgleich im Backend
Journey-Sichtbarkeit ohne Conversion	Blind für Nicht-Konverter: Daten verlassen den Browser erst bei der Conversion, ein Vergleich von Konvertern und Nicht-Konvertern ist nicht möglich	Volle Sichtbarkeit: Jede Interaktion wird mit dem _ga-Cookie gestreamt, für Konverter wie für Nicht-Konverter
Offline-Conversions und CAPI-Matching	Verliert Conversion-Signale, sobald der Sales-Zyklus länger dauert als das Cookie überlebt	Hohe Match-Rate; die vollständige Click-ID-Historie speist Conversions API und Conversion Uploads
Systemabhängigkeit	Abhängig von DOM-Verfügbarkeit und Skriptausführung im Client	Abhängig von der Stabilität des Server-Proxys und der Backend-Pipeline

8. Wann eine CDP oder ein eigenes Tool die bessere Antwort ist

Dieser Ansatz taugt nicht für jeden Fall. Eine Customer Data Platform oder ein eigener Warehouse-Aufbau rechnet sich, wenn:

• Time to Value keine Rolle spielt und ein Projekt über mehrere Quartale akzeptabel ist.
• ein internes Data-Science- oder Data-Engineering-Team existiert, das die Pipelines dauerhaft betreibt.
• Granularität auf Intraday- oder Event-Ebene tatsächlich gebraucht wird und nicht nur wünschenswert ist.
• rohe Event-Historie über das GA4-Aufbewahrungsfenster hinaus benötigt wird.
• Quellen ausserhalb des Web-Stacks zusammengeführt werden müssen: App-SDKs, Kassensysteme, Produkttelemetrie, Offline-Events.
• ein deterministischer Identity Graph über Logins, mehrere Domains und Apps hinweg gefordert ist.
• Anforderungen an Datenstandort oder Compliance GA4 vollständig ausschliessen.
• das Traffic-Volumen so hoch ist, dass Kardinalitäts- und Sampling-Grenzen in GA4 greifen.

Trifft nichts davon zu, enthält der bestehende Stack bereits alle Bausteine, um vollständige Journeys zu messen.

9. Fazit

Clientseitige Bibliotheken und serverseitige Erfassung lösen dasselbe Problem an unterschiedlichen Stellen des Datenflusses, und diese Stelle bestimmt die Obergrenze. Eine Journey im Browser ist dadurch begrenzt, was ein Browser zu behalten bereit ist, und dieser Spielraum schrumpft mit jedem Privacy-Release. Eine serverseitig erfasste Journey ist durch die Qualität der Pipeline begrenzt, und die lässt sich tatsächlich steuern.

Für die meisten mittelgrossen Unternehmen sieht die praktische Variante unspektakulär aus: eine Custom Dimension, ein GTM-Tag, ein verstecktes CRM-Feld und eine Pipeline, die das Ergebnis mit dem Umsatz verbindet.

Nächste Schritte

• Die Erfassungsmethoden im Detail: Server-Side Tracking für zuverlässige Datenerfassung.
• Das umfassendere Vorgehen: Customer Journey von Klicks bis ROI ohne neues Tool messen.
• Ergebnisse aus der Praxis in unseren Case Studies.
• Den eigenen Stack mit unserem Team besprechen: Strategiegespräch buchen.