Markus Baersch

Dies ist der dritte Teil der Serie rund um Tracking, Cookies und (viel Unbelastbares zum) Consent. Nach den grundsätzlichen Problemen mit der Identifizierung von Besuchern und cookielosem Betrieb von Analytics steht diesmal der serverseitige Einsatz Tracking mit Google Analytics und dem Measurement Protocol. Vor allem im Hinblick auf Tracking ohne Consent erscheint diese Variante offensichtlich attraktiv; ist sie doch bei entsprechender Gestaltung für eine von außen "unsichtbare" Vermessung der Websitenutzung geeignet. Aber ist sie in diesem Fall auch im Sinne der geltenden Reglementierungen auch nutzbar?

Das kleine Disclaimerchen

Der hier gezeigte Weg wird weder unsichtbar sein, noch geht es um die Sammlung am Wunsch des Besuchers bzw. Gesetzgebers vorbei. Auch so bleibt der serverseitige Einsatz vor allem im Zusammenhang mit einer ggf. fehlenden Zustimmung eine verlockende Option... die hier primär aus technischer Sicht und mit Machbarkeit im Fokus beleuchtet wird. Das beinhaltet ausdrücklich keine Empfehlung, es genau so zu machen, wie es hier beschrieben wird. Ist es ein Weg zum Tracking ohne Consent? Diese Frage wird hier trotz vieler Wörter nicht beantwortet werden (können). Sorry. Aber zumindest die, was man tun kann und wie es zu nutzen ist.

Man kann den Umfang des Trackings aber so reduzieren, dass selbst die typischen Vorbehalte gegen Google als Datenspeicher (denn mehr passiert hier bei korrekter Reduktion der Informationen nicht mehr) m. E. nicht mehr zum Tragen kommen. Ein Verzicht auf personenbezogene Daten ist umsetzbar, solange das Thema der Identität gelöst ist. Im schlimmsten Fall bleiben also nur noch Hits ohne die zusammenfassende Klammer einer Sitzung übrig. Auf der anderen Seite des Pendels kann ich aber deutlich mehr an Google übertragen, selbst eine ungekürzte IP würde ja keiner mehr "sehen". Insofern kann dieser Beitrag nicht nur technische Aspekte ansprechen, sondern kommt an ein wenig Ethik nicht vorbei. Trotzdem viel Spaß beim Lesen!

"Serverside Tagging": Serverseitiges Tracking, clientseitiges Auslösen?

In vielen Systemen ist eine "komplett serverseitige" Nutzung von Analytics problemlos nachzurüsten. Für WordPress gibt es sogar passende Plugins, sowohl zum Tracking von Bots als auch für reale Besucher. Solche Lösungen nutzen ebenso das Google Analytics Measurement Protocol, mit dessen Hilfe man Daten auch ohne Browser und den klassischen Trackingcode an Analytics senden kann. Von Herausforderungen wie Caching etc. abgesehen werden aber i. d. R. "nur" Seitenaufrufe vermessen. Oder Transaktionen, wenn das Tracking auf ein Shopsystem abgestimmt ist.

Typisches Tracking umfasst aber mehr als Event oder auch virtuelle Seitenaufrufe. Vor allem bei Einsatz des GTM gibt es fast unbegrenzte Möglichkeiten, bestimmte Aktionen oder Abfolgen nach sehr ausgefeilten Triggerbedingungen zu vermessen. Serverseitige Varianten von Tracking, das dennoch vom Browser aus per Script ausgelöst wird (oder Hybridlösungen aus beidem), schließen diese Lücke. Dazu finden sich auch Anleitungen auf Github zum Einbau in das eigene System oder das Ausspielen mit Hilfe von Systemen wie Cloudflare. Je nach eigenen Bedingungen gibt es also vermutlich einfachere und / oder komfortablere Möglichkeiten. Sie sind aber meistens auf ein bestimmtes System reduziert.

