Markus Baersch

Nanu, was ist das denn für ein bekloppter Titel? Klären wir es auf: Seit Mitte Mai häufen sich die Anomalien in der geografischen Zuordnung in der Webanalyse, allen voran Google Universal Analytics. Diese äußern sich auf unterschiedliche Weise und sind je nach Zusammensetzung des Traffics unterschiedlich „dramatisch“. Generell verschieben sich Standorte von Besuchern mit Safari Browsern durch eine Änderung in Version 15, die in einer der jüngeren Updates per Default aktiviert ist und welche die IP vor bekannten Trackern schützt.

Im Ergebnis stammen Besucher z. B. gehäuft aus einzelnen Städten wie Köln in einem signifikant wachsenden Anteil oder - wahrscheinlicher - stammen lt. Standort sogar aus den USA. Dabei ist die Sprache des Browsers nach wie vor auf „DE“ eingestellt, was ein deutliches Zeichen dafür ist, dass hier etwas nicht stimmen kann.

Hier ein Beispiel, das ich gestern nach einer diesbezüglichen Frage von Florian Möller im Community Forum zu Simo Ahavas Browser Protection Kurses in den UA Daten einer deutschen E-Commerce Property gefunden habe:

ITP hat wieder zugeschlagen

Die gezeigten Besucher stammen angeblich alle aus dem US Raum, nutzen Safari und sprechen zum größten Teil Deutsch. Schaut man nach mehr Details wie Region / Stadt, erntet man großteilig ein „(not set)“. Zugleich wird die obige Kurve bereinigt, wenn man sich auf dieses Segment konzentriert:

Wie man sieht, setzt der Effekt Mitte Mai ein und steigt dann stetig an. Wer davon in den eigenen Daten nichts sieht, sollte sich nicht zu sicher fühlen, denn ggf. verstecken sich die falsch zugeordneten Besucher nur in einer anderen Stadt.

Wer ist eigentlich dieser "Köln"?

Im folgenden Beispiel aus einer anderen Property sind es zwar hauptsächlich wie erwartet Safari Benutzer aus DE, aber wenn der Ort als zweites Merkmal hinzukommt, stammen auffällig viele aus Köln. Auf diesen Effekt hatte mich Michael Janssen schon Ende Juni hingewiesen, nachdem er in Universal Analytics auf die "wundersame Kölner-Vermehrung" aufmerksam wurde.

Gefiltert für Köln sieht man im Verlauf und den Daten, dass das Unheil mit Version 15.5. seinen Lauf genommen hat.

Wenn Köln also nicht zufällig einen gigantischen Einwohnerzuwachs erfahren hat, muss hier wohl das gleiche passiert sein, was der gute "Herr Dr. Analytics Ninja" (nicht verwechseln mit Dr. Ninja Baljeet!) in seinem Blogpost Ende Juni bereits beschrieben hat: Safari ITP macht hier ganz offenbar Alarm. Warum sich das nicht in allen Konten zeigt und mal US und mal Köln (oder ggf. andere Städte in DE bzw. Europa) rauskommt? Keine Ahnung. Zwar existiert mit Private Relay auf Apple Geräten eine Funktion, mit der sich (zahlende) iCloud+ Abonnenten nicht nur für bekannte Tracker, sondern auch für die besuchte Website selbst eine neue IP aussuchen können, aber da dies nur einen geringen Teil der Safari-Installationen betreffen sollte, muss es eine "allgemeinere" Antwort geben. Und die lautet bei Safari meistens "ITP / Trackingschutz". Die in diesem Kontext als Ursache auszumachende Funktion ist generell nicht neu, sondern schon Ende des vergangenen Jahres in Version 15 (siehe Release Notes) hinzugekommen:

Den meisten Verläufen in Universal Analytics kann man aber unschwer entnehmen, dass der Anstieg des falschen US Traffic oder die Massen-Migration nach Köln etc. erst später eingesetzt (oder besser: wieder eingesetzt; siehe Verläufe unten) hat. Der Löwenanteil kommt mit Version 15.5 daher. Somit sollte die standardmäßige Aktivierung der o. a. Option in dieser Version passiert sein. So sieht das dann z. B. auf dem Mac aus:

In den Release Notes habe ich die genaue Version nicht identifizieren können. Der Verlauf der obigen Kurve passt aber recht gut zur Verbreitung von 15.5. (vorher musste die Option manuell aktiviert werden).

