Tracking-Setup: So implementierst du sauberes Tracking

Ein sauberes Tracking-Setup hat vier Bausteine: Consent vor jeder Erhebung, einen vom Produkt verantworteten Data Layer, eine bewusste Ownership-Entscheidung zwischen client- und serverseitiger Erfassung — und kontinuierliche Qualitätsmessung statt einmaliger Implementierung. Der schwerste Teil ist dabei nicht der Aufbau: „Es ist so viel schwieriger, ein gutes Setup über längere Zeit aufrechtzuerhalten, als initial ein gutes Setup hinzustellen", sagt Christian Ebernickel, der als Product Owner das globale Tracking-Setup von Miele X verantwortet hat, in der ausführlichsten Tracking-Folge meines Podcasts.

Dieser Guide fasst zusammen, was aus dieser Folge und den Consent-, Cookieless- und Analytics-Gesprächen aus über 330 MDIBTY-Folgen für die Praxis hängen bleibt — inklusive der Fehler, die richtig Geld kosten.

Erst die Business-Frage, dann das Tag

Der Grundsatz, an dem die meisten Setups schon scheitern, bevor ein Tag gefeuert hat: „Daten an sich haben keinerlei Wert — es geht darum, was ich mit den Daten anfange und ob ich anhand der Nutzung einen Vorteil für mein Business erzielen kann. Wenn ich das nicht nachweisen kann, brauche ich die Daten nicht" (Ebernickel). Sauber implementieren heißt deshalb zuerst: definieren, wer welche Parameter wofür auswertet — „Implementierung bedeutet, ich messe die angeforderten Parameter für mein Business", wie es Till B. von DHL schon in einer der frühesten Folgen formuliert hat (zur Folge).

Die Kehrseite ist Überinstrumentierung — und die ist nicht harmlos: „Wenn am Ende keiner die Daten benutzt und wenn die Daten sogar den Analysten den Blick darauf verstellen, was wirklich relevant ist, dann sind diese zu viel erhobenen Daten sogar schädlich." Historisch kommt genau daher der Ballast vieler Setups; Julian L. P. von Tealium beschreibt die Anfangsjahre so: Die große Herausforderung war damals nicht Qualität, „sondern mehr Daten zu erfassen. Wir waren datenhungrig." (zur Folge) Dieser Datenhunger ist heute der Grund, warum Projekte scheitern: „Die Datenqualität war nicht gut, die Daten sind in Silos, wir wissen nicht, wo wir sie herkriegen."

Consent-first: keine Einwilligung, keine Aktivierung

Consent ist kein Banner-Thema, sondern die Grundlage der gesamten Datennutzung. Die Tealium-Folge bringt es unmissverständlich auf den Punkt: „Jedes Unternehmen braucht eine Einwilligung, um Profiling machen zu dürfen. Punkt." Und die operative Konsequenz: „Wenn du vorne rechtlich die Einwilligung nicht eingeholt hast, hast du nicht die Möglichkeit, deine Daten zu aktivieren." Jede Personalisierung, jedes Audience-Matching, jede Kampagnenlogik hängt an diesem ersten Schritt.

Wichtig ist die Reihenfolge: Consent-Architektur zuerst, Quick-Fixes danach. Sarah S. von Penguin Random House beschreibt die richtige Haltung gegenüber schnellen Pflastern wie dem Google Consent Mode: „Das könnte ich tun. Aber das ist eine kurzfristige Lösung" — die eigentliche Aufgabe ist „ein Setup, das mir erlaubt, meine eigenen Daten selbst zu verwalten und selbst zu kontrollieren" (zur Live-Folge). Und ja, die Branche hat das Aufschieben perfektioniert — mein eigenes Learning aus der DSGVO-Zeit: „Fünf Jahre haben wir gesagt, der Cookie-Banner muss kommen. Und dann waren ab dem Ersten plötzlich alle überrascht."

Serverseitig vs. clientseitig: die Ownership-Frage