Daher geht es in diesem Beispiel um einen Ansatz, der zwar serverseitig das Tracking ausführt (also auf den Google Analytics Trackingcode verzichtet), aber dennoch (genau wie beim normalen Tracking) vom Client per Javascript "getriggert", also ausgelöst wird. Bei Seitenaufrufen, ausgewählten Events; was auch immer. Damit bleibt nach wie vor JavaScript im Spiel, nur wird kein Analytics-Tracking mehr aufgerufen, sondern ein Tracker, der auf dem eigenen Server "gehostet" wird. Das klingt nach mehr, als schlussendlich dahinter steckt. Eine PHP Datei muss dort abgelegt werden. Oder er wird auf einer anderen Plattform gehostet und (per CNAME als Subdomain der eigenen Domain) betrieben werden. Sonst bekommen wir potentiell wieder irgendwann vom Browser ausgelösten Ärger mit dem Laden "externer" Ressourcen.

Dieser "Logger" gibt die Daten dann serverseitig an Google Analytics weiter. Durch die Nutzung des "eigenen Trackers" bleibt von außen nicht ersichtlich, in welcher Form und welchem Umfang ein eigenes Tracking stattfindet. Die Technologie hinter der Funktionalität auf dem eigenen Server ist auch theoretisch beliebig austauschbar. Meint: Es kann, muss aber kein Analytics genutzt werden, um die Trackingaufrufe weiterzuverarbeiten. Versenken in einer eigenen Datenbank, Versenden an ein ganz anderes System (oder mehrere): das ist in der Praxis nur davon abhängig, was der eigene Tracker (oder besser: die selbst betriebene "Trackingbrücke") damit macht.

Damit unterscheidet sich der hier gezeigte Ansatz prinzipiell nicht von dem, was man mit einem serverside Google Tag Manager anstellen kann. Serverside Tagging wird aus diesem Konstrukt aber streng genommen erst dann, wenn die empfangenen Daten aus dem Browser nicht nur an einen einzigen Empfänger wie Google Analytics, sondern auch andere gesendet wird. Dazu gehört im serverside GTM z. B. gern auch Google Ads, die Facebook / Meta Conversions API oder andere Dienste.

Äh... Google Analytics? Füttern wir dann nicht doch wieder die Bösen?

Ich kann die Frage nachvollziehen. Und leider nicht beantworten, ob und unter welchen Voraussetzungen sich der Einsatz von GA vom Server aus dazu eignet, ein Ersatztracking aufzubauen, wenn kein Consent besteht. Ganz bestimmt hängt dies auch wieder vom Faktor der "Identitätsgewinnung" ab, um die es auch in den letzten beiden Teilen - zurecht - ging. Aber jenseits dieser offenen Fragen ist ein "Entkoppeln" von Analytics und dem Browser mehr als nur ein technischer Aspekt.

Wo die cookielose Variante nur die Identität selbst in die Hand nimmt und alles andere wie vorher weiter läuft, ist bei Einsatz des Measurement Protocols auch jeder andere "Informationskanal" wie der Abruf der Scripts oder Sammlung von Merkmalen des Clients abgekoppelt. Es kommt nur das in Analytics an, was man selbst dorthin sendet. Aus Datenschutzsicht bedeutet dies, das die Kontrolle dessen, was an den Betreiber fließt, voll in der Hand des Senders liegt. Hier die entsprechende Sorgfalt vorausgesetzt, sind die Daten soweit reduzierbar, dass sie vermutlich nicht einmal mehr unter die DSGVO fallen. Problemstellen wie Mailadressen oder andere Daten in URLs sind schon vor dem Versand zu beheben. Im Extremfall verzichtet man zudem auf den User Agent (oder reduziert diesen vor der Übertragung) und sendet jeden Hit mit einer neuen, zufälligen Client ID, wenn sich herausstellt, dass deren Beibehaltung während einer Session auch schon zu viel sein sollte. Weil die dadurch entstehenden Daten nicht mehr sind, als Logfiles - ohne IP Adressen, sollte damit also sogar die Sonderstellung, die Google im Hinblick auf Datenschutz, Profilbildung & Co. einnimmt, nicht mehr ins Gewicht fallen. Kann und darf man z. B. eine Session-ID verwenden, um nur für die Dauer eines Besuchs ein gemeinsames Merkmal für die Hits zu schaffen, das nach dem Besuch weder Rückschlüsse auf die Herkunft noch andere bestehende oder künftige Sitzungen erlaubt? Wenn die Antwort "Ja" lauten sollte (was wir alle hoffen), dann bleibt schon eine ganze Menge Webanalyse übrig. Grundsätzlich ist das hier gezeigte Prinzip aber auch mit anderen Empfängern der Daten umsetzbar.

