Manchmal ist man einfach zu gut zum Verdrängen. Ich weiß nicht mehr, wie oft mein Co-Moderator Michael und ich in unserem Podcast gesagt haben: "Wenn Universal Analytics abgeschaltet wird, muss man seinen Content aufräumen. Veraltete Anleitungen schaden mehr als sie nutzen." Guter Tipp. Haben wir 2022 oder so gegeben. Umgesetzt habe ich ihn - naja - jetzt. Im April 2026. Fast drei Jahre nach dem Ende von UA.
Personenbezogene Daten wie Namen, Mailadressen, Anschriften etc. (AKA "PII" - Personally identifiable information) haben in Google Analytics nichts verloren. Das ist nicht erst seit der DSGVO so. Google hatte schon immer etwas dagegen und gibt die Verantwortung dafür schon immer in den Nutzungsbedingungen ab. Seit GA4 gibt es erfreulicherweise auch Funktionen zum Redigieren von Mailadressen in URLs oder gezieltem Entfernen von Daten. Aber das reicht nicht unbedingt. Was ist mit Mailadressen in Ereignisparametern oder Nutzereigenschaften? Aus diesem Grund habe ich den PII-Check bei Analytrix nach vielen Jahren wieder aufleben lassen, denn ich treffe immer wieder auf Fundstellen an Orten, an denen ich keine Personenbezogenen Daten vermuten würde. Selbst wenn ein automatisierter Check nicht alles finden kann, hat diese Wiederbelebung m. E. einen Sinn. Und so lebt das Tool wieder, mit dem jeder nach Autorisierung des Zugriffs anhand verschiedener Muster in seinen Daten nach Spuren von problematischen Eigenschaften suchen kann. Nicht nur (aber auch) in URLs.
Weiterlesen... »
Scrolltracking ist ein - leider - sehr beliebtes Feature. Nicht nur, aber auch in Google Analytics. Eine der "besten" Eigenschaften von Google Analytics ist es, dieses Event nur einmal bei 90 Prozent auszulösen und nicht in Zehn- oder 25-Prozent-Schritten.
Warum wollen wir überhaupt Scrolltracking? Dieser Beitrag befasst sich mit den typischen Fragen, die hinter dem Wunsch nach Scrolltracking stehen, den besseren Wegen zu Antworten und den Problemen, die damit zusammenhängen, wenn man diese Antworten dennoch in Scroll-Ereignissen sucht. Weiterlesen... »
Damals, als mein Haar noch voll war und bevor es Webanalyse mit "Tracking-Pixeln" gab, waren Logfiles mal sexy. Seither hat mein Kopf reichlich Haare - und das Thema jenseits von Monitoring und IT immer mehr an Relevanz - verloren. Obschon doch so viel mehr in Logs seht als Seitenaufrufe. Einiges davon war und ist auch im Marketing interessant. Mit der wachsenden Relevanz von KI Crawlern für Training und Grounding erinnern sich nun verschiedenste Disziplinen wieder an den Wert von Logfiles. Die Ironie: In den Übersichten im Backend der meisten Hoster und Server ist die Zeit stehen geblieben. Wir sehen Balkendiagramme und "Hit-Zähler", wie es sie schon in den Neunzigern gab. Wer mehr wissen will, muss sich auch heute noch oft selbst einen passende Stack dazu aufbauen... mit entsprechendem Aufwand und technischen Hürden.
Logalytrix ist mein Versuch, das zu ändern: Ein Logfile-Analyzer, der aus Rohdaten echte Analyse ermöglicht... wenngleich nicht perfekt. Aber anders als typische und meist statische Reports und Auswertungen. Das ganze passiert lokal, in einer einzigen HTML-Datei, ohne Backend - und mit ein paar Fähigkeiten, die man in diesem Segment nicht erwartet. Neugierig geworden? Hier die Story dazu und ein Blick in die Funktionen und Besonderheiten.
Es gibt viele gute Gründe, etwas an einem Tag Manager Container zu ändern. Zum Glück kann man in der Vorschau testen, ob alles funktioniert. Und wenn ein Trigger nicht wie gewünscht auslöst, findet man in Variablen, dem dataLayer, dem Consent Mode oder irgendwo anders üblicherweise den Grund: Der CSS Selektor ist falsch, das Variablenformat stimmt nicht (mehr), vormals zuverlässige Keys aus der Datenschicht sind ausgefallen. Die Gemeinsamkeit: Man hat es selbst in der Hand oder findet zumindest einen nachvollziehbaren Grund. Normalerweise. Und dann gibt es da Click-Trigger im Google Tag Manager, die trotz erfüllter Bedingungen einfach nicht auslösen wollen. Alles zehnfach kontrolliert und auf gleiche Weise hunderte Male schon gebaut... und dann funktioniert es nicht. Stößt man bei der Suche im Tag Assistant auf eine nicht erfüllte "Regex-Bedingung", die man selbst gar nicht definiert hat, hat man ein Problem. Ein seltenes, aber reales Problem, das sich weder durch Löschen und Neuanlegen der Trigger noch durch Neupublikation beheben lässt. Was tun?
Meine Probleme sind bestimmt nicht vergleichbar mit denen des Anton aus "Es ist nicht leicht ein Gott zu sein", aber auch Agnostiker haben es manchmal schwer. Wenn es um Webanalyse, Tag Manager, Reporting Plattformen und andere Themen geht, bezeichne ich mich gern als "tool-agnostisch". In wenigen Kategorien fällt mir das allerdings so schwer wie bei Consent Management Plattformen. Und obschon meine Berührungspunkte primär mit der (oft sehr holprigen) Zusammenarbeit zwischen Consent Manager, Consent Mode und Tag Manager zu tun haben (siehe mein E-Book dazu ;)) und dieser Bereich schon genug Stolperfallen bereithält, kenne ich aus der Praxis auch das eine oder andere Backend und die im Tool verankerten Prozesse.
Meistens dann, wenn es nicht rund läuft. Da es aber zu meinem Alltag gehört, Kunden bei der Implementierung und Optimierung von Tracking-Setups zu begleiten - und die CMP ist dabei die erste und oft schmerzhafteste Weichenstellung -, werde ich auch gelegentlich um Rat gefragt, welches Tool man anschaffen sollte. Weil das alte entweder schlichtweg schon auf den ersten Blick nicht die datenschutzrechtlichen Anforderungen erfüllen kann, zu teuer geworden ist oder man schlechte Erfahrungen gemacht hat. Mit der API, der Zuverlässigkeit, der Gestaltungsoptionen des Consent Dialogs... Gründe gibt es genug.
Gerade heute landete wieder eine dieser Anfragen in meinem Postfach, die ich in ähnlicher Form schon mehrfach bekommen habe: Ein größeres Unternehmen will seine bestehende CMP ablösen. In diesem Fall OneTrust, was nicht ganz unüblich ist, (räusper) und hat dafür ein Anforderungsprofil in einer Excel-Liste zusammengestellt. Verschiedene Anbieter sollen diese Liste beantworten und ich habe ein solches Exemplar bekommen, mit dem Feedback eines der Anbieter. Das klingt nach einem vernünftigen Prozess. Ist es auch - aber leider nur auf den ersten Blick.
Google Analytics bietet mit Schlüsselereignissen einen einfachen Weg, wichtigen Aktionen eine besondere Rolle zu geben und mit den zugehörigen "Konversionen" Erfolg zu bewerten. Ein Klick in der Übersicht der Ereignisse in den Einstellungen auf den Stern für dem Ereignisnamen, fertig. Das ist vielleicht sogar schon zu einfach, denn die Versuchung ist groß, auch sämtlihe Micro Conversions als Schlüsselereignis zu markieren. Download eines PDFs, Klick auf eine Telefonnummer, Absenden eines Newsletter-Formulars, Add to Cart: All das kann ein Schlüsselereignis sein. Die Frage ist, ob es eines sein sollte.
Denn jedes zusätzliche Schlüsselereignis verwässert die Key Event Rate. Diese Metrik – verfügbar auf Ebene von Sitzungen und Nutzern – ist einer der wenigen echten Conversion-Rate-Indikatoren in GA4. Wer dort alles reinwirft, was irgendwie nach Interaktion riecht, macht sie unbrauchbar. Am Ende steht eine beeindruckende Rate von 62%, die exakt nichts aussagt, weil sie angefangene Kontaktformulare, PDF-Downloads und Klicks auf die Telefonnummer in einen Topf mit harten Zielerreichungen oder Käufen wirft.
Die Alternative: Events weiterhin als normale Ereignisse feuern lassen und ihre Anzahl über benutzerdefinierte Messwerte (Custom Metrics) auswertbar machen. Ohne die Conversion-Rate zu ruinieren, aber mit voller Flexibilität in Explorations und Standardberichten.
Ich prüfe Tracking-Setups. Oft - und manuell. Browser auf, DevTools auf, Netzwerk-Tab filtern, Consent-Banner klicken, schauen was passiert, Cookie-Liste durchgehen, dataLayer inspizieren, Consent Mode Parameter entziffern. Für jede einzelne Phase: Pre-Consent, Post-Accept, Post-Reject. Und dann manchmal nochmal für den typischen E-Commerce-Pfad - zumindest bis vor dem Kaufabschluss, um in den dataLayer zu starren und Inkonsistenzen zu finden. BTW: Dabei muss ich gelegentlich immer noch Erinnerungen an Universal Analytics abschütteln, wenn ich auf das vertraute, aber veraltete Format treffe. Egal. Das ist jedenfalls theoretisch gründlich, aber es skaliert nicht - und es ist fehleranfällig, weil ein Mensch beim dritten Audit am Tag Dinge übersieht, die beim ersten noch aufgefallen wären.
Daher habe ich schon länger darüber nachgedacht, genau diesen Vorgang zu automatisieren. Selbst geschrieben (wie es bisher meine Art war) ist das allerdings angesichts der vielen Variablen schwierig, komplex, zeitraubend und fehleranfällig. Deshalb bin ich es auch nie angegangen - bis in dieser Woche. Mit Claude, Node.js, Playwright und einer wachsenden Sammlung von Erkenntnissen, die man nur bekommt, wenn man es wirklich baut und verwendet. Dieser Post dokumentiert den Weg - und erzählt zugleich eine (vielleicht) typische Geschichte, wie man es endlich schafft, nicht mehr selbst der Flaschenhals zu sein. Denn: Skepsis gegenüber der Idee, eine solche Analyse einer KI zu überlassen, ist berechtigt. Warum und wie ich es dennoch getan habe, ist hier dokumentiert.
Weiterlesen... »
Manche Websites altern wie guter Wein, andere wie Milch. Und dann gibt es meine: Ein digitales Biotop, das irgendwo zwischen "Linkwüste der 90er" und "XHTML-Validierungs-Wahn der 2000er" steckengeblieben ist. Aber letzte Woche ist tatsächlich etwas passiert. Die Site ist neu - wirklich komplett überarbeitet. Und mein Partner in Crime war diesmal kein Editor, sondern Gemini. Neues Design entwerfen, Inhalte neu zusammenstellen, Portierung der alten Seiten auf das neue Design, ein wenig PHP, WordPress Template für den Blogbereich... alles (und das ist - für mich - relativ neu) nur noch lenkend, statt alles selbst zu erledigen.
Aber da es nicht immer so war und meine eigene Site 25 Jahre hinter sich hat, wollte ich hier einen persönlichen Rückblick hinterlassen. Keine Relevanz für meine Lieblingsthemen "Tagging" und "Analytics". Wenn Du es trotzdem lesen willst: Hier meine "Website-Story".
Weiterlesen... »
Google hat es mal wieder geschafft: Eine Mail wirft mehr Fragen auf, als sie beantwortet. Ähnlich wie beim Thema Consent Mode haben viele Nutzer eines Google Tools - diesmal des Tag Managers - eine verwirrende Mail zu einer anstehenden Änderung erhalten, die das Google-Tag betrifft. Dieser Beitrag beleuchtet die Hintergründe und zeigt vor allem, was konkret zu tun ist, wenn man sich nicht auf den in wenigen Wochen geänderten Automatismus verlassen mag.
Weiterlesen... »
Wenn es um Tracking-Setups geht, waren iFrames schon immer eine besondere Herausforderung. Für einen Inhalt in einem iFrame als Teil einer beinhaltenden Seite ein sinnvolles Tracking aufzusetzen, das in den Kontext der restlichen Domain passt, verursacht oft eine Menge Arbeit. Kommen die Inhalte für den iFrame auch noch von einer anderen Domain, fängt der Spaß so richtig an: Cross-Domain-Tracking, getrennte Persistenz in Form von Cookies und Browser-Speicher, wackelige Kommunikation zwischen den beteiligten Domains über Parameter, Hürden durch moderne Browser-Tracking-Protection-Maßnahmen an allen Fronten. Dazu gesellt sich die “Same Origin” Policy als Blockade für alle Versuche, aus der Hauptseite “in” den iFrame zu schauen (oder gar umgekehrt). Und dann ist da auch noch das Thema Zustimmung. Wer fragt wann wonach, bevor Daten gesendet werden können? Das alles ist ein ziemlicher Wust aus potenziellen Problemen. Zum Glück gibt es aber eine ganz einfache Lösung: Das Tracking bleibt auf der beinhaltenden Seite und alles, was im iFrame passiert, wird über Messages kommuniziert. Weiterlesen... »
Sobald mehr als ein globales “Marketing-Pixel” oder ein beliebiger Tracking-Code auf Websites eingebunden werden soll, spielen Tag Management Systeme ihre Stärken aus. Gezieltes Ausspielen von Tags verschiedener Dienste auf einzelnen oder allen Seiten sowie die Messung von einzelnen Events und E-Commerce sind damit ungleich einfacher als bei direkter Implementierung. Kein Wunder also, dass Google Tag Manager, Tealium oder Tag Management Komponenten von Matomo, Piwik PRO und anderen weit verbreitet sind. Was aber, wenn mehr als eine Website bedient werden soll? Bekommt jede Seite einen eigenen Tag Manager oder ist eine zentrale Pflege in einem Multi-Site-Container möglich und sinnvoll? Die Antwort hängt - wie immer - von den Rahmenbedingungen ab. Weiterlesen... »
Dass Google einen schlechten Start mit dem eigenen Consent Mode hingelegt hat, ist unbestritten. Eine kurze Frist, wenig Infos zu den Folgen bei Nichtbeachtung und spärliche Angaben zu den konkreten Auswirkungen waren ein ziemlicher Schreck für viele... vor noch nicht sehr langer Zeit. Nun hat Microsoft nachgezogen und alle Advertiser angeschrieben, dass der UET - eigene Consent Mode nun in der "Basic" Variante (um im Google Jargon zu bleiben) ebenfalls Pflicht wird. Ohne weitere Informationen zu Fristen und Folgen, ohne Unterstützung jenseits einer schon seit längerem existierenden Hilfe-Seite zum UET Consent Mode. Was ist denn da los? Weiterlesen... »
Dieser Beitrag beschreibt ein Verfahren zum Austausch einer Google Tag Manager Vorlage gegen eine andere. Ja genau: Es ist ein sehr spezieller Anwendungsfall. Mir ist er begegnet, als ich in mehreren Containern ein z. T. recht umfangreiches Tracking mittels Facebook Pixel von einer Community-Vorlage auf eine andere umstellen musste. Genauso denkbar ist ein Einsatz dort, wo eine zunächst lokal installierte Vorlage ("Template") gegen sein zwischenzeitlich in der Community Gallery verfügbares Pendant ausgetauscht werden muss und nicht nur ein oder zwei Tags bzw. Variablen neu definiert werden müssen. Weiterlesen... »
Bei der Implementierung von parallelem Facebook Tracking via Pixel und CAPI über den Google Tag Manager bin ich vor ein paar Tagen auf ein eigenartiges Problem gestoßen: Die Event IDs der Ereignisse aus dem Browser und vom Server stimmten nicht überein, obschon sowohl das GA4 Tag, das durch den server-side GTM läuft als auch das Facebook Pixel Tag im Browser zur gleichen Zeit ausgelöst wurden. Nur hat das GA4 Tag für page_view, view_item, purchase und einige andere stets Event IDs späterer Events verwendet.
TL;DR: Wer nur die Lösung braucht: Es liegt am Tag Sequencing, das bei älteren client-side Tag Manager Containern die beste Option war, um wirklich alle Events durch den eigenen Server laufen zu lassen. Wer mehr wissen will, findet im Folgenden mehr Details zum Problem und zur Korrektur, die ich nur dank Denis von Stape kenne, obschon das Phänomen offenbar schon älter ist. Weiterlesen... »