Der Status quo ist unbequem: „In weit über 90 Prozent der Fälle sprechen wir davon, dass Tracking-Technologie eingesetzt wird, die von Dritten stammt, die das Unternehmen nicht selber ownt — und die meistens auch noch von Unternehmen stammt, die selber Werbenetzwerke betreiben" (Ebernickel). Clientseitig heißt: „Wir laden im Grunde fremden Code in unsere Website, der in den Browsern unserer Nutzerinnen und Nutzer läuft, ohne dass wir richtig kontrollieren können, was das Zeug da macht."

Wie teuer dieser Kontrollverlust werden kann, zeigt ein belegter Fall aus der Folge: Beim Meta-Pixel lässt sich „Automatic Advanced Matching" ohne Admin-Zugriff aktivieren — „dann fängt das Tag selbstständig an, zusätzliche First-Party-Daten wie Namen, Adressen, E-Mail-Adressen zu erfassen und an Meta zu senden." Die schwedische Avanza-Bank kassierte dafür umgerechnet 1,3 Millionen Euro Bußgeld, eine Online-Apotheke sogar über 3 Millionen.

Die serverseitige Antwort: „Ich kann das erstmal an einen Endpunkt senden, an einen sogenannten Tagging-Server bei mir selber — und von dort entscheiden, wer eigentlich welche Daten kriegt." Genau das ist der Ownership-Gewinn: Daten lassen sich „gezielt von der Weitergabe an Meta ausschließen, was du bei einem clientseitigen Meta-Tracking kaum machen kannst." Aber — und diese Ehrlichkeit unterscheidet Praktiker von Prospekten — Server-Side ist kein Selbstläufer: „Es wäre naiv zu glauben, ich kann einfach alles serverseitig migrieren und dann läuft das schon." Manche Werbefunktionen wie Lookalike Audiences brauchen weiterhin clientseitige Tags; der pragmatische Zwischenschritt ist oft das GA4-Tag über einen eigenen Tagging-Server. Und selbst dann gilt: „Wenn ich an Google Analytics weitersende — ich owne die Daten nicht so richtig. Ich nutze sie nur."

Datenqualität: der Data Layer gehört dem Produkt

Der stille Killer vieler Setups ist organisatorisch: Niemand fühlt sich für die Datenschicht zuständig. Till B. hat das Problem früh benannt: „Die meisten Product Owner da draußen sind sich wahrscheinlich nicht mal dessen bewusst, dass ihr Produkt sowas wie einen Data Layer braucht, damit der Analyst damit arbeiten kann." Meine These dazu, damals wie heute: Der Data Layer ist Teil des Produkts — wer das Feature baut, liefert die Datenschicht mit, sonst bricht das Tracking bei jedem Release.

Dazu gehört Messung der Messung: kontinuierliche Datenqualitätsprüfung statt „einmal implementiert, läuft schon". Meine drei Implementierungs-Punkte aus der DHL-Folge: sauber planen, Datenqualität kontinuierlich messen, aufs Wesentliche fokussieren — nicht verzetteln.

Die typischen Fehler im Überblick

• Tags sammeln statt Fragen beantworten. Jeder Parameter ohne Auswerter ist Ballast — im Audit-Alltag führt das zu dem, was Ebernickel unverblümt „Schrott-Setups" nennt.
• Consent als Banner-Projekt behandeln. Ohne saubere Einwilligung ist jede nachgelagerte Aktivierung blockiert — rechtlich und technisch.
• Dritt-Tags blind vertrauen. Funktionen wie Advanced Matching ändern das Verhalten eines Tags ohne Code-Änderung — regelmäßige Tag-Audits gehören zum Betrieb.
• Server-Side als Wundermittel verkaufen. Ownership ja, aber mit klaren Grenzen — Migrationsplan pro Anwendungsfall statt Big Bang.
• Data Layer ohne Owner. Wenn die Datenschicht niemandem gehört, bricht sie beim nächsten Release — der Product Owner ist zuständig, nicht „das Analytics-Team irgendwann".
• Setup als Projekt statt als Betrieb. Der schwierige Teil beginnt nach dem Go-live: Monitoring, Qualitätsmessung, Änderungsprozesse.

Häufige Fragen