Gleich vorab: Eine definitive Antwort auf alle Fragen in diesem Zusammenhang habe ich (noch) nicht. Aber zumindest genug für einen ersten und vergleichsweise kurzen Blogpost. Spät genug, denn Safari 13 mit ITP 2.4 - dem weiter verschärften Trackingschutz - ist schon seit Ende September verfügbar. Darin geht es vor allem wieder um bekannte Tracking Domains und das, was sie tun dürfen. Neben dem "Verstümmeln" des Referrers bei solchen Domains (was nachvollziehbare Gründe hat) geht es erstmals unter bestimmten Umständen neben Cookies auch localStorage und IndexedDB an den Kragen. Welche Werte sind betroffen und unter welchen Umständen? Hier gibt es erste Ergebnisse meiner Tests... ("fertig" bin ich aber noch nicht). Weiterlesen... »

Mit Edge auf Chromium-Basis kommen Neuerungen, die dem Browser vielleicht tatsächlich neues Leben einhauchen könnten. Darunter ist ein eigener Trackingschutz. Betrachten wir die neue Version als Zukunft des aktuellen Marktanteils von Edge und Internet Explorer, bekommt damit auch der Dritte der drei größten Browser etwas Vergleichbares zu ITP in Safari bzw. ETP in Firefox.

Wie funktioniert dieser Trackingschutz und welche Auswirkungen hat er? Steht auch hier die Webanalyse auf der Kippe oder betrifft der Trackingschutz nur Drittpartei-Cookies? Ein Blick auf die Beta zeigt zwar nur einen vorläufigen Stand, aber im Licht der derzeitigen Entwicklung im Kampf von Browsern gegen Tracker ist er m. E. dennoch sinnvoll. Im Sinne rechtzeitiger Vorbereitung 🙂

TL;DR: Implementierung und Ergebnis erinnern an ETP in Firefox, aber es gibt Unterschiede. Derzeit bleiben Google Tag Manager und das Tracking via Google Analytics voll nutzbar. Details? Gern.

Weiterlesen... »

Alle Browserhersteller (selbst in gewissem Umfang Chrome) erschweren das Tracking von Besuchern auf die eine oder andere Weise. Wenngleich das keine neue Entwicklung ist, hat das Thema mit ITP in Safari, ETP in Firefox und der neuen Beta von Edge jüngst einiges an Fahrt aufgenommen. Daher soll dieser Beitrag einen Über- und Ausblick geben, in welchem Maß und Umfang verschiedene Trackingmechanismen beeinflusst werden und welche Herausforderungen sich Anbietern und Nutzern von Tools im Trackingumfeld stellen - und stellen werden. Dabei geht es nicht nur, aber auch um Google Analytics und den Tag Manager.

Ausnahmsweise wird dies kein "Nerdbeitrag" und der Tech-Part bleibt auf ein notwendiges Minimum beschränkt. Davon habe ich schon einige geschrieben und es folgen auch weitere. Links zu passenden Beiträgen werden für den technisch Interessierten enthalten, aber nicht zum Verständnis erforderlich sein. Wer nach diesem Disclaimer noch Bock hat, darf gern weiterlesen 😉
Weiterlesen... »

Hinweis: Dieser Beitrag aus dem Jahr 2019 beschreibt ein sehr spezifisches Phänomen in Universal Analytics: falsche Absprungraten über 100% im Bericht "Alle Seiten", verursacht durch Non-Interaction-Events nach einem Session-Timeout. Mit dem Ende von Universal Analytics im Juli 2023 ist der Beitrag ein Zeitdokument - die Absprungrate in GA4 ist grundsätzlich anders definiert (als Gegenstück der Engagement-Rate, also "1 minus Engagement-Rate"), wird nur über die API geliefert und folgt nicht mehr der Logik "Einstieg = Ausstieg ohne Interaktion". Die beschriebene Rogue-Events-Dynamik existiert in GA4 so nicht mehr. Wer sich heute mit Engagement und Absprungraten in GA4 befasst, findet Kontext in den Besonderheiten in Google Analytics 4.

