Website-Personalisierung mit GTM und ActiveCampaign

Website-Personalisierung mit Google Tag Manager und ActiveCampaign funktioniert über eine klare Aufgabentrennung: GTM übernimmt die Auslieferung der Personalisierungslogik im Browser des Besuchers, ActiveCampaign stellt die Kontextdaten bereit – über das Site Tracking-Snippet und über URL-Parameter in E-Mail-Links. DSGVO-konform wird das Setup nur, wenn das Consent-Management vor dem Tracking-Tag greift.

Das Wichtigste in Kürze

Das ActiveCampaign-Site-Tracking-Snippet wird als Custom HTML Tag in GTM verwaltet und per Consent-Trigger erst nach Einwilligung aktiviert.
URL-Parameter aus ActiveCampaign-E-Mail-Links identifizieren bekannte Kontakte sitzungsweise – ohne dauerhaftes Third-Party-Cookie.
ActiveCampaign-API-Schlüssel gehören nicht ins Browser-Frontend; für CRM-Daten braucht es eine serverseitige Zwischenschicht.
GTM ist für Show/Hide-Logik und Parameterübergaben geeignet, nicht für komplexe Inhaltswechsel, die ein Front-End-Framework erfordern.

Wie GTM und ActiveCampaign die Aufgaben aufteilen

In vielen Setups vermischt sich schnell, was das Tag-Management-System und was das CRM leisten soll. Das Ergebnis sind fragile Konfigurationen, die beim nächsten CMS-Update brechen oder beim ersten DSGVO-Audit zu Nachfragen führen. Die saubere Abgrenzung ist deshalb der wichtigste Schritt, bevor irgendeine Zeile Personalisierungslogik gebaut wird.

Google Tag Manager ist das Delivery-System. Er entscheidet im Browser des Besuchers, wann welcher Code ausgeführt wird, welcher Inhalt sichtbar ist und was in den Data Layer geschrieben wird. GTM kennt den Besucher selbst nicht – er liest nur, was ihm über Variablen, URL-Parameter oder Data Layer-Objekte mitgeteilt wird.

ActiveCampaign ist die Datenbasis. Es kennt den Kontakt, seinen Verlauf, seine Tags und seinen Lead Score. Diese Daten verlassen ActiveCampaign entweder über das Site Tracking-Cookie, über URL-Parameter in E-Mail-Links oder über die API. Der Browser bekommt davon nur so viel, wie die Architektur explizit weiterleitet.

Diese Trennung hat praktische Konsequenzen. Wer Geschäftslogik in GTM baut – etwa "Nutzer mit mehr als drei Seitenbesuchen gilt als qualifiziert" – hat das Problem, dass dieselbe Logik an zwei Stellen gepflegt werden muss. Die ActiveCampaign-Automatisierung kennt den Website-Zustand dann nicht, und GTM weiß nicht, was in der Automatisierung gerade läuft. Segmentierungs- und Qualifizierungslogik gehört in ActiveCampaign. GTM liest das Ergebnis – als Tag, als Lead Score oder als URL-Parameter – und liefert den passenden Content aus.

Welche Datenflüsse es gibt

Drei Kanäle verbinden ActiveCampaign und GTM in der Praxis:

Das Site Tracking-Snippet, das GTM auf jeder Seite ausliefert und das bekannte Kontakte über ein First-Party-Cookie identifiziert, sobald sie vorher einen E-Mail-Link geklickt haben.
URL-Parameter, die ActiveCampaign in E-Mail-Links einbettet und die GTM über eine URL-Variable ausliest – dieser Kanal funktioniert ohne dauerhaftes Cookie und ist deshalb die einfachere DSGVO-Variante.
Eine serverseitige API-Abfrage, die GTM selbst nicht durchführen kann, da API-Schlüssel im Browser-Frontend nicht exponiert werden dürfen. Dafür ist eine Serverless Function oder ein Backend-Endpoint notwendig, der nur die benötigten, anonymisierten Felder zurückgibt.