Nicht nur Köln... aber meistens

Ich habe mir mehrere Hundert Properties unterschiedlicher Größe und Ausrichtung angesehen. Ein echtes Muster ist nicht zu erkennen. Nicht alle Domains mit nennenswerten Besucherzahlen via Safari zeigen diesen Zuwachs von (not set) oder einzelnen Städten. Ich habe mir zur Untersuchung per API-Reporting identifizierter Kandidaten ein schnelles Dashboard in Google Data Studio zusammengeklickt, um die Länder und Städte gefiltert für Safari für die letzten 12 Monate zu betrachten. Hier sind ein paar Fundstücke, stellvertretend für verschiedene Klassen von Umschichtungen, die ich in geschätzten 75% der untersuchten Konten in der einen oder anderen Weise gefunden habe.

Dieses Beispiel stammt lustigerweise aus den UA Demodaten von Google und zeigt vor allem Wachstum für "not set". Wenngleich man diesen Daten misstrauen kann: Das Profi habe ich auch in anderen Properties gefunden. Tatsächlich habe ich auch ein Beispiel, wo es nicht Köln, sondern Berlin ist, wohin sich die Besucher verlagert haben:

Hier ist die Visualisierung auf 100% normiert, so dass die Fallzahlen fehlen - es waren mehrere Tausend Besucher pro Monat. Davon gab es mehrere Kandidaten. Hier eine Site, die es besonders hart trifft, weil es eine lokal aus Essen ausgerichtete Site ist. Neben einem Ausfall der Messung zeigt das folgende Diagramm vor allem, wie angeblich kaum noch lokale Besucher kommen; dafür aber Berliner in Scharen. Was sicher nicht stimmt.

In der Schweiz bin ich auf ein Fundstück getroffen, wo Zürich offenbar die Rolle übernommen hat. Zugegeben: Nicht ganz so eindeutig und nur etwa 500 Safari-Besuche / Monat, aber wer eine große Site in der Schweiz untersucht, mag den Trend bestätigen können.

Üblicher ist aber entweder ein Mix aus (not set) und Köln... selbst wenn die Website wie in diesem Beispiel den Fokus nicht auf DE, sondern CH Traffic hat:

Oder eben wie schon zuvor: Köln. Jede Menge davon.

Verlängert man den Zeitraum, sieht man auch einen sehr typischen Verlauf, den in an mehreren Properties gefunden habe: Um den Jahreswechsel mit Verfügbarkeit der neuen Option in Safari (also Version 15) gab es bereits eine Phase mit großer Verschiebung. Das Problem ist also nicht neu, aber hat seit Mitte Mai erneut angezogen.

GDS Report-Vorlage nutzen

Wer sich selbst ein Bild machen möchte, ohne dabei GA zu bemühen, kann der hier verwendete Data Studio Report als Vorlage öffnen, kopieren und das eigene Konto durchsehen. Der Zeitraum von 12 Monaten ist voreingestellt und über ein Datensteuerungs-Element können auch mehrere Konten und Properties schnell durchgesehen werden; Sampling hin oder her. Auf einer zweiten Seite finden sich die gleichen Diagramme zu Land und Ort als prozentualer Anteil der normalisierten Safari-Besucher. Darin sind die Verschiebungen mitunter besonders gut zu sehen, wenn diese sowohl den Wechsel in die USA als auch innerhalb von DE betreffen (offenkundig inspiriert vom oben verlinkten Analytics-Ninja-Artikel).

Ein Umbau für GA4 Properties ist auch schnell erledigt. Wer dabei andere Städte findet: Ich würde mich riesig über eine Abbildung mit Beispieldaten freuen!

Google Analytics 4... (noch) nicht?

Interessanterweise ist GA4 hiervon offenbar (noch) nicht betroffen. Ob das daran liegt, dass die relativ neuen Tracking Endpunkte für EU Besucher (region1.google-analytics.com und region1.analytics.google.com) nur noch nicht davon betroffen sind oder das ein dauerhafter Zustand ist? Schauen wir einfach mal nach: Theoretisch haben es alle „Known Trackers“ in Safari nun schwer. Aber nicht alle gleich - wie es scheint. Ein Tracker ist „bekannt“, sobald dieser auf dem DuckDuckGo Tracker Radar auftaucht, der zur Identifizierung von Trackern in Safari genutzt wird.