Am Anfang steht wieder: Identität

Wollen wir mehr als separate Hits sammeln, brauchen wir auch hier Identität. Die Herausforderungen sind im ersten Teil, konkrete Lösungsbeispiele zur Generierung und Weitergabe an ein Trackingsystem im zweiten Teil behandelt. Da auch das serverseitige Tracking weiter vom Client gesteuert werden soll, können die gleichen client- oder serverseitigen Komponenten zur Identitätsverwaltung und -weitergabe genutzt werden. An die Stelle des modifizierten Trackingcodes aus Teil 2 tritt hier allerdings ein Aufruf eines Trackers auf dem eigenen Server. Nicht vergessen: Der Nutzen steht und fällt mit der Eindeutigkeit und Lebensdauer der Identität. Dazu kommen wir später noch einmal zurück, wenn es um die Vor- und Nachteile geht.

Der eigene Tracker

Ein solcher Tracker kann unterschiedlich komplex ausfallen. Je nachdem, welche Informationen und Arten von Hits er verarbeiten soll und wie einfach die Implementierung in ein bestehendes Tracking sein soll, kann viel Code auf dem Server und einige Arbeit im Client erforderlich sein. Zum Glück geht es hier nur um das Prinzip und so beschränken wir uns auf Seitenaufrufe und Events. Dennoch ist es zu viel Quellcode für einen Blogbeitrag. Ich habe eine einfache, aber funktionstüchtige Variante des "Servertrackers", den ich derzeit auf eigenen Websites (ja auch hier) erprobe, auf Github abgelegt. Wer Code lesen kann und mag, findet im Beispiel reichlich Kommentare.

Einiges an Code dient dabei bereits der "Minimalabsicherung". Er nimmt z. B. nur Aufrufe von der gleichen Domain entgegen, auf der er lebt. Diese Lösung ist dennoch sehr rudimentär. Und sie ist zwar auch dann nutzbar, wenn man mit dem Google Tag Manager arbeitet, aber der "Umbau" ist vergleichsweise aufwändig. Es gibt andere Lösungen, die in dieser Hinsicht deutlich reibungsloser eingebunden werden können und durch mehr JavaScript-Zauber im Client z, B. dafür sorgen, dass man kaum etwas umstellen muss. Speziell im Fall eines mit vielen Tags und Triggern ausgestatteten GTM kann eine Umstellung sonst viel Arbeit bedeuten - für solche Fälle gibt es aber zum Glück bereits entsprechende Lösungsansätze wie z. B. einen "Tag Manager Server". Das Prinzip bleibt aber mehr oder weniger gleich. Es wird ein Ersatz für das übliche clientseitige Tracking mit Analytics Trackingcodes und / oder UA-Tags im Tag Manager geschaffen.

Serverseitige Identitätsfindung

Als Vorteil einer serverseitigen Lösung muss, solange man nicht zu irgendwelchen Zwecken die ID auch im Client benötigt, kein Abruf der ID erfolgen. Er kann es aber (siehe Hinweise zum GTM unten). Für das Tracking mit dem oben verlinkten "Logger" reicht es generell, die Quelle wie ein Cookie oder Fingerprint zu definieren und dann ruft das Script die Identität selbst ab und nutzt sie für das Tracking. Zur Auswahl stehen hier die schon aus den anderen Beiträgen bekannten Optionen:

