IP Adressen Nicht Tracken

Ich bin kein Anwalt und ich darf und kann Niemanden beraten, wenn es um Fragen des Rechts geht. Soviel vorweg.

In Deutschland geht die Debatte um Daten und insbesondere persönliche Daten („PII“) ziemlich hart zur Sache. Manchmal geht es dabei um die IP Adresse der Besucher. Deutschland gehört zu den Ländern, in denen die IP Adresse als PII gilt.

Was die rechtlichen Aspekte angeht, werde ich mich dazu nicht äußern, aber ich möchte gerne kurz erklären, was es für Einstellungen in SiteCatalyst gibt.

IP Adressen Nicht Tracken

Nee, Moment!

IP Adressen und SiteCatalyst

Erstmal sollte ich vielleicht erklären, was überhaupt passiert.

Also:

1. Besucher kommt auf getrackte Webseite
2. Seite enthält Javascript Code für’s Tracking
3. Javascript Code baut „Tracking Beacon“ und sendet sie an Collection Server
4. Collection Server nimmt Daten entgegen und leitet sie weiter an Processing
5. Processing macht Geolookup, basierend auf IP Adresse
6. Processing führt Processing Rules und VISTA aus
7. Processing speichert Rohdaten in Data Warehouse
8. Processing speichert aggregierte Daten in SiteCatalyst und Discover

Die IP Adresse ist grundlegender Bestandteil des Internet. Jedes Gerät, das im Internet kommunizieren will tut dies über das IP Protokoll, zu dem die IP Adressen gehören.

Schritt 1 funktioniert nur mit IP Adressen beiderseits, ebenso die Schritte 3, 4 und 5. Schritt 6 kann auf die IP Adresse zurückgreifen, das hängt von der eigentlichen VISTA Rule ab. Und Schritt 7 speichert normalerweise die IP Adresse mit. Danach ist sie irrelevant.

Soweit zum Prozeß und zum technischen Hintergrund.

IP Adressen Nicht Tracken

SiteCatalyst hat Optionen, mit denen man den Prozeß oben beinflussen kann, was die IP Adressen angeht. Zwei Optionen sollten wir uns genauer ansehen, bzw. welche Auswirkungen sie auf die Abfolge oben haben:

1. Den Geolookup in Schritt 5
2. Die Speicherung der Rohdaten in Schritt 7

Die Auswirkungen gehen dabei ein wenig weiter. Fangen wir mal mit dem zweiten an, ist einfacher.

Speichern der IP Adresse

Es gibt in SiteCatalyst bzw. Adobe Analytics drei Möglichkeiten:

Erstens kann man die IP Adresse wie sie ist in den Rohdaten speichern.

Wer das tut kann sich die IP Adressen seiner Besucher in Data Feeds ansehen, wozu auch immer das gut sein soll.

Zweitens kann man die IP Adresse verschlüsselt („gehasht„) speichern.

Hashing ist eine Einwegverschlüsselung; man kann sie also nicht wieder entschlüsseln. Es ist theoretisch denkbar, daß jemand durch Durchprobieren aller möglichen IP Adressen (immerhin 4 Milliarden) die richtige findet. Dazu bräuchte dieser Jemand natürlich wieder den Data Feed.

Drittens kann man die IP Adresse aus-x-en, also statt der IP Adresse „x.x.x.x“ in die Rohdaten schreiben lassen. Dies ist die Standardeinstellung für Kunden in Deutschland.

Hier gibt es keine Möglichkeit, auf die ursprüngliche IP Adresse
zurückzuschließen.

Wichtig: Die drei Einstellungen gelten nur für Data Warehouse, also die Rohdaten. In SiteCatalyst, Discover und den anderen Tools, die auf SiteCatalyst Daten aufsetzen (Report Builder, ClickMap, Reporting API, …) werden keine IP Adressen gespeichert, hier ist das Thema also nicht relevant.

Geolookup

SiteCatalyst und Adobe Analytics können Besucher räumlich zuordnen, also z.B. das Herkunftsland, die Region und die Stadt ermitteln. Dazu wird die IP Adresse benutzt.

Theoretisch wäre es möglich, daß man einen Besucher anhand seiner geografischen Lage identifiziert. Man denke an die Halligen in der Nordsee oder Orte mit wenigen Einwohnern. Eine genaue Lokalisierung könnte problematisch sein.