So bindest du das ActiveCampaign Site Tracking korrekt ein

Das Site Tracking ist die Grundlage aller weiteren Personalisierungsschritte. Es verbindet Website-Besuche mit dem ActiveCampaign-Kontakt und macht Verhaltensdaten für Automatisierungen, Segmentierungen und Lead Scoring auswertbar. Mehr dazu, wie das Tracking intern arbeitet, erklärt der Artikel Site Tracking in ActiveCampaign: Website-Besucher Kontakten zuordnen.

Das Snippet selbst ist ein kurzes JavaScript, das ActiveCampaign unter Einstellungen > Tracking > Site Tracking bereitstellt. Es ist konto-spezifisch und enthält die Tracking-ID deines Accounts. Dieses Snippet als Custom HTML Tag in GTM zu verwalten hat einen entscheidenden Vorteil: Du kannst den Consent-Status des Besuchers als Voraussetzung setzen und das Tag erst feuern lassen, wenn die Einwilligung vorliegt.

So gehst du vor:

In ActiveCampaign: Einstellungen > Tracking > Site Tracking. Dort liegt dein Account-spezifischer Tracking-Code. Den Code vollständig kopieren – inklusive der umschließenden Script-Tags.
In GTM: Neuen Tag anlegen, Typ "Benutzerdefiniertes HTML". Den kopierten Code einfügen. Den Tag-Namen eindeutig benennen, zum Beispiel "AC – Site Tracking".
Trigger definieren: Wenn du mit dem GTM Consent Mode arbeitest, nutzt du den Trigger-Typ "Einwilligung initialisieren" und setzt analytics_storage als Voraussetzung. Wenn du ein eigenes Consent-System nutzt, legst du eine GTM-Variable an, die den Einwilligungsstatus aus dem Cookie deines Consent-Banners liest, und verwendest diese als Trigger-Bedingung.
GTM Vorschau aktivieren: Im Preview Mode prüfst du, ob der Tag ausschließlich bei gegebener Einwilligung feuert. Dazu das Consent-Banner im Preview-Browser ablehnen und prüfen, ob der Tag als "Blocked by Consent" oder "Not fired" erscheint.
In GTM veröffentlichen und anschließend in ActiveCampaign unter Einstellungen > Tracking > Seitenbesuche prüfen, ob die Daten nach einem Testklick von einer E-Mail ankommen.

Einmal aktiv, siehst du in ActiveCampaign pro Kontakt eine Chronologie der besuchten Seiten. Diese Daten stehen sofort für Automatisierungen (“Kontakt hat Preisseite besucht”) und Segmentierungen (“alle Kontakte, die in den letzten sieben Tagen die Demo-Seite aufgerufen haben”) zur Verfügung.

Das Site Tracking-Setup dauert in GTM wenige Minuten. Genau deshalb wird es oft schnell erledigt – und der Consent-Gate wird dabei übergangen. GTM bietet mehrere Trigger-Typen an, und "All Pages" ist der naheliegendste. Ein Tag mit diesem Trigger feuert beim Seitenaufruf sofort, bevor der Besucher überhaupt die Möglichkeit hatte, sein Consent-Banner zu sehen.

Das Ergebnis ist ein technisch funktionsfähiges, aber rechtlich problematisches Setup. In einem DSGVO-Audit reicht es nicht aus zu sagen, dass das Tracking rein technisch als First-Party-Tracking implementiert ist. Entscheidend ist der Verarbeitungszweck: personalisierte Inhalte auf Basis von Kontaktverhalten sind Marketing, und Marketing erfordert Einwilligung nach Art. 6 Abs. 1 lit. a DSGVO.

Kontakte sitzungsweise über URL-Parameter identifizieren

