English
Deutsch
PolskiTag-Management-Systeme: Von der Hardcodierung zum Server-Side-Betrieb und zur Wahl des Anbieters
Inhalt
Wer heute im digitalen Marketing oder in der Datenanalyse arbeitet, nutzt wahrscheinlich täglich ein Tag Management System (TMS). Aber es war nicht immer so einfach. Um die Leistungsfähigkeit moderner Plattformen wie Google Tag Manager, Tealium oder Jentis wirklich zu verstehen, müssen wir uns die Anfänge der Datenerfassung ansehen.
Die Anfangszeit: Die Ära des Hardcodings
In den frühen 2000er Jahren musste ein Marketing-Team jedes Mal, wenn es ein Tracking-Pixel (wie Google Analytics oder ein Affiliate-Skript) auf einer Website platzieren wollte, ein Ticket an die IT-Abteilung schreiben. Entwickler mussten diese JavaScript-Snippets manuell direkt in den Quellcode der Website “hardcoden”.
Dieser Prozess war langsam, fehleranfällig und extrem abhängig von den Release-Zyklen der IT. Mit dem Boom des digitalen Marketings wurden Websites mit Dutzenden von Drittanbieter-Skripten überladen, was die Ladezeiten drastisch verschlechterte und das Datenmanagement zum Albtraum machte.
Die Evolution: Die Geburt des TMS
Zwischen 2008 und 2012 entstanden die ersten Tag Management Systeme (Tealium wurde 2008 gegründet, GTM startete 2012). Ein TMS lieferte einen einzigen “Container”-Code, der nur einmal auf der Website platziert wurde. Von da an konnten Marketer Tags über eine benutzerfreundliche Web-Oberfläche implementieren und verwalten, ohne den Code der Website jemals wieder berühren zu müssen.
Heute durchläuft die Branche einen weiteren massiven Wandel: Serverseitiges Tracking (Server-Side Tracking, SST). Aufgrund von Adblockern, Datenschutzgesetzen (DSGVO) und Intelligent Tracking Prevention (ITP) in Browsern gehen beim klassischen Client-Side-Tracking massiv Daten verloren. TMS-Plattformen entwickeln sich weiter, um Daten über einen eigenen Server (First-Party) zu leiten, bevor sie an Anbieter gesendet werden.
Werfen wir einen Blick auf die größten Marktteilnehmer.
Die Big Player im Tag Management
1. Google Tag Manager (GTM)
Der unangefochtene Marktführer, vor allem, weil seine Standardversion völlig kostenlos ist und sich nahtlos in das Google-Ökosystem integriert.
- PROs: Kostenlos, riesige Community, endlose Tutorials, extrem benutzerfreundlich für Anfänger.
- CONs: Der kostenlosen Version fehlen Enterprise-SLAs. Die Daten fließen direkt in das Google-Ökosystem, was bei einigen Unternehmen Bedenken hinsichtlich des Datenschutzes (DSGVO) aufwirft.
- Server-Side Tracking: Verfügbar (sGTM). Die Einrichtung über die Google Cloud ist relativ machbar, erfordert aber technisches Wissen, um Client-Side-Daten an den Server zu mappen.
- Wann wählen: Wenn der Marketing-Stack stark von Google (GA4, Google Ads) abhängt und eine schnelle, kostengünstige Lösung gefragt ist.
2. Tealium (Tealium iQ)
Ein Pionier und Schwergewicht im Enterprise-Bereich. Tealium wurde für riesige Konzerne mit komplexen Multi-Brand-Datenarchitekturen entwickelt.
- PROs: Unglaublicher Tag-Marktplatz (über 1000 native Integrationen), exzellente Data Governance und eine äußerst stabile Umgebung.
- CONs: Sehr teuer. Die Benutzeroberfläche ist hochgradig technisch und die Lernkurve ist steil.
- Server-Side Tracking: Exzellent. Tealium EventStream bewältigt serverseitiges Daten-Routing fehlerfrei, erfordert aber Entwicklerkenntnisse.
- Wann wählen: Für ein Großunternehmen mit hohem Budget, das Daten an Hunderte von Nicht-Google-Anbietern senden muss.
3. Adobe Experience Platform (Tags / ehemals Adobe Launch)
Adobes Antwort auf Tag Management, tief integriert in die Adobe Experience Cloud.
- PROs: Tiefe, native Integration mit Adobe Analytics, Adobe Target und AEM.
- CONs: Die Benutzeroberfläche ist im Vergleich zu GTM eher klobig. Völliger “Overkill” ohne weitere Adobe-Produkte im Einsatz.
- Server-Side Tracking: Wird über das Adobe Edge Network (Event Forwarding) realisiert. Hochleistungsfähig, aber in der Implementierung sehr komplex.
- Wann wählen: Ausschließlich, wenn das digitale Ökosystem des Unternehmens vollständig auf der Adobe Experience Cloud aufbaut.
4. Commanders Act (ehemals TagCommander)
Ein europäischer Anbieter, der stark auf DSGVO-Konformität und Consent Management fokussiert ist.
- PROs: Entwickelt mit Blick auf europäische Datenschutzgesetze. Kombiniert nahtlos Consent Management (CMP) mit Tag Management.
- CONs: Geringere weltweite Verbreitung, was eine kleinere Community und weniger Tutorials bedeutet.
- Server-Side Tracking: Solide native serverseitige Funktionen. Die Implementierung ist mittelschwer.
- Wann wählen: Für ein europäisches Unternehmen, dem DSGVO-Konformität, Datensouveränität und strenges Consent Management oberste Priorität sind.
5. Jentis (Der Innovator)
Jentis ist ein österreichisches Technologieunternehmen, das Tag Management völlig anders angegangen ist. Anstatt ein Client-Side-TMS zu nehmen und später Server-Funktionen hinzuzufügen, wurde Jentis von Grund auf als native Plattform für Server-Side Tracking entwickelt.
- PROs: Ultimative Datenqualität, integrierte Rechtssicherheit (DSGVO) und extreme Performance-Vorteile, da kaum noch JavaScript im Browser des Nutzers ausgeführt wird.
- CONs: Erfordert einen kompletten Paradigmenwechsel. Es ist ein Premiumprodukt, das den Abschied von “Client-Side”-Gewohnheiten verlangt.
- Server-Side Tracking: Ist das Herzstück des Produkts. Die Implementierung ist stark optimiert und deutlich einfacher als der Bau eigener GTM-Server.
Das Feature “Synthetic Users” (Synthetische Nutzer) von Jentis: Hier glänzt Jentis durch echte Innovation. Wenn ein Nutzer Cookies im Consent-Banner ablehnt, stellen traditionelle Systeme das Tracking komplett ein, was riesige Lücken in der Analyse hinterlässt (oft 30-40% des Traffics). Jentis löst dies mit Synthetic Users. Anstatt ein Cookie im Browser zu platzieren, nutzt der Jentis-Server fortschrittliche statistische Modellierung und anonymisierte Server-Daten, um einen “synthetischen” Session-Identifier zu generieren. Dies ermöglicht es Unternehmen, entscheidende Daten über Traffic-Volumen und Conversions zu erhalten – völlig anonymisiert und zu 100% DSGVO-konform.
- Wann wählen: Wenn Datenqualität höchste Priorität hat, abgelehnte Cookies massive Datenverluste verursachen und eine hochmoderne, sofort einsatzbereite Server-Side-Lösung gefragt ist.
Fazit: Wie fällt die Entscheidung?
Es gibt kein “bestes” TMS – es gibt nur das beste TMS für das jeweilige Ökosystem. Ein Google-lastiger Stack ruft nach GTM, ein Adobe-lastiger nach Adobe Tags. Enterprise-Flexibilität spricht für Tealium. Stehen dagegen Datenschutz und die Wiederherstellung verlorener Daten im Vordergrund, ist Jentis die Zukunft.
Fragen und Antworten
Ist der Unterschied zwischen den Synthetic Users von Jentis und der Conversion-Modellierung von Google technisch, oder geht es nur darum, wo sie läuft?
Der Unterschied ist technisch: Beide sitzen auf getrennten Schritten, und die Verwirrung entsteht, wenn diese Schritte als einer behandelt werden.
Der erste Schritt ist die Identifizierung: ob überhaupt etwas auf das Gerät des Besuchers geschrieben oder von dort gelesen wird. Der zweite ist die Schätzung: Lücken in der Auswertung aus zusammengefassten Mustern zu füllen. Die Conversion-Modellierung ist rein der zweite; es entsteht keine Kennung, und fehlende Conversions werden aus beobachteten geschätzt. Eine synthetische Sitzungskennung gehört zum ersten: Der Server vergibt etwas, das für eine Sitzung steht, ohne den Browser zu bitten, es aufzubewahren. Was Jentis darauf an statistischer Modellierung anwendet, gehört zum zweiten.
An diese Unterscheidung gehören auch die Fragen. Die Genauigkeit ist eine Eigenschaft des Schätzschritts und wird mit einem Holdout-Vergleich beantwortet, nicht mit einer Anbieteraussage. Ob nach den ePrivacy-Regeln eine Einwilligung nötig ist, ist eine Eigenschaft des Speicherschritts, weil diese Regeln am Speichern oder Auslesen von Informationen auf dem Gerät ansetzen und nicht an Schlüssen, die danach auf einem Server gezogen werden; die Verarbeitung auf dem Server braucht trotzdem eine eigene Rechtsgrundlage nach der DSGVO. Eine Bewertung, die diese beiden Fragen getrennt hält, bekommt brauchbare Antworten; eine, die zur ganzen Funktion fragt „ist das konform“, nicht.
Was bedeutet „Data Governance“ bei Enterprise-Systemen konkret im Vergleich zu einem sauber geführten kostenlosen Container?
Im Kern drei nachprüfbare Dinge, und der Unterschied liegt darin, ob sie durchgesetzt oder nur verabredet sind.
Erstens Freigabe: Wer darf veröffentlichen, und muss eine zweite Person zustimmen? Der kostenlose Container kennt Rollen und Versionen, aber keinen erzwungenen Freigabeweg. Die Vereinbarung „niemand veröffentlicht allein“ hält, solange sich alle daran erinnern. Zweitens Zugriff auf Daten: Welche Werte darf ein Tag überhaupt lesen? Im kostenlosen Container kann ein benutzerdefiniertes HTML-Tag jede Variable und jedes Element der Seite lesen; gesperrt wird ein solcher Tag-Typ über eine Liste im Code der Seite, nicht in der Oberfläche des Containers. Drittens Ziele: Wohin darf gesendet werden? Eine gepflegte Liste erlaubter Empfänger ist etwas anderes als die Möglichkeit, ein eigenes Skript einzufügen.
Ob das den Preis wert ist, hängt an einer einzigen Zahl: wie viele Menschen Zugang haben. Bei drei Personen in einem Team ersetzt Absprache die Technik zuverlässig. Bei dreißig Personen aus fünf Agenturen ersetzt keine Absprache eine technische Grenze, und genau dort verkaufen sich diese Systeme.
Lässt sich ein exportierter Container im JSON-Format in der Praxis in das System eines anderen Anbieters übertragen?
In der Praxis nicht. Besser ist es, davon von Anfang an auszugehen, als auf einen Konverter zu setzen. Der Export beschreibt Tags, Trigger und Variablen im Format eines Anbieters; ihre Gegenstücke in einem anderen System haben andere Begriffe und andere Grenzen.
Übertragbar ist dagegen die Datenschicht, und sie entscheidet über die Kosten einer Migration. Sind Ereignisse und ihre Parameter in einem Dokument beschrieben und schiebt die Seite sie unabhängig davon aus, wer sie empfängt, beschränkt sich der Systemwechsel darauf, die Regeln auf denselben Daten nachzubauen. Steckt die Logik in Dutzenden Variablen, die das DOM auslesen, ist die Migration ein Neuschreiben von Grund auf.
Daraus folgt ein praktischer Schluss für heute, unabhängig davon, ob ein Wechsel je kommt: Die Datenschicht ist der Teil, der sich am meisten lohnt, schriftlich zu spezifizieren. Der Rest ist Konfiguration des Werkzeugs, und Werkzeuge wechseln häufiger als Onlineshops.
Passend dazu
