Bots haben das Web übernommen. Das ist nicht neu: Laut dem 2025 Bad Bot Report hatte automatisierter Traffic schon 2024 den menschlichen überholt. Außerdem haben wir uns schon immer dafür interessiert, ob Googlebot und seine per User Agent ihre Identität bekennenden und willkommenen Kollegen unsere Inhalte finden, besuchen und dem Index hinzufügen. Seit KI Crawler das gleiche Spielfeld betreten haben und uns ebenso (in den meisten Fällen) willkommen sind, haben sich zu Tools rund um Insights zu Suchmaschinen inzwischen reichlich neue Quellen ergeben, an denen wir Daten zu Chat GPT & Co. bekommen. Bing Webmaster Tools, Microsoft Clarity, die Google Search Console sind "First Party" Quellen, die allerdings stets nur einen Teil der Story erzählen können. Im komplett neu entstandenen Markt der Prompt- und KI-Rank Tracker wird ebenso versucht, Traansparenz in die eigene Rolle in Antworten und Trainingsdaten zu finden.

Eine der vollständigsten Quellen zu KI-Crawler Daten aber sind die Logfiles des eigenen Servers. Wie diese mit minimalem Aufwand hinsichtlich GPTBot, ClaudeBot, PerplexityBot und anderen unterscht werden und hilfreiche Einsichten generiert werden können, zeigt dieser Beitrag.

Weiterlesen... »

"Sauberes Tagging" ist das Fokusthema meiner täglichen Arbeit. Marketing-Tags sollen feuern, wenn sie dürfen... und sie sollen es nicht, wenn die Zustimmung fehlt. Im Bedarfsfall ist noch der von mir wenig geliebte Advanced Consent Mode im Spiel, Enhanced Conversions, Deduplikation bei hybriden Setups. Zur Kontrolle gehört meistens auch, sich mit den ausgehenden Daten des Browsers zu befassen. Denn: Nur weil ein Tag angeblich gefeuert hat, müssen die Daten nicht genau so wie gewünscht den Browser verlassen haben. Dazu gab es immer schon zwei Wege: Google Tag Assistant für die Google Welt und eine Armee von "Pixel Helper" Extensions für alles andere auf der einen Seite... oder die Kontrolle des Netzwerkverkehrs in den Entwicklertools des Browsers. Leider wird der letztgenannte Weg aber laufend unzuverlässiger: Google Tag Gateway, Bereitstellung über eigene Pfade am server-side GTM oder Custom Loader von Diensten wie Stape, Taggrs und anderen Anbietern machen die Erkennung der Requests - und das Lesen der Parameter - zunehmend schwieriger. Hinzu kommt, dass der eine oder andere Request dort gar nicht auftaucht, weil ein Service Worker den Versand übernimmt. Was tun? Weiterlesen... »

Dieser Post wird so etwas wie ein "Live-Blog", denn Google hat größere und kleinere Änderungen im Google Tag Manager angekündigt, die in mehreren Wellen bei uns ankommen sollen. Da seit ein paar Tagen die ersten Änderungen im User-Interface zu finden sind, plane ich hier meine Einschätzung und evtl. Hilfestellung zur Nutzung bzw. einem evtl. Umstieg auf das kommende neue Format ("gtag statt gtm") zu leisten.

Weiterlesen... »

Wenn Google eine Schnittstelle in den "Wartungsmodus" schickt und gleichzeitig einen glänzenden Nachfolger präsentiert, ist der (erwartete) Reflex ziemlich vorhersehbar: aufmerksam werden, Doku überfliegen, Migration einplanen. Denn nicht nur bei Google Ads Conversions und neuerdings auch Floodlight, sondern auch für Google Analytics soll die neue API die "vereinheitlichte" serverseitige Schnittstelle zur Anlieferung von Daten werden, wenn es nach Google geht.

Daher habe ich mir mein eigenes Experiment von 2022 zur Vermessung von Website-Traffic via Measurement Protocol vorgenommen und geschaut, ob sich a) ein Unterschied in den erzielbaren Daten ergibt und b) wirklich alles, was vorher mit dem GA4MP möglich war, auch mit der Data Manager API funktioniert.