Am Anfang stand die harmlose Frage eines Kunden nach den Gründen dafür, warum die Absprungrate im Bericht “Alle Seiten” in Google Analytics für einzelne Seiten eine Absprungrate von über 100% - also z. B. 150%, 200% oder auch andere Werte - ausweist.

Schon aus Routine habe ich die üblichen “bekannten Gründe” abgeklopft und den verbleibenden Rest als Antwort gegeben: Es liegt an Sitzungen, die “eingeschlafen” sind und daher mit Events statt Seitenaufrufen neu anfangen. Das stimmt glücklicherweise auch. Aber wie genau ist der Ablauf, der zu diesem Effekt führt? Kann man das nachstellen - und so ggf. auch vermeiden? Wie ist mit solchen Zahlen umzugehen? Ich habe es mir genauer angesehen. Weiterlesen... »

Update 09/2019: Anfang des Monats wurde Version 69 veröffentlicht. Hiermit ist der unten beschriebene Trackingschutz nun nicht nur in Neuinstallationen, sondern für alle Benutzer in der Standardeinstellung aktiviert. Er betrifft aber nach wie vor "nur" die hier im Beitrag genannten sekundären Funktionen wie demografische Daten etc. Das Tracking-Script selbst und auch die First Party Cookies von Google Analytics werden im Standard nicht blockiert.

Mit dem aktuellen Release 67.0.1 von Firefox Quantum... "ist Trackingschutz nun Default", "wird die Webanalyse verhindert" oder "Google Analytics blockiert". So oder ähnlich lasen sich jedenfalls die Schlagzeilen der letzten Tage. Ein paar schnelle Tests, was genau nach der Installation der neuen Version passiert und ich war erst einmal sicher: Es passiert gar nichts, alles läuft wie gewohnt. Das ist aber auf den zweiten Blick nicht die ganze Wahrheit. Wie immer "kommt es darauf an". Dazu gleich mehr.

Mein Fazit zum aktuellen Stand vorab: Das grundlegende Tracking von Google Analytics und alles andere, was mit First Party Cookies zu tun hat (also auch andere Systeme) sind nicht von diesem Update betroffen. Anders als bei ITP ist es dabei (einstweilen) egal, ob es sich um HTTP-Cookies oder per JavaScript im Browser erzeugte Cookies handelt. Es gibt aber auch im Google Analytics Funktionsumfang Dinge, die auf Third Party Cookies basieren. So sind zumindest bei einer Neuinstallation von Firefox die Werbefunktionen und Remarketing via Analytics betroffen, da diese von weiteren Cookies abhängen, die in der Standardeinstellung nicht mehr verarbeitet werden können.

Weiterlesen... »

Kurze Antwort: Nein.

Warum ich mich das überhaupt gefragt habe? Weil laut der Beschreibung im Chromium Blog "Google Server" im Spiel sind (wie auch sonst), die die Seiten optimieren und faktisch in veränderter Form ausliefern. Aber: Tun Sie das wie ein Proxy oder CDN oder ändert sich - wie im Fall von AMP - etwas am Tracking und den Rahmenbedingungen wie dem Host, der URL der Seite etc?

Damit in diesem Blogbeitrag dennoch etwas mehr Nutzen herauskommt als die kurze Antwort oben, beschreibe ich kurz meinen Weg zum "Nein", denn das Debugging von mobilen Seiten in Chrome auf einem Android Gerät mag dem einen oder anderen in ähnlichen Fällen helfen. Weiterlesen... »

Hinweis: Mit der bei ITP inzwischen verwendeten, relativ willkürlich erscheinenden Definition von "First Party" sind die Spielregeln über die Jahre weiter verschärft worden. Wenn ein Cookie von einem Server gesetzt werden soll, der nicht in der ersten Hälfte der IP mit dem Server der besuchten Website übereinstimmt, gilt es als "fremdes" Cookie und ist den - ebenso inzwischen in Details veränderten - Spielregeln von ITP unterworfen. Dieser Austausch zwischen Trackingschutz und Trackinganbietern wird auch nie enden. Dennoch markiert speziell die Version 2.1 von ITP einen besonderen Wendepunkt, wenn es um Schutzmaßnahmen geht, die sich vor allem gegen Wiedererkennung und Profilbildung richten und nicht generell "Tracking verhindern" wollen. Diesen Punkt sollte man ITP zu Gute halten.