• Cookies: Nutzbar sind sowohl eigene Cookies oder schon bestehende "Fremdcookies". Im Setup kann bestimmt werden, welcher Cookieschlüssel und wer das Cookie verwaltet
• Fingerprint: Orientiert sich am bereits im letzten Teil beschriebenen Beispielverfahren, das aber beliebig ausgebaut / ausgetauscht werden kann
• Session: In diesem Fall wird die PHP-Session (mit dem dazu gehörigen Cookie PHPSESSID) genutzt

Auch fast alle anderen Optionen des Codes befassen sich mit dem Thema des Identitätsverfahrens; ansonsten ist nur noch eine Google Analytics Property ID erforderlich. Warum diese hier steht und nicht vom Client übergeben wird, sollte offenkundig sein. Welche Property man verwendet, kommt auf das Nutzungsszenario an: Sowohl ein eigenes Profil als auch die Sammlung gemeinsam mit den vollständig erhobenen Daten im Consent-Fall in einer gemeinsamen Property haben jeweils eine Existenzberechtigung - unter der Voraussetzung, dass diese Lösung im Fall fehlenden Consents betrieben werden darf (was ich nicht beantworten kann - noch betreibe ich diesen Test ja unter den gleichen Bedingungen wie sonst auch vollständiges Tracking). Der Rest des Beispielcodes besteht dann im Wesentlichen aus dem Sammeln und Auswerten von Merkmalen wie dem User Agent, der aufrufenden Seite etc. und dem Absetzen des Trackinghits.

Trackinghits senden

Der Transport geschieht dabei wie schon erwähnt über das Measurement Protocol. Dabei gibt es viele gemeinsame Parameter; andere werden je nach Typ des Hits benötigt. Da hier nur Seitenaufrufe und Events vermessen werden (und Events nur aus Kategorie, Aktion und Label bestehen) ist der "Zusammenbau" der Hits vergleichsweise einfach. Will man mehr übertragen oder müssen Transaktionen verarbeitet werden, ist ein Ausbau des Beispiel-Loggers erforderlich. Im Kern geht es aber um den Aufruf einer URL wie der folgenden:

https://www.google-analytics.com/collect?v=1&tid=UA-12345678-9&cid=12345.67890&t=event&ec=Klicks&ea=MailLink&el=Header

Hinter dem ersten "&" folgen in dieser URL Informationen zur Art des Hits, der Property ID, der hier vieldiskutierten Client ID und weitere Angaben zum Hit, die vorher gesammelt wurden und (über in der Referenz beschriebene Parameter) an Analytics übertragen werden. Der Parameter t=event gibt dabei den Typ des Hits an.

Anreichern der Dimensionen und Messwerte

Oben im Logger-Script findet sich eine Option zur Definition eigener, z. B. Benutzerdefinierter Dimensionen oder Metriken, die an den Hit angehängt werden sollen. Natürlich kann man diese auch direkt unten im Script an den Aufruf anhängen. Die Variable $customParameters des Beispielscripts dient also eher der zentralen Konfigurierbarkeit. Das kann und sollte man auch nutzen - und sei es nur, um einen Marker aller Hits zu definieren, so dass diese dadurch von den "normalen" Hits unterschieden, gefiltert oder segmentiert werden können. Dazu bietet sich z. B. der Parameter "ds" (Data Source) an. Damit hängt man z. B. ein ds=servertracking an alle Hits zur Markierung an, indem man diese Ergänzung im Setup-Block angibt.

Dimensionsschwund. Gewollt.