Praktischerweise ist dessen Code als Open Source auf GitHub jederzeit einsehbar. Dort findet sich in den Listen ein Eintrag für die o. a. neue Domain ("region1" in den "subdomains"):

Gleiches gilt für die Hosts / Subdomains analytics und region1.analytics im File für google.com. Die Domains sind also bekannt. Auch die Endpunkte für Tracking-Hits sind zu finden (*.google.com/g/collect bzw. *.google-analytics.com/g/collect). Daher sollte GA4 eigentlich ebenfalls betroffen sein - bisher ist aber noch nichts davon in GA4 Reports zu sehen, während die Universal Daten für die gleiche Website den obigen Effekt aufweist. Das mag daran liegen, dass Apple mit einer älteren Fassung arbeitet (die Files waren gerade erst vor 7 Tagen aktualisiert, als ich reingesehen habe), in welcher diese Subdomains noch nicht vorhanden waren. Oder es wird nur ein Teil der Liste genutzt bzw. die Einträge werden anders gefiltert oder anhand der zahlreichen Angaben zur Domain gewichtet – wer weiß? Sicher sollte man sich aber mit GA4 nicht fühlen, solange man keinen eigenen Endpunkt nutzt und sich von Standard-Trackingcodes bzw. deren üblichen Quellen frei macht (siehe unten).

Warum ist das doof?

Hauptsächlich deshalb, weil je nach Filtern oder Segmenten, die US Traffic vom Rest trennen, nun so unsicher sind, dass man damit faktisch nicht mehr arbeiten kann. Das Verschieben in einzelne Städte, das nicht nur durch den ITP Standard Trackingschutz von Apple nun deutlich angezogen hat, sondern zusätzlich durch „Private Relay“ in iCloud+ auf nutzenden Geräten zusammen mit bereits bestehenden Herausforderungen wie VPN etc. die „Verortung“ erschwert, kann je nach Report und Nutzung der Daten problematisch sein. In der Webanalyse ebenso wie in Werbesystemen oder auf der Website selbst, wenn anhand der IP z. B. bestimmt wird, wo Besucher auf einer internationalen Website einsteigen bzw. welche Inhalte zu sehen sind. Zudem ist (mir) unklar, wie oft eine solche IP wechselt.

Was kann man tun?

Ist das eigene System betroffen, muss man entweder damit leben oder muss aktiv werden. Das mag der ohnehin anstehende Wechsel des Tools sein – wie o. a. ist zumindest aktuell selbst GA4 noch unbetroffen... oder es wird auf andere Weise vermieden, als „Known Tracker“ erkannt zu werden, indem die Sammlung von Daten im Browser und / oder der Endpunkt ausgetauscht werden.

Alternativen in der Cloud: Eine Frage der Zeit

Mit einem Umstieg „von der Stange“ auf GA4 ist m. E. allerdings aus oben gezeigtem Grund eher kurz- als mittelfristig damit zu rechnen, dass der gleiche Effekt eintritt. Apple hat es schlussendlich selbst in der Hand und ITP (und damit auch diese Funktion) wird sich laufend weiter entwickeln. In anderen Tools wie Piwik PRO oder Matomo (zumindest wenn selbst gehostet) mag der individuelle Endpunkt längerfristig „sicher“ vor dieser Maßnahme sein… muss es aber nicht. Der Beweis findet sich z. B. im Eintrag zur Domain piwik.pro in DE (Listen werden nach Ländern bzw. lokalen DuckDuckGo Quellen gehalten). Hier zeigt sich bei den "subdomains" ein Auszug aus der Kundenliste, die durch die Systematik der individuellen Hosts je Account entsteht (die meisten geben Ihrem Account nun mal einen erkennbaren Namen):

Noch sind es also in DE derzeit nur 7 von x Kunden, die potentiell unter Trackingschutz in Safari oder durch die DuckDuckGo Apps mehr leiden als andere. Hase und Igel. Diese Liste wird laufend wachsen.

Matomo? Selbst gehostet und damit mit eigenem Endpunkt recht sicher. In der Cloud hingegen nicht mehr als Piwik PRO, denn für die Domain matomo.cloud läuft das gleiche Spiel. Daher auch hier eine ungewollt entstehende (freilich unvollständige) Liste deutscher Kunden im Tracker Radar Code:

Ebenso wenig sicher sind kleinere Tools, die nur wegen der geringen Anzahl der nutzenden Websites noch unter dem Radar fliegen. Nicht mal bei Plausible ist man seiner IP noch sicher (wieder nur DE):