ITP ("Intelligent Tracking Prevention") als Schutz vor Tracking durch Drittparteien und domainübergreifende Profilbildung in Safari Browsern ist prinzipiell eine gute Idee. Das sage ich selbst als jemand, der in der Rolle eines Marketers bei Google Ads & Co. auf so erhobene Daten in gewisser Weise angewiesen ist. Aber was Safari mit der neuen Version 2.1 von ITP einführen wird, geht deutlich über diese ursprüngliche Intention hinaus. Im Kern werden dabei First Party Cookies, wie sie für die Webanalyse (und deren Opt Out! - siehe unten), Testing, Personalisierung und viele andere Funktionen jenseits von Tracking durch Dritte oder Profilbildung genutzt werden, auf eine Lebensdauer von 7 Tagen begrenzt. Mit Folgen für alle o. a. Systeme. Das ist nicht gut. Was alles betroffen ist und was man tun kann, um die Effekte abzumildern, zeigt dieser Beitrag. Weiterlesen... »

Hinweis: Dieser Beitrag stammt aus Januar 2019 und beschreibt einen neuen Check für doppelte Transaktionen im damaligen UA-Audit bei analytrix.de. Mit der Abschaltung von Universal Analytics im Juli 2023 ist der seinerzeit verlinkte UA-Beispielreport nicht mehr nutzbar. Der Check selbst ist in das GA4-Audit uebergegangen und untersucht dort weiterhin Fundstellen doppelt gemessener Transaktionen.

Die mehrfache Messung von Transaktionen in einem Shop kann mehrere Ursachen haben. Im einfachsten Fall wird die Bestätigungsseite eines Shops neu geladen und führt dann nicht zum leeren Warenkorb, sondern enthält nochmals alle Daten der Transaktion, die dann ein zweites Mal an die Webanalyse gesendet wird. Auch in AJAX-Checkouts kann es - vor allem im Zusammenspiel mit dem Google Tag Manager - schnell passieren, dass Transaktionen mehrfach gemessen werden.  Weiterlesen... »

Als ich vor ein paar Wochen erstmals den Namen "Nacho Analytics" gehört hatte, bin ich sowohl neugierig als auch skeptisch geworden. Das Tool verspricht dem Nutzer, in "jedermanns Analytics" schauen zu können. Einfach so. Revolutionäre Idee, mega-innovativ, Blabla.

Zugegeben: Kaugummigestützt aus "Not Your Analytics" ein "Nacho Analytics" zurechtzunuscheln, ist schon mal eine kreative Idee (die nur ein Amerikaner haben konnte). Und die verfügbaren Daten in Analytics zu versenken, klingt im ersten Moment auch nicht dumm. Aber steckt mehr dahinter, als durch pluginverseuchte Browser gesammelte Daten wie im Fall von SimilarWeb? ich wollte es wissen und habe nach längerer, durch gutes Marketing und schlechte Skalierung beim Anbieter ausgelöster Wartezeit einen kurzen Test gemacht, um mir einen Eindruck zu verschaffen.  Weiterlesen... »

Hinweis: Dieser Beitrag stammt aus August 2018 und aktualisiert die Zahlen aus der Spam-Studie auf Basis von Universal-Analytics-Daten und Events aus dem Spam-Check bei analytrix.de. Sowohl UA als auch der Spam-Check wurden mit der Abschaltung von Universal Analytics im Juli 2023 eingestellt. Das Ghost-Spam-Phänomen war eine UA-Eigenheit und existiert in Google Analytics 4 in dieser Form nicht mehr. Der Beitrag bleibt als Zeitdokument erhalten.

Anfang des letzten Jahres habe ich unter der Überschrift "ist Spam besiegt?" erstmals Zahlen zum Volumen von Spammern und Opfern, dem Anteil von Spam im Verweistraffic und der zeitlichen Entwicklung von Spam in Google Analytics veröffentlicht. Die Zahlen basierten auf der massenhaften Auswertung der Verweise für alle mir zur Auswertung selbst zur Verfügung stehenden Analytics - Properties von eigenen Websites und den Sites betreuter Kunden.