Der Beispiel-Logger beschränkt sich auf relativ wenige Dimensionen und Messwerte. Diese werden entweder als Parameter vom clientseitigen Part des Trackers übergeben (wie der Referrer der Seite und die URL eines virtuellen Seitenaufrufs bzw. Angaben zu einem Event) oder direkt per PHP am Server vom Logger ermittelt. Diesen Umfang kann man deutlich ausbauen... trotzdem ist das Tracking auf alles beschränkt, was über das Measurement Protocol übergeben werden kann... und darf bzw. sollte. Ein Beispiel: Wir können theoretisch eine ungekürzte IP-Adresse übergeben. Niemand würde es sehen. Oder zumindest eine anonymisierte IP Adresse. Das wäre auch wünschenswert, um z. B. die Dimensionen zum Nutzerstandort zumindest in der Auflösungsgenauigkeit in Analytics sehen zu können, wie es bei vollständigem Tracking der Fall ist. Da es hier aber um eine kontrollierte Weitergabe möglichst vieler Daten geht, ohne dabei Dinge zu verarbeiten, die dem Schutz des Besuchers vor Profilbildung u. a. schaden könnten, sollte man das vermutlich nicht tun. Aus diesem Grund wird die konstante IP-Adresse 0.0.0.0. verwendet. Hauptsächlich deshalb, weil in den Berichten sonst alle Besuche vom Standort des eigenen Servers kommen würden. Dann lieber "not set". Ähnliches gilt für den im Beispiel komplett übertragenen User Agent, dessen "Personenbezug" nach meinem Wissensstand durchaus diskutabel ist. Stellt sich dies als Problem heraus, kann er ausgelassen oder z. B. auf Angaben zu Browser und Betriebssystem reduziert eingesetzt werden. Je nach Umfang des verbauten Trackings und der Übertragung an Analytics kann man also durch Ausbau vieles, aber nicht alles abfangen, was in einem vollwertigen Tracking möglich ist.

Ansteuern des Loggers im Browser

Einsatz via Google Tag Manager

Aus oben genannten Gründen ist der Google Tag Manager ein typischer und zentraler Bestandteil komplexerer Trackingszenarien. Über entsprechende Templates oder zur Not Custom HTML Tags ist das folgende Prinzip auch über den Tag Manager zu nutzen. Dabei ist der vorherige Abruf von Identität im Client nicht erforderlich, weil der Logger diese serverseitig selbst ermitteln kann. Wird eine Client ID dennoch benötigt, kann der Logger als "Identitätslieferant" eingesetzt werden. Dazu wird er mit dem Parameter "?ht=sid" aufgerufen. Statt eines Pixels kommt dann die ermittelte ID der Sitzung oder des Clients (je nach gewählter Einstellung im PHP Script) zurück. Das erlaubt es, den Logger auch ohne separate getclient.php aus dem Beispiel des Beitrags zu cookielosem Tracking zu verwenden, wenn z. B. im Rahmen eines hybriden Setups die Client ID im Browser benötigt wird.

Einsatz direkt auf der Seite

Im Beispiel bleiben wir aber bei einem direkt implementierten Universal Analytics Code. Weil es einfacher ist; außerdem ist das Prinzip auch auf gtag.js oder eben Tracking mit dem GTM übertragbar. Ich weiß auch von komplexeren und komfortableren Umsetzungen... und vielleicht schreibt der Urheber einer dieser Lösungen ja selbst gelegentlich etwas darüber (wenn er das hier liest, wird er sich hoffentlich angesprochen fühlen! ;))

Zurück zum einfachen Anwendungsfall. Im Zentrum steht dabei wieder ein "Trackingscript", welches den Logger auf dem eigenen Server aufruft. Eine zum Beispiel-Logger passende clientseitige Javascript-Trackingfunktion  kann mit sehr wenig Code auskommen, wie im Beispiel zu "doLog()" bei Github zu sehen ist. Und auch die wahlweise Nutzung von GA oder dieser Variante ist bei einem direkt verbauten Tracking einfach zu erledigen, weil man nur eine eigene ga()-Funktion benötigt (auch das ist im Beispiel gezeigt).

Nutzbarkeit und Nutzen

