Server-Side Tracking

Messen, was zählt.
Serverseitig.

Messlücken reduzieren. Einwilligungen respektieren. Wir planen die Messung vom Browser bis ins Zielsystem und schreiben auf, welche Ereignisse ankommen und welche nicht. Denn Browserregeln, abgelehnte Einwilligungen und fehlende Ereignisse bleiben Grenzen, egal wie gut die Architektur ist.

Tracking prüfen Arbeiten ansehen

Der Endpunkt gehört zu Ihrer Website

Der Browser schickt erlaubte Ereignisse zuerst an einen Endpunkt auf Ihrer eigenen Domain. Dort werden sie verarbeitet und an die vereinbarten Zielsysteme weitergegeben. Serverseitig gesetzte Cookies gibt es nur im vereinbarten Umfang und passend zur Einwilligung.

Das ist eine saubere Schnittstelle zwischen Website und Datenanbietern, mit dokumentierten Regeln. Vollständig wird die Messung damit nicht: Browser begrenzen weiter, Einwilligungen fehlen, manche Interaktion erreicht den Endpunkt nie.

Von der Einwilligung bis zum Zielsystem

Die Einwilligung wird im Browser erfasst und vor dem Versand ausgewertet. Der First-Party-Endpunkt leitet erlaubte Ereignisse an den Server-Container. Dort werden die Signale erneut geprüft und für GA4, Google Ads, Meta CAPI oder LinkedIn CAPI aufbereitet.

Azure Front Door oder Cloudflare Workers können den Endpunkt ausliefern oder weiterleiten. Die tatsächliche Laufzeit des Server-Containers weisen wir in der Architektur getrennt aus.

Was wir im Tracking prüfen

Wir verfolgen ein ausgewähltes Ereignis vom ersten Aufruf bis zum Zielsystem. Dabei trennen wir technische Übertragung, Einwilligung und fachliche Bedeutung.

Consent Mode v2Wir prüfen ad_storage, analytics_storage, ad_user_data und ad_personalization. Dazu gehören die Reihenfolge der Initialisierung, asynchrone Aktualisierungen, wait_for_update, die region-Konfiguration sowie Basic und Advanced Consent Mode. Ziele außerhalb von Google prüfen wir getrennt.

Conversion APIsWir prüfen die Übertragung an Google Ads, Meta CAPI und LinkedIn CAPI. Wenn Standard-Tags nicht ausreichen, entwickeln und prüfen wir sandbox-kompatible Vorlagen für den Server-Container.

Zuordnung in SPAsWir verfolgen den ersten Kampagnenkontakt und spätere Routenwechsel. Erlaubte Click-IDs werden einwilligungsabhängig gespeichert. Tag-Reihenfolge und Deduplizierung verhindern eine falsche Zuordnung.

Ereignisse mit BedeutungEin technisch gesendetes Ereignis ist noch keine belastbare Kennzahl. Wir gleichen Namen, Auslöser, Parameter und Zielsysteme mit der fachlichen Definition ab.

Serverlogs und Browser messen andere Dinge

Ein Matomo-Import aus Serverlogs wertet Anfragen aus, die den Server oder die Edge erreicht haben. Er kann ohne Browser-Skript und Tracking-Cookie auskommen. Klicks oder Formularschritte, die keine protokollierte Anfrage erzeugen, bleiben jedoch unsichtbar.

Browserbasiertes Tracking kann solche Interaktionen erfassen. Es bleibt von Einwilligung, Browserregeln und der korrekten Ausführung der Tags abhängig. Keine der beiden Architekturen belegt für sich die Datenschutzkonformität. Datenminimierung, Rechtsgrundlage, Aufbewahrung und Zugriffe müssen passend zum Vorhaben festgelegt werden.

Tracking wird wie Code behandelt

Wir exportieren Containerstände und legen sie versioniert ab. Änderungen werden als Unterschied sichtbar und vor der Veröffentlichung geprüft. Die freigegebene Fassung lässt sich so einem Release zuordnen.

Zur Prüfung gehören Vorschau, Testereignisse und der Abgleich im Zielsystem. Tokens, interne Kennungen und Nutzdaten bleiben außerhalb der Exporte und der öffentlichen Dokumentation.

Für iF Design umgesetzt

Für iF Design haben wir Server-Side Tracking über einen First-Party-Endpunkt und einen Server-Container umgesetzt. Die Architektur verbindet Consent Mode, SPA-Zuordnung und Conversion APIs. Für Anforderungen außerhalb der Standard-Tags kommt eine sandbox-kompatible Vorlage zum Einsatz. Containerstände werden versioniert und vor der Veröffentlichung geprüft.

Auslieferung an der Edge

Der Tracking-Endpunkt ist Teil der Plattformarchitektur. Wie Azure Front Door und Cloudflare Workers Routing, Schutz und Auslieferung übernehmen, beschreiben die jeweiligen Leistungsseiten.

Azure Front DoorRouting, WAF, Caching und TLS für Anwendungen auf Microsoft Azure.

Cloudflare WorkersCode und Weiterleitung an der Edge mit Cloudflare.

Das Ergebnis des Tracking-Checks

Im Gespräch klären wir die Aufgabe. Ein anschließendes Angebot legt Stichprobe, benötigte Zugänge, Ergebnisse und Kosten fest.

Dokumentierter FlussSie erhalten den Event- und Consent-Fluss mit Messbedingungen, Systemgrenzen und nicht verfügbaren Nachweisen.

Priorisierte MesslückenWir ordnen Lücken nach ihrer Wirkung auf Zuordnung, Einwilligung und fachliche Auswertung.

Prüfbare SchritteFür die vereinbarten Ereignisse dokumentieren wir Testdaten, erwartete Signale und die Prüfung in jedem beteiligten System.

Nächste MaßnahmenSie erhalten Empfehlungen, Aufwandsschätzungen und Kriterien für die Verifikation. Wo eine Umsetzung sinnvoll ist, grenzen wir sie in einem Angebot ab.