Und wie man sieht, nutzt die CNAME Zauberei bei Red Bull da (wie oben bei Matomo ebenso) nichts: aus pm.redbull.com ist schnell custom.plausible.io hervorzuzaubern. Darauf fällt heute kein Browser mehr rein und folgerichtig auch nicht der Tracker Radar.

First Party Tracking!

Mit einem serverseitigen GTM oder eigenem Endpunkt als Proxy ist spätestens bei Verzicht auf analytics.js oder andere Standard-Scripts nach akt. Stand nicht viel zu befürchten, wenn es um dieses spezielle Problem geht… wenn man dabei zudem möglichst Muster umgeht, die „nach Tracking wie auf anderen Websites auch“ aussehen. Da kann ggf. selbst ein individueller Cookie Name schon helfen. Die Verwendung eines eigenen Tracking-Endpunkts allein unter Beibehaltung anderer Muster (wie Quelle der Tracking-Scripts oder des clientseitig geladenen Google Tag Managers) scheint hingegen kein Garant zu sein, dieses Problem zu umgehen. Auch in solchen Setups sind die oben beschriebenen Effekte zu finden. Je mehr Besuche auf Apple Geräten (oder mit dem BuckDuckGo Browser) stattfinden, desto größer wird das Problem ausfallen. Weitere Browser können jederzeit nachziehen, wann immer ihnen danach ist.

Auf der Haben-Seite: Es gibt einen Ausweg, wenn das Problem so große Auswirkungen auf die eigenen Analysen hat, dass der Aufwand gerechtfertigt ist. Oder damit nun die Waage in Richtung einer aus anderen Gründen bisher aufgeschobenen Errichtung eines robusten First Party Setups kippt. Je individueller dabei die Sammlung von Daten im Browser, Bereitstellung der dazu erforderlichen Scripts, Persistenz / Cookies und Endpunkt ausfallen, desto robuster wird ein First Party Tracking Setup sein.

Warum überhaupt Browser-Trackingschutz umgehen?

Solange man Tracking bzw. Measurement (ich sehe da einen Unterschied) nur dann ausspielt, wie es die Zustimmung (oder Gestaltung der Datenschutzeinstellungen des Tracking Tools) datenschutzkonform erlaubt, ist nichts dagegen einzuwenden, wenn man sich Browser-Trackingschutz-Maßnahmen in den Weg stellt. Wir haben ja schon denjenigen gefragt, um dessen Daten es geht. Bevormundung durch den Browser ist an dieser Stelle also sowohl unnötig als auch kontraproduktiv. Solange aber Browser unterschiedliche Maßnahmen nutzen und das Einholen und Speichern von Zustimmung in einer Vielzahl vollkommen verschiedener Tools und Formate geschieht, ist ein koordiniertes "Hand-in-Hand" von Browser und Consent Tool nicht zu erwarten. Sich bis zu einem gewissen Grad vor den Hürden zu wappnen, die der Browser auch für ein Tracking mit Zustimmung errichtet, bleibt deshalb einstweilen die einzige Option... neben dem Ignorieren der immer weiter steigenden Effekte oder dem Vertrauen darauf, dass Machine Learning die Lücke im Reporting schließt.

IP als Merkmal: Jetzt noch mieser

Mit dieser Verschärfung von ITP ist die IP-Adresse als Merkmal zur Standortbestimmung nochmals deutlich unzuverlässiger geworden. Das gilt gleichfalls für die Bildung von Ersatz-Identifiern im "cookielosen" Tracking unter Verwendung der IP. Wie oft mag die IP wohl aus Sicht eines bekannten Trackers wechseln? Ob so schon mitten in der Session ein Hash aus IP und dem ebenso anfälligen User Agent den Kontakt zwischen zwei Seitenaufrufen verliert? Ich will es zumindest nicht ausschließen.

Gegen Private Relay, VPNs & Co. ist zudem ohnehin kein Kraut gewachsen. Hier auf andere Merkmale wie die Sprache oder in eigenen Dimensionen hinterlegten (bekannten) Standort zu setzen, ist dann die einzige Option. Glücklicherweise ist der Effekt dieser Maßnahmen aber i. d. R. deutlich geringer im Vergleich zum oben beschriebenen neuen Effekt von ITP, wo es bisher hauptsächlich um die Wiedererkennung anhand von Klick-IDs, Cookies und Browserspeicher ging. Hach, war das noch schön… 😐