Wie auch der cookielose Betrieb von Google Analytics bietet auch dieses Verfahren Vor- und Nachteile. Dabei gibt es Gemeinsamkeiten, aber auch ein paar besondere Aspekte, die der "versteckte" Einsatz auf dem Server mit sich bringt.

Vorteile

• Die (serverseitige) Verwaltung der Identität schützt auch hier vor ITP bei gleichzeitiger "Zweckerfüllung" des Trackingschutzes (siehe Vorteile der cookielosen Variante)
• Durch den Verzicht auf von Trackingservern nachgeladene Scripts sind hier ETP und typisches Blockieren von Tracking kein Thema
• Volle Kontrolle über den Umfang der (an Google) übergebene Daten. Bis hin zum "stupiden Sammeln von zusammenhanglosen Hits" reduziert umsetzbar
• Einfacher Austausch oder Ergänzung des schlussendlich belieferten Trackingsystems
• Man kann im Prinzip "machen, was man will", ohne dass es jemand nachvollziehen kann

Nachteile

• Man kann im Prinzip "machen, was man will", ohne dass es jemand nachvollziehen kann. Ja natürlich: Das ist ein Vorteil und Nachteil zugleich. Je nachdem, inwiefern dieser Punkt ausgenutzt wird. Tracking ist nicht der Wilde Westen. Karma, Baby!
• Auch dieses Verfahren ist auf Identität angewiesen und die muss irgendwo herkommen. Das ist kein systemeigener Nachteil, wird aber gern übersehen 😉
• Rechtskonformer Einsatz ohne Consent unter künftigen Bedingungen ist vollkommen unklar bzw. sehr vom Umfang der übergebenen Daten abhängig. Nur weil andere es ähnlich machen, muss es nicht OK sein
• Implementierungsaufwand i. d. R. höher als bei anderen Lösungen bzw. Trackinganbietern, die ein "Light Tracking" ggf. schon von Haus aus ermöglichen. Es ist damit definitiv keine "Massenlösung" und auch nicht für jeden eine Option.

Einsatz zur Erfolgskontrolle?

Es bleibt aber vor einem Abschluss noch ein wesentlicher Punkt offen: Was bleibt vom typischen Nutzen der Webanalyse übrig, wenn die Datensammlung mit den hier gezeigten Mitteln in eingeschränkter Weise stattfindet? Ein Teil der Antwort ist schon im ersten Beitrag angesprochen: Attribution ist einer der größten Schwachpunkte, wenn man z. B. auf unzuverlässigere und / oder kurzlebige Client IDs  zurückgreifen muss.

Trotzdem ist z. B. bei einer Verknüpfung von Google Ads und Analytics durch das Auto-Tagging z. B. bei Nutzung einer Session ID als Identität der Import von in der nach dem Klick stattgefundenen Sitzung erreichten Zielen als Conversions in Ads möglich. Ich habe es getestet. Das ist nicht viel, aber es ist etwas. Hat man Zugriff auf eine langlebigere Identität, mag sogar die rückwirkende Zuordnung noch gegeben sein. Hilft das bei Bing? Oder Facebook? Nein. Und vor allem ist es eine Verbindung zweier Systeme und keine reine Statistikfunktion mehr. Spätestens dann bedarf es daher zum Einsatz sicher auch Consent, wenn er zum vollwertigen Tracking erforderlich ist/wird (und ein DSGVO-Thema bleibt dieser Anwendungsfall dann auch). Insofern kann man mit der serverseitigen Variante einer Menge Probleme entgehen (siehe Vor- und Nachteile unten), aber selbst wenn wir irgendwie und in eingeschränktem Umfang noch Statistik auch ohne Consent betreiben werden dürfen, sind wir bei dieser Verknüpfung spätestens im Bereich der "Werbung" und nicht mehr "Statistik", um in den typischen Gruppen von Consent Managern zu bleiben.