Site Tracking funktioniert nur für bekannte Kontakte, die vorher auf einen E-Mail-Link geklickt haben – und nur, wenn das First-Party-Cookie von ihrem Browser gespeichert wird und noch gültig ist. Es gibt einen ergänzenden Weg, der ganz ohne dauerhaftes Cookie auskommt: die URL-Parameter-basierte Sitzungsidentifikation.

ActiveCampaign kann in jeden Link einer E-Mail URL-Parameter einbetten. Das geschieht entweder über UTM-Parameter, die du manuell in den Link schreibst, oder über Personalisierungsfelder, die ActiveCampaign beim Versand dynamisch befüllt. Ein typischer Link sieht dann so aus: https://beispiel.de/landing?utm_source=newsletter&utm_campaign=onboarding&ac_contact=HASH

GTM liest diesen Parameter über eine URL-Variable aus. Der Wert ist für die Dauer der Sitzung im Browser verfügbar. Damit lässt sich steuern, welcher Inhalt dem Kontakt gezeigt wird – ohne dauerhaft gespeichertes Cookie.

URL-Variable in GTM anlegen

Das technische Setup besteht aus drei Schritten:

In GTM unter Variablen > Neue Variable anlegen. Variablentyp: "URL", Komponentenformat: "Abfragestring". Als Schlüssel den Parameternamen eintragen, zum Beispiel "ac_contact". Speichern und der Variable einen klaren Namen geben, etwa "URL – AC Contact ID".
Einen Trigger erstellen, der auf alle Seiten feuert, wenn die Variable "URL – AC Contact ID" nicht leer ist. Das stellt sicher, dass Personalisierungs-Tags nur aktiv werden, wenn ein Kontaktparameter in der URL vorhanden ist.
Einen Custom HTML Tag schreiben, der den Wert der Variable ausliest und den gewünschten Seiteninhalt anpasst: ein verstecktes Element einblenden, den Text einer Headline setzen oder eine andere Variante eines CTAs sichtbar machen.

Der wesentliche Vorteil dieser Methode ist die Rechtssicherheit: Da kein Cookie gesetzt wird, ist der DSGVO-Aufwand minimal. Der Nachteil: Die Personalisierung greift nur auf der ersten Zielseite nach dem E-Mail-Klick zuverlässig. Auf Folgeseiten ist der Parameter nur dann verfügbar, wenn er über interne Links explizit weitergereicht wird – was in der Praxis selten konsequent umgesetzt wird.

Was nicht als URL-Parameter übertragen werden sollte

URL-Parameter sind für jeden sichtbar, der den Link kennt oder die Browser-URL liest. Persönliche Daten wie Vor- und Nachname, E-Mail-Adresse oder Unternehmen sollten daher nicht als Klartext in der URL erscheinen. Wer eine Kontakt-ID oder einen anonymisierten Hash überträgt, ist auf der sicheren Seite – er erlaubt serverseitig eine Zuordnung, ist aber für Dritte ohne Datenbankzugriff bedeutungslos. Außerdem gilt: Server-Logs und Analytics-Tools sollten diese Parameter nicht dauerhaft im Klartext speichern, da die URL dann selbst als personenbezogenes Datum gilt.

DSGVO: Was bei der technischen Umsetzung zwingend ist

Personalisierung auf Basis von Kontaktdaten aus einem CRM ist nach DSGVO eine Verarbeitung personenbezogener Daten. Für das Setup aus GTM und ActiveCampaign ergeben sich daraus drei unvermeidliche Pflichten, die vor dem Go-Live geklärt sein müssen.

Einwilligung vor dem Tracking