TL;DR

Das selbe Experiment, mit der Data Manager API wiederholt, ergibt im Wesentlichen das altbekannte Ergebnis. Zumindest, was die Attribution angeht. Aber ein 1:1 Ersatz sieht anders aus. Authentifizierung und Latenz des Endpunkts liefern echte neue Herausforderungen.

Hier die lange Fassung für alle, die mehr wissen wollen oder den Einsatz der Data Manager API statt des Measurement Protocols nutzen wollen - vor allem in Grenzfällen, wie ich sie in meiner Serie zum Measurement Protocol seinerzeit beschrieben habe (siehe z. B. Anleitung zum Lifelogging oder für Tracking des Googlebot).

Weiterlesen... »

Wenn man eine Chrome Erweiterung zum Debugging von "Erweiterten Conversions" für Google Ads baut, muss man sich zwangsweise tiefer mit den Nutzerdaten auseinandersetzen, die auf unterschiedlichen Wegen zu Google Ads gelangen können. Einige Fragen, auf die ich zum Beispiel bei der Erstellung des Enhanced Conversion Data Validators gestoßen bin: Kann man tatsächlich eine Straße auch als Hash-Wert statt im Klartext im user_data Objekt übergeben? Wie genau geht Google vor, wenn eine Straße als Klartext in einen Hashwert verwandelt wird? Wie sieht es bei anderen Diensten aus - oder anderen Adressinformationen? Dieser Post liefert Antworten auf diese Fragen und versucht, das Kosten-Nutzen-Verhältnis realistisch einzuschätzen. Weiterlesen... »

Dass Cookies auf dem absteigenden Ast sitzen, ist nichts neues. Ebenso wenig - eigentlich - die Enhanced Conversions für Google Ads, Meta und viele anderen Anbieter, die anhand von E-Mail-Adressen im Klartext oder als Hashwert gern die Lücke im Tracking schließen wollen, wenn keine Referenz in Form einer Klick-ID o. Ä. in einem Cookie zur Hand ist.

Telefonnummern, Namen und Adressen gehören ebenfalls zu diesen Nutzerdaten, die durch Abgleich mit der eigenen Datenbank die Verbindung zwischen Aktion und Ergebnis schaffen sollen. Das kann z. B. der Anzeigenklick bei Google oder Meta im angemeldeten Zustand sein. Findet sich z. B. zu einem an einer Conversion hängenden E-Mail-Hash ein Treffer zu einer Aktion auf der eigenen Plattform, kann der Empfänger (also z. B. Google Ads) den zuvor erfolgten Klick mit der Conversion auch ohne Cookies verknüpfen. Die Umsetzung ist allerdings nicht immer ohne Hürden und Missverständnisse zu erledigen. In diesem Beitrag geht es daher vor allem um die Implementierung und Verifikation von Nutzerdaten für Google Ads. Weiterlesen... »

Wer visuelle Fragen stellt, sollte die Antwort nicht in Tabellen mit Zahlen und Absprungraten suchen. Was im ersten Moment wie eine Binsenweisheit klingt, beschreibt ein Problem, das ich in meiner Arbeit mit Web-Analytics oft sehe: Teams versuchen, mit Google Analytics oder vergleichbaren Tools zu verstehen, warum ein Formular schlecht konvertiert, warum bestimmte Inhalte nicht wahrgenommen werden oder ob ein neues Layout besser funktioniert als das alte. Scrolltracking, Events, Funnels, Absprungraten. Zahlen, die man interpretieren muss - und die dabei erstaunlich oft in die Irre führen.

Microsoft Clarity ist hingegen genau dafür gemacht. Es ist kein Ersatz für Analytics-Tools, sondern eine ideale Ergänzung. Es ist auch nicht der einzige Vertreter seiner Klasse - aber es ist aus mehreren Perspektiven ein besonderes Tool und daher empfehle ich es auch gern.

Weiterlesen... »

Manchmal ist man einfach zu gut im 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.

Weiterlesen... »

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.

Weiterlesen... »

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?

Weiterlesen... »

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.

Weiterlesen... »

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. Aber sollte das auch so sein?

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.

Weiterlesen... »

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... »