AnreicherungJetzt verfügbar

    Ein stabiler Identifier ohne Cookie.

    Wird Speicher geleert, begrenzt oder nie zugelassen, verlieren Ihre Tags den Faden zwischen Requests. Das Modul User ID leitet am Gateway einen pseudonymen Identifier aus Signalen ab, die in der Verbindung ohnehin vorhanden sind, und übergibt ihn Ihrem Container als einzelnen Header.

    Identifier mit 32 Zeichen
    Geheimer Schlüssel pro Container
    Jederzeit rotierbar
    Alle Module
    Eingaben, am Gateway
    Client-AdresseUser AgentTLS-ParameterContainer-Schlüssel
    HMAC-SHA256
    Header, den Ihre Tags erhalten
    X-User-Id9f4c1ab7e0d2385c6a17be49f03d7c82

    Der Container-Schlüssel verlässt das Gateway nie, Identifier lassen sich also anderswo weder nachrechnen noch über Container hinweg verknüpfen.

    Wie der Identifier entsteht

    Identität, die nicht vom Speicher abhängt

    Cookies und Local Storage sind das Erste, was ein Browser zurücknimmt. Sind sie weg, wirken Requests, die offensichtlich zusammengehören, unverbunden, und in der Tag-Schicht gibt es nichts, was sie wieder verknüpfen könnte.

    01

    Speicher ist nicht garantiert

    Private Fenster, geleerte Browser und Tracking-Schutz entfernen clientseitige Identifier, mitunter zwischen zwei Requests innerhalb einer Sitzung.

    02

    Hashing im Tag ist schwächer

    Ein im Container berechneter Hash kann nur nutzen, was der Container sieht. Das Gateway sieht mehr, darunter Signale auf Verbindungsebene, die den Container nie erreichen.

    03

    Eigenbau ist ein Risiko

    Selbstgebaute Identifier sind meist über Properties hinweg verknüpfbar, aus öffentlichen Eingaben vorausberechenbar oder beides, genau die Eigenschaften, die ein Prüfer beanstandet.

    So funktioniert es

    Der Identifier ist ein HMAC-SHA256 über Verbindungssignale und ein für Ihren Container einzigartiges Geheimnis, gekürzt auf 32 hexadezimale Zeichen und als X-User-Id ausgeliefert.

    01

    Verbindungssignale

    Client-Adresse und User-Agent werden mit den vom Client angebotenen TLS-Parametern kombiniert, seinen Cipher- und Kurvenlisten, einem leichten Fingerabdruck, den der Container nie sieht.

    02

    Ein Schlüssel pro Container

    Ein für Ihren Container einzigartiges Geheimnis fließt mit ein. Derselbe Besucher erzeugt damit auf jedem Container einen anderen Identifier, und der Hash lässt sich nicht aus öffentlichen Eingaben vorausberechnen.

    03

    Als ein Header ausgeliefert

    Ihr Container erhält X-User-Id: 32 hexadezimale Zeichen, stabil so lange, wie die zugrunde liegenden Signale stabil sind.

    04

    Auf Wunsch rotieren

    Den Schlüssel in der Konsole neu zu erzeugen rotiert ab diesem Moment jeden Identifier: ein sauberer, prüfbarer Reset, wann immer Sie ihn wollen.

    Was Sie bekommen

    Übersteht Speicherverlust

    Es wird nichts in den Browser geschrieben, also gibt es auch nichts zu löschen. Der Identifier wird pro Request aus der Verbindung selbst abgeleitet.

    Über Container hinweg nicht verknüpfbar

    Weil der Schlüssel pro Container gilt, lässt sich derselbe Besucher weder über zwei Ihrer Container noch über zwei unserer Kunden zusammenführen.

    Nicht vorausberechenbar

    Ohne den geheimen Schlüssel lässt sich ein Identifier nicht aus IP-Adresse und User-Agent reproduzieren, genau das unterscheidet ihn von einem einfachen Hash.

    Normaler Header, normale Variable

    Lesen Sie X-User-Id mit der Standard-Request-Header-Variablen aus und nutzen Sie ihn überall dort, wo Ihre Tags einen stabilen Schlüssel brauchen.

    Spezifikation

    Header
    X-User-Id
    Format
    32 hexadezimale Zeichen
    Ableitung
    HMAC-SHA256 über Verbindungssignale
    Schlüssel
    Pro Container, neu erzeugbar
    Kosten
    In Ihrem Container enthalten
    Request-Header
    X-User-Id

    Wann Sie es einsetzen

    Sie deduplizieren Events

    Ein stabiler Schlüssel macht es deutlich einfacher, Browser- und Server-Events desselben Besuchers abzugleichen, bevor sie einen Vendor erreichen.

    Sie brauchen Sitzungskontinuität ohne Speicher

    Wo ein Cookie nie gesetzt oder bereits gelöscht wurde, hält der Identifier eine Sitzung als eine Sitzung erkennbar.

    Sie bauen ein Warehouse-Modell

    Ein pseudonymer Schlüssel, der pro Container stabil und außerhalb nicht verknüpfbar ist, ist ein solider Join-Key zum Modellieren, ohne personenbezogene Daten hineinzuschieben.

    Fragen zu User ID

    Sind das personenbezogene Daten?

    Behandeln Sie ihn als pseudonymes Datum und führen Sie ihn in Ihrer Datenschutzdokumentation. Er wird aus personenbezogenen Daten abgeleitet und identifiziert einen Besucher innerhalb Ihres Containers, auch wenn er sich nicht in eine Adresse zurückrechnen lässt.

    Wie stabil ist er in der Praxis?

    So stabil wie die zugrunde liegenden Signale. Ein Browser-Update oder ein Netzwerkwechsel erzeugt einen neuen Identifier. Dies ist eine Kontinuitätshilfe, kein dauerhafter Schlüssel.

    Was passiert, wenn ich den Schlüssel neu erzeuge?

    Ab diesem Moment ändert sich jeder Identifier. Frühere Werte lassen sich nicht mit neuen verknüpfen, und genau das ist der Sinn: ein bewusster, sauberer Reset.

    Lässt sich das mit dem Anonymizer kombinieren?

    Ja. Der Identifier wird am Gateway aus der echten Verbindung berechnet, bevor der Anonymizer die Header umschreibt. Sie können also einen stabilen Schlüssel haben und trotzdem überhaupt keine IP-Adresse weiterreichen.

    Weitere Module

    Module lassen sich kombinieren. Aktivieren Sie so viele, wie Sie brauchen. Sie fließen in eine einzige Konfiguration vor Ihrem Container zusammen.

    Bereit zum Aktivieren?

    Jedes Modul ist ohne Aufpreis in Ihrem Container enthalten. Container anlegen, Modul-Panel öffnen, Schalter umlegen.

    Preise ansehen