Aber die unmittelbare Kontrolle von "Kampagnenerfolg" in Form von Besucherverhalten nach Quelle / Medium oder Kanal in Analytics selbst ist auch ohne eine Verknüpfung nach wie vor möglich. Es gilt: Hat man zumindest eine Session, kann auch Zielerreichung und Trichterverhalten etc. betrachtet werden. Im schlimmeren Fall aber eben leider nur auf Basis einer Sitzung. Oder - bei Einsatz von nicht wirklich eindeutigen Fingerprints (Stichwort gleiche - anonymisierte - IP, Browser und Systeme) - zwar über die Sitzung hinaus, aber mit der realen Gefahr, Sitzungen unterschiedlicher Benutzer durcheinander zu werfen. Jedenfalls dann, wenn man es im Sinne des Datenschutzes richtig macht. Potentiell ohnehin schon fehlerbehaftete Zahlen in der Webanalyse werden dadurch aber systembedingt leider noch schlechter.

Macht der fallende Baum ein Geräusch, wenn keiner zuhört?

Serverseitig bedeutet im weitesten Sinne "unbeobachtet". Was natürlich die Verlockung birgt, hinter dem Schutz des eigenen Servers deutlich mehr zu sammeln und zu nutzen, als für ein minimiertes und vom User möglichst entkoppeltes Tracking erforderlich wäre. Denn der Blick auf das "Große Ganze", die Customer Journey und das Zusammenspiel der verschiedenen Touchpoints (soweit sie in der Webanalyse erfasst werden) ist bestenfalls getrübt und im schlimmeren Fall vollkommen verwehrt. Bei der Einschätzung des Umfangs dessen, was man tracken will vs. was man unter bestimmten Bedingungen darf, ist vor allem vermutlich moralische Stärke gefragt. Und man ringt vermutlich auch im Einzelfall zwischen "Richtig" und "Nutzen". Wie sieht es z. B. mit Transaktionen aus? Transaktionsnummern kann man weglassen, aber manchmal reicht vielleicht schon die Zusammenstellung des Warenkorbs oder der Endpreis, um daraus auf den Käufer zu schließen. An dieser Stelle sei wiederholt: technisch machbar ist es natürlich. Und aus Sicht eines Shopbetreibers natürlich auch zu 100% wünschenswert. Alles andere muss eingeschätzt werden, wenn wir (neue) konkrete Anforderungen und Grenzen kennen. Gerade bei serverseitigem Tracking ist am Ende des Tages (dummerweise) jeder allein mit seiner Entscheidung über den Umfang. Weil die Nachvollziehbarkeit auf Einsicht in die Daten der Webanalyse angewiesen ist und sich nicht aus Beobachtung von Vorgängen im Browser stützen kann. Die Empfehlung kann daher hier nur lauten, sich bei einer Umsetzung auf ein Minimum an übergebenen Dimensionen zu beschränken und speziell bei der Identität und ggf. strittigen Dimensionen Dingen wie dem User Agent die eigene Lösung mit den rechtlichen Anforderungen des Nutzungskontexts abzustimmen.

Ein Ende ohne Fazit

Womit wir einstweilen tatsächlich am Ende der Serie angekommen sind, bevor es zu moralisch wird. Zumindest vorläufig. Denn wenngleich hier die technische Machbarkeit im Fokus steht, muss eine reale Umsetzung noch einmal auf den Prüfstand. Spätestens nach einem Urteil oder dem Glattziehen der Unterschiede in der Umsetzung der ePrivacy-Verordnung in Deutschland ggü. den Nachbarn wird es dazu kommen (müssen). Erst mit Wahl der dann noch verfügbaren Optionen zur Identitätsbestimmung steuert sich die Nutzbarkeit der Ergebnisse auf einem einschätzbaren Level ein. Vielleicht kommt ja auch alles anders als gedacht und wir werden noch einmal vor der Consent-Welle oder dem optionalen Großausfall von "ganz normalem" Tracking gerettet. Ja, ich weiß. Man wird ja noch träumen dürfen...