Das Site-Tracking-Snippet darf erst feuern, nachdem der Besucher eingewilligt hat. Das ist im GTM Consent Mode abzubilden oder über eine eigene Variablen-Logik, die den Einwilligungsstatus prüft. Wer das Snippet mit einem All-Pages-Trigger ohne Consent-Gate versieht, verstößt gegen die DSGVO-Anforderungen – auch wenn das Tracking technisch als First-Party-Tracking gilt. Entscheidend für die rechtliche Bewertung ist nicht die technische Umsetzung, sondern der Verarbeitungszweck: personalisierte Inhalte auf Basis von Kontaktverhalten sind Marketing, und Marketing erfordert Einwilligung. Ein häufig übersehener Punkt: GTM Consent Mode-Konfigurationen sind oft unvollständig. Wenn das Consent-Banner nur "analytics_storage" signalisiert, aber das Site-Tracking-Tag auf "marketing_storage" wartet, feuert das Tag nie – auch nicht nach Einwilligung. Beide Consent-Signale müssen sauber aufeinander abgestimmt sein.

Auftragsverarbeitung korrekt dokumentieren

Mit ActiveCampaign muss ein Auftragsverarbeitungsvertrag abgeschlossen sein. Bei Konten, die nach den aktuellen ActiveCampaign-Nutzungsbedingungen aktiviert wurden, ist der AVV in der Regel Bestandteil der Verträge. Es empfiehlt sich trotzdem, den Stand zu prüfen und die Bestätigung für das eigene Verfahrensverzeichnis zu dokumentieren – sowohl für ActiveCampaign als auch für Google als GTM-Anbieter.

Verfahrensverzeichnis-Eintrag anlegen

Die Website-Personalisierung auf Basis von Kontaktdaten ist als Verarbeitungstätigkeit zu dokumentieren. In das Verfahrensverzeichnis gehören: Zweck der Verarbeitung, Rechtsgrundlage, Kategorien der verarbeiteten Daten, Aufbewahrungsfristen und die eingesetzten Tools. Ein häufig vergessener Punkt: Wenn URL-Parameter eine Kontakt-ID enthalten, ist die aufgerufene URL selbst personenbezogen, solange sie dem Kontakt eindeutig zugeordnet werden kann. Server-Logs und Analytics-Tools sollten diese Parameter nicht dauerhaft im Klartext speichern.

Typische Fehler, die die Personalisierung zerstören

Aus dem Blick in viele GTM-Container und ActiveCampaign-Konten zeichnen sich wiederkehrende Muster ab. Die folgenden Fehler machen das Setup entweder rechtlich problematisch oder technisch funktionsunfähig – meistens beides gleichzeitig.

Der häufigste Fehler: Das Site Tracking feuert ohne Einwilligungsschranke. Der GTM-Container ist schnell aufgesetzt, aber der Consent-Check fehlt. Das zeigt sich oft erst dann, wenn ein Datenschutzbeauftragter das Setup prüft oder eine Aufsichtsbehörde eine Beschwerde nachverfolgt. Ein zusätzliches Problem: GTM Consent Mode-Konfigurationen sind häufig unvollständig. Wenn das Consent-Banner nur "analytics_storage" signalisiert, aber das Site-Tracking-Tag auf "marketing_storage" wartet, feuert das Tag nie – auch nicht nach Einwilligung. Beide Consent-Signale müssen sauber aufeinander abgestimmt sein.

Personalisierter Inhalt wird vom CDN gecacht

Wenn eine Seite als gecachtes HTML-File durch ein CDN ausgeliefert wird, erhält jeder Besucher dieselbe HTML-Version. Clientseitiges JavaScript greift in diesem Fall zu spät: Der Besucher sieht kurz die generische Version, dann springt der Inhalt – ein sogenannter Flash of Generic Content. Das wirkt nicht personalisiert, sondern fehlerhaft. Wer auf einem statisch gecachten Framework aufbaut, muss entweder die Personalisierungslogik serverseitig verlagern oder Cache-Bypässe für bekannte Kontakte konfigurieren – was die CDN-Performance reduziert und die Architektur komplexer macht.

API-Schlüssel landen im GTM Custom HTML Tag