Diese Untersuchung habe ich seitdem monatlich fortgeführt. Zudem habe ich vor einiger Zeit damit begonnen, den Anteil an Spam im Verweistraffic als Event zu messen, wenn eine Spamanalyse mit Analytrix durchgeführt wurde - freilich ohne Bezug zur untersuchten Property oder gar Domain; nur den ermittelten Gesamtanteil an Spam, um eine von "meinen" Daten unabhängigere Messung zu ermöglichen. Hier nun zu beiden Methoden ein paar Zahlen als Update zur "Studie" aus dem letzten Jahr. Weiterlesen... »

Hinweis: Dieser Beitrag stammt aus Juli 2018 und zeigt eine customTask-Lösung für Universal Analytics, die die Zuordnung des organischen Traffics bereits im Browser vor dem Senden der Hits korrigiert. Weder der customTask noch die "Quellen der organischen Suche" in den Property-Einstellungen existieren seit der Abschaltung von Universal Analytics im Juli 2023 noch. Google Analytics 4 hat das Keyword-Konzept komplett abgeschafft und klassifiziert Suchmaschinen über Custom Channel Groups mit einer anderen Logik. Das hier gezeigte Verfahren funktioniert nicht mehr; der Beitrag bleibt als Zeitdokument erhalten.

Kommen Besucher über Google oder Bing auf die eigene Website, ist dies in Google Analytics problemlos dem Kanal des organischen Traffic zuzuordnen. Und auch für viele andere Suchmaschinen funktioniert dies - die Liste der unterstützen Quellen ist lang... leider aber auch sehr alt. Schon bei den internationalen Fassungen von Yahoo hört der Spaß auf und lokale Quellen wie Suchfunktionen bei T-Online oder web.de landen ohne Eingriff in die Konfiguration im falschen Topf. Dieser Beitrag zeigt eine Lösung, die mit einmaligem und überschaubarem Aufwand für eine Korrektur sorgt.
Weiterlesen... »

Hinweis: Dieser Beitrag stammt aus Juli 2018 und zeigt eine GTM-Lösung zur Messung von SERP-Bounce und Dwell Time mit Universal Analytics: Timing-Tags, Ereignis-Ziele und einen berechneten Messwert auf Datenansicht-Ebene. Seit der Abschaltung von UA im Juli 2023 existieren weder die Timings-Reports noch die berechneten Messwerte in dieser Form; Google Analytics 4 hat ein komplett anderes Event- und Conversion-Modell. Die grundsätzliche Idee (History-basierter Messpunkt beim Eintritt aus den SERPs) ließe sich in GA4 als benutzerdefiniertes Event nachbauen, ein Copy-Paste-Rezept ist dieser Beitrag aber nicht mehr. Der Beitrag bleibt als Zeitdokument erhalten.

So sperrig, wie der Titel es vermuten lässt, ist das Thema diesmal wirklich. Mir ist aufgefallen, dass ich die Anleitung zur Messung eines Teils der vielzitierten "User Signals" aus "Sicht" der Google Suchergebnisse bisher noch nicht verbloggt habe, sondern diese nur in Form der Session - Folien zur CAMPIXX 2018 (ab Folie 31) zu haben ist. Da hier die fehlende Tonspur eine eigene Umsetzung nicht wirklich einfach macht, liefere ich diese hier für alle nach, die das erweiterte Rezept zur Messung der SERP Bounce Time von Simo Ahava selbst implementieren wollen.  Weiterlesen... »

Exit Intent Banner sind nicht immer und überall eine gute Idee. Dennoch mag es im Einzelfall zumindest sinnvoll sein, den Versuch des Verlassens einer Seite in der Webanalyse zu vermerken. Und sei es nur zur "Verbesserung" der Messung der Verweildauer auf einer Landingpage... solange es dann wenigstens als Ersatz für stumpf implementiertes und gern direkt schon beim Seitenaufruf erste Events feuerndes Scrolltracking dient 😉
Weiterlesen... »