Man kann daher das letzte Oktett der IP Adresse auf „0“ setzen, bevor sie an Geolookup gegeben wird. Aus „82.132.221.84“ würde dann z.B. „82.132.221.0“. Die räumliche Auflösung des Geolookup wird so stark eingeschränkt.

Auch das ist Standardeinstellung für Neuimplementierungen in Deutschland.

Als Kunde kann man das einschalten lassen, indem man sich an ClientCare wendet. Einen Schalter in der Adminkonsole sowie bei der IP Obfuscation gibt es zur Zeit noch nicht.

Achtung: Diese Einstellung hat Auswirkungen auf Processing Rules und VISTA Rules und alle folgenden Schritte in der Prozeßkette!

Firmeninterne Zugriffe

Viele Analysten nehmen den firmeninternen Traffic aus der Analyse heraus, also all das, was die Kollegen im Büro auf der Webseite tun.

Dafür benutzt man üblicherweise die IP Adresse als Kriterium, entweder direkt in der Adminkonsole in SiteCatalyst, oder über eine DB VISTA Rule, falls man viele IP Adressen verwalten muß.

Wenn man die Option „Before Geo-Lookup [x] Replace visitor’s last IP octet with 0“ einschalten läßt, dann hat man für die VISTA Rule und die „IP Exclusion“ Einstellung in der Adminkonsole nicht mehr die ganze IP Adresse zur Verfügung, der Ausschluß wird also weniger präzise — d.h. man schließt im Zweifelsfall zu viele Besucher aus.

Wer darauf angewiesen ist, die gesamte IP Adresse für die Unterscheidung zwischen internem und externem Traffic heranzuziehen, kann das datenschutzkonform eigentlich nur im Browser abtesten, also bevor die Daten überhaupt gesendet werden.

Je nach Infrastruktur fallen mir da ein paar Möglichkeiten ein:

• Man könnte den Firmenproxy so konfigurieren, daß er intern ein separates s_code.js file ausliefert. In dieser Datei müßte dann nur die Variable s_account anders gesetzt werden.
• Der Firmenproxy könnte alternativ den ausgehenden Verkehr nach Requests absuchen, die an Adobes Collection Server gehen Das kann man ja gut an der URL sehen. In diesen Requests könnte der Proxy dann gezielt die rsid ersetzen.
• Man könnte per Policy an alle Computer einen Cookie verteilen, indem einfach nur „intern“ steht. Im Javascript fragt man diesen Cookie ab und setzt die Report Suite entsprechend.
• Ebenfalls im Javascript könnte man die IP Adressen gegen eine Liste interner IPs testen und die Report Suite anpassen. Nachteil ist, daß man dadurch seine IP Adressen quasi öffentlich in’s Netz stellt.

Alle Methoden haben ihre Vor- und Nachteile, keine ist perfekt.

Als letztes sei noch eine weitere Möglichkeite genannt: Internen Traffic gar nicht herausfiltern, sondern genau wie anderen Traffic auch behandeln.

Notizen

Alles oben Gesagte gilt für eine „normale“ Implementierung. Wenn ein Kunde beschließt, IP Adressen in eine prop oder eVar zu schreiben, dann greifen die Einstellungen für diese prop oder eVar nicht!

Und wo wir gerade bei identifizierbaren Daten sind: Man hat heutzutage Zugriff auf einen praktisch unüberschaubaren Fundus an Daten auf einer Website. Wer z.B. Facebook Connect benutzt, kann im Prinzip so ziemlich auf alle Daten seiner Besucher zugreifen.

Was viele nicht wissen: Man muß die nicht benutzen, und man sollte sie auf keinen Fall speichern!

Es gibt in diesem Umfeld drei Grundregeln, die ich persönlich für gut halte:

• „Say what you do“ – Ein detailliertes und transparentes Privacystatement ist ein absolutes Muß. Die meisten Besucher werden es nie lesen, aber die die es lesen wollen werden dankbar sein.
• „Do what you say“ – Wer sein eigenes Privacystatement nicht beachtet darf sich nicht wundern, wenn eines Tages ein Shitstorm die Marke überrennt.
• „Don’t surprise the user“ – Wer die Erwartungen seiner Benutzer verletzt, verliert Vertrauen(svorschuß).