ActiveCampaign-API-Schlüssel, die in einem Custom HTML Tag in GTM landen, sind für jeden Besucher im Quellcode der Seite sichtbar. Der API-Schlüssel gewährt Zugriff auf den gesamten ActiveCampaign-Account – Kontakte lesen, Automationen starten, Daten exportieren. Ein kompromittierter Schlüssel bedeutet vollständigen Datenverlust und eine meldepflichtige Datenschutzverletzung nach DSGVO Art. 33. Für Daten aus ActiveCampaign, die über die API abgerufen werden müssen, ist immer eine serverseitige Lösung erforderlich: eine Serverless Function oder ein eigener API-Endpoint, der nur die benötigten, anonymisierten Kontextdaten zurückgibt.

Trigger-Reihenfolge in GTM nicht abgestimmt

GTM führt Tags in der Reihenfolge aus, in der sie im Container angelegt sind – sofern keine explizite Priorität gesetzt ist. Wenn ein Personalisierungs-Tag vor dem Consent-Tag feuert, ist die Einwilligung noch nicht bekannt, und der Personalisierungs-Tag greift ins Leere. Consent-relevante Tags brauchen entweder eine höhere explizite Priorität oder einen Consent-Initializer-Trigger, der sicherstellt, dass der Consent-Status vor allen anderen Tags gelesen wird.

Personalisierungslogik doppelt pflegen

Wer Segmentierungsregeln in GTM nachbaut, die bereits in ActiveCampaign existieren, hat zwei Systeme, die sich im besten Fall synchron verhalten. In der Praxis driften sie auseinander: ActiveCampaign bekommt ein neues Tag-System, GTM kennt es nicht. Eine Automatisierung ändert die Qualifikationsregel, GTM weiß es nicht. Personalisierungslogik, die sich auf Kontaktdaten stützt, gehört in das System, das diese Daten verwaltet. GTM setzt nur um, was ActiveCampaign entschieden hat – und nicht mehr.

Wann diese Kombination nicht die richtige Wahl ist

GTM und ActiveCampaign als Personalisierungs-Stack ist für viele Szenarien gut geeignet – aber nicht für alle. Wer das Setup aufbaut, ohne die Grenzen zu kennen, investiert Zeit in eine Lösung, die das eigentliche Problem nicht löst.

Wenn Echtzeit-CRM-Daten gebraucht werden

Wenn die Personalisierung von Daten abhängt, die sich häufig ändern – aktueller Vertragsstatus, Kaufhistorie der letzten Woche, offene Support-Tickets – reicht das Setup nicht aus. Diese Daten stehen in ActiveCampaign nicht als URL-Parameter zur Verfügung, und eine API-Abfrage im Browser-Frontend ist aus Sicherheitsgründen ausgeschlossen. Hier braucht es serverseitige Personalisierung: entweder durch einen dedizierten Personalisierungs-Service, der Segmententscheidungen trifft, bevor die Seite ausgeliefert wird, oder durch die Serverkomponenten des jeweiligen Frameworks wie Next.js Server Components oder Nuxt SSR.

Wenn kein GTM-Know-how im Team vorhanden ist

GTM ist ein mächtiges Werkzeug mit einer steilen Lernkurve beim Fehlerdiagnostizieren. Ein Custom HTML Tag, der eine JavaScript-Exception wirft, kann dazu führen, dass andere Tags auf derselben Seite nicht mehr feuern. Fehler sind oft nur im GTM Preview Mode sichtbar und lassen sich im Live-Container schwer reproduzieren. Wer im Team keine Person hat, die GTM-Container debuggen kann, sollte diesen Stack nicht in Eigenregie aufbauen.

Wenn eine statisch gecachte Architektur die Basis ist

Websites, die auf einem Static Site Generator basieren und alle Seiten als vorgerenderte HTML-Files über ein CDN ausliefern, bieten clientseitigem JavaScript wenig Spielraum für nahtlose Personalisierung. Jede clientseitige Änderung am Inhalt tritt nach dem First Contentful Paint ein – der Besucher sieht den generischen Inhalt zuerst, dann die Personalisierung. Je nach Ladegeschwindigkeit und Art des personalisierten Inhalts fällt das kaum oder stark auf. Wer eine überwiegend statisch gecachte Architektur betreibt, sollte klären, ob Edge-seitige Personalisierung über Cloudflare Workers, Vercel Edge Functions oder Netlify Edge eine bessere Grundlage bietet, bevor GTM-basierte Lösungen aufgebaut werden.