Hinweis: Dieser Beitrag entstand im April 2018 und dokumentiert eine Testreihe gegen Universal Analytics Properties. Seit Juli 2023 ist UA abgeschaltet, die gezeigten Datenansichten, Filter und Screenshots gibt es in dieser Form nicht mehr. Die Kern-Erkenntnisse - dass einige Crawler aktiv Tracking-Scripts blocken und andere nicht, und dass Filter nur gegen eigene Testcrawls helfen - sind als Prinzip weiter gültig. Wer heute rendernde Crawler aus den eigenen Daten halten will, findet einen aktuellen, tool-übergreifenden Ansatz im Beitrag zur serverseitigen Erkennung rendernder Bots. Der Beitrag bleibt als Zeitdokument erhalten.

Auf der CAMPIXX habe ich in Diskussionen im Anschluss an mehrere Sessions gehört, dass die Untersuchung der eigenen Website mit Tools wie dem Screaming Frog SEO Spider zunehmend Spuren in der Webanalyse hinterlässt, seit deren Crawler in der Lage sind, nicht nur den Quelltext einer Seite herunterzuladen und zu analysieren, sondern auch wie ein normaler Browser zu rendern. Ganz nach dem Vorbild von Google.

Aber stimmt das wirklich? Als “Webanalyse-Spam-Fan” bin ich darauf natürlich angesprungen und wollte es genauer wissen. Für eine Antwort muss also überprüft werden, ob sich in Google Analytics Hits nachweisen lassen, die durch Crawl-Vorgänge mit gängigen SEO- und OnPage-Tools entstehen, wenn deren Crawler die untersuchten Seiten auch rendern und nicht nur den Quellcode abrufen. Weiterlesen... »

Hinweis: Dieser Beitrag stammt aus Februar 2018 und zeigt, wie interne Besuche auf WordPress-Sites über ein dataLayer-Plugin + GTM + Custom Dimensions in Universal Analytics markiert und per Datenansicht-Filter ausgeschlossen werden. Seit Juli 2023 ist UA abgeschaltet, die hier gezeigten Filter auf Datenansichten und die Custom-Dimension-Indizes gibt es so nicht mehr. Das beschriebene WordPress-Plugin und die dataLayer-Signale (wp_utype, wp_aut etc.) funktionieren aber weiter und lassen sich in GA4 über Event-Parameter, User Properties und Audiences analog nutzen. Der Beitrag bleibt als Zeitdokument erhalten.

Knapp 40% aller Websites weltweit werden mit WordPress betrieben. Deren Betreiber nutzen in großer Anzahl Google Analytics zur Auswertung des Besucherverhaltens. Kein Wunder also, dass es zahlreiche Plugins rund um Integration, Reporting, Verfeinerung der Messung durch Events, E-Commerce-Transaktionen etc. gibt. Das Angebot wird dünner, wenn man sich um hiesige Besonderheiten wie IP-Anonymisierung, erweiterte Opt-Out-Funktionen oder den Dank der Anonymisierung nicht mit den üblichen IP-Filtern zu erledigende Ausschluss interner Besucher geht. Daher müssen wir uns auf verschiedenen Umwegen um Kennzeichnung interner Besucher bemühen, damit es etwas zu filtern gibt. Einen Überblick über einige Lösungen habe ich vor einiger Zeit unter www.gandke.de/ga-marker veröffentlicht, wo es auch einige Plugins für verschiedene Systeme - einschließlich WordPress - gibt.

Anreicherung des dataLayer für WordPress-Sites

Für eine vergleichsweise "kleine" Website mit einem oder wenigen Webmastern/Autoren habe ich im Sinne einer möglichst simplen Lösung ein weiteres Plugin erstellt, das im Zusammenspiel mit dem Google Tag Manager die Markierung anhand des Anmeldestatus ermöglicht. Davon ausgehend, dass i. d. R. genau dann viel "Datenmüll" entsteht, wenn man an der eigenen Website arbeitet und sonstige Aufrufe eher nicht ins Gewicht fallen, reicht dieses Merkmal vollkommen aus, um überflüssige selbstgemachte Hits ausreichend gut aus der Webanalyse zu filtern. Nebenbei wird der dataLayer des Tag Managers um ein paar weitere Informationen wie Autor, Monat und Jahr des Beitrags, Kategorien und Tags angereichert, um diese ebenfalls z. B. als benutzerdefinierte Dimension an Google Analytics zu senden.
Weiterlesen... »