EnrichmentAvailable now

    A stable identifier without a cookie.

    When storage is cleared, capped or never granted, your tags lose the thread between requests. The User ID module derives a pseudonymous identifier at the gateway from signals that are already present in the connection, and hands it to your container as a single header.

    32-character identifier
    Per-container secret key
    Rotate whenever you want
    All modules
    Inputs, at the gateway
    client addressuser agentTLS parameterscontainer key
    HMAC-SHA256
    Header your tags receive
    X-User-Id9f4c1ab7e0d2385c6a17be49f03d7c82

    The container key never leaves the gateway, so identifiers cannot be recomputed elsewhere or linked across containers.

    How the identifier is derived

    Identity that does not depend on storage

    Cookies and local storage are the first things a browser reclaims. When they go, requests that plainly belong together look unrelated, and there is nothing in the tag layer that can reconnect them.

    01

    Storage is not guaranteed

    Private windows, cleared browsers and tracking prevention all remove client-side identifiers, sometimes between two requests in a single session.

    02

    Hashing inside the tag is weaker

    A hash computed in your container can only use what the container can see. The gateway sees more, including connection-level signals that never reach it.

    03

    Rolling your own is a liability

    Home-grown identifiers tend to be linkable across properties, precomputable from public inputs, or both, exactly the properties a reviewer will object to.

    How it works

    The identifier is an HMAC-SHA256 over connection signals and a secret unique to your container, truncated to 32 hexadecimal characters and delivered as X-User-Id.

    01

    Connection signals

    The client address and User-Agent are combined with the TLS parameters the client offered, its cipher and curve lists, a lightweight fingerprint the container never sees.

    02

    A per-container key

    A secret unique to your container is mixed in. The same visitor therefore produces a different identifier on every container, and the hash cannot be precomputed from public inputs.

    03

    Delivered as one header

    Your container receives X-User-Id: 32 hexadecimal characters, stable for as long as the underlying signals are stable.

    04

    Rotate on demand

    Regenerating the key from the console rotates every identifier from that moment on: a clean, auditable reset whenever you want one.

    What you get

    Survives storage loss

    Nothing is written to the browser, so there is nothing for a browser to clear. The identifier is derived per request from the connection itself.

    Unlinkable across containers

    Because the key is per container, the same visitor cannot be joined across two of your containers, or across two of our customers.

    Not precomputable

    Without the secret key, an identifier cannot be reproduced from an IP address and a User-Agent, which is what separates this from a plain hash.

    Ordinary header, ordinary variable

    Read X-User-Id with the standard Request Header variable and use it wherever your tags need a stable key.

    Specification

    Header
    X-User-Id
    Format
    32 hexadecimal characters
    Derivation
    HMAC-SHA256 over connection signals
    Key
    Per container, regenerable
    Cost
    Included with your container
    Request headers
    X-User-Id

    When to use it

    You are deduplicating events

    A stable key makes it far easier to reconcile browser and server events for the same visitor before they reach a vendor.

    You need session continuity without storage

    Where a cookie was never set or has already been cleared, the identifier keeps a session recognisable as one session.

    You are building a warehouse model

    A pseudonymous key that is stable per container and unlinkable outside it is a sound join key for modelling without shipping personal data into it.

    Questions about User ID

    Is this personal data?

    Treat it as pseudonymous data and cover it in your privacy documentation. It is derived from personal data, and it identifies a visitor within your container, even though it cannot be reversed into an address.

    How stable is it in practice?

    It is stable for as long as the underlying signals are. A browser upgrade or a change of network will produce a new identifier. This is a continuity aid, not a permanent key.

    What happens when I regenerate the key?

    Every identifier changes from that moment on. Previous values cannot be linked to new ones, which is the point: it is a deliberate, clean reset.

    Can it be combined with the Anonymizer?

    Yes. The identifier is computed at the gateway from the real connection before the Anonymizer rewrites the headers, so you can have a stable key and still forward no IP address at all.

    Other modules

    Modules stack. Enable as many as you need. They compose into one configuration in front of your container.

    Ready to switch it on?

    Every module is included with your container at no extra cost. Create a container, open the modules panel, and toggle.

    See pricing