Häufige Fragen

Wie erkennt ActiveCampaign Site Tracking einen wiederkehrenden Besucher?

Das Site Tracking-Snippet setzt beim ersten Klick eines Kontakts auf einen E-Mail-Link ein First-Party-Cookie im Browser. Bei allen folgenden Besuchen derselben Domain liest das Snippet dieses Cookie aus und ordnet die aufgerufenen Seiten dem entsprechenden Kontakt in ActiveCampaign zu. Das funktioniert nur für Besucher, die mindestens einmal einen E-Mail-Link geklickt haben, und nur im Browser, in dem dieses Cookie gesetzt wurde. Im Inkognito-Modus oder in einem anderen Browser ist der Kontakt anonym.

Kann GTM ActiveCampaign-Tags direkt auslesen, ohne eine API-Anfrage zu machen?

Nein. GTM hat keinen direkten Zugriff auf ActiveCampaign-Daten. Tags, Custom Fields oder Lead Scores sind im Browser nicht verfügbar, es sei denn, sie wurden zuvor explizit übermittelt – entweder über URL-Parameter aus E-Mail-Links oder über eine serverseitige Zwischenschicht, die die API aufruft und nur die benötigten Felder in den Data Layer schreibt. Beides erfordert zusätzliches Setup und kann nicht allein aus GTM heraus realisiert werden.

Für die Nutzung im Rahmen von Marketing-Personalisierung gilt: Ja. Das Site Tracking identifiziert Kontakte individuell und speichert ihr Surfverhalten im CRM. Das ist ein Marketingzweck, für den die DSGVO Einwilligung verlangt. Wer das Snippet hinter einem Consent-Gate platziert, ist auf der sicheren Seite – unabhängig davon, ob das Cookie technisch als First-Party oder Third-Party klassifiziert wird.

Was passiert mit der Personalisierung, wenn ein Kontakt im Inkognito-Modus browst?

Im Inkognito-Modus existieren keine vorherigen Cookies. Das Site Tracking setzt zwar ein neues Cookie, wenn der Kontakt einen E-Mail-Link klickt – dieses Cookie besteht aber nur für die Dauer der Inkognito-Sitzung. Sobald das Fenster geschlossen wird, ist die Identifikation verloren. URL-Parameter-basierte Personalisierung funktioniert auch im Inkognito-Modus, sofern der Kontakt direkt von einem E-Mail-Link kommt und die Parameter in der URL vorhanden sind.

Eignet sich GTM für A/B-Tests im Rahmen der Website-Personalisierung?

GTM kann einfache clientseitige A/B-Tests abbilden, bei denen Besucher per JavaScript zufällig einer Variante zugewiesen werden. Das reicht für schnelle Hypothesentests aus. Für statistisch belastbare Ergebnisse über längere Zeiträume braucht es ein dediziertes Testing-Tool, das Variantenzuweisungen konsistent über mehrere Sitzungen speichert und Experimente sauber auswertet. GTM-basierte Tests ohne persistente Speicherung der Variantenzuweisung verzerren die Ergebnisse, sobald ein Besucher die Seite erneut aufruft.

Wer ActiveCampaign systematisch für die Website-Kommunikation einsetzen und das Zusammenspiel mit dem Front-End ausbauen will, legt die Grundlage am besten mit einem sauberen Site Tracking-Setup – bevor Personalisierungslogik in GTM aufgebaut wird. Die Qualität der Kontaktdaten in ActiveCampaign entscheidet letztlich darüber, wie differenziert die Website auf bekannte Besucher reagieren kann.