Identity Modes

Every site starts anonymous: no page view or event carries an identifier that persists from one visit to the next. If your own application already knows which signed-in user is visiting, you can switch that one site to pseudonymous mode and carry your own id on every page view and event it sends.

The two modes

Switching a site to pseudonymous mode is a deliberate choice a team member with access to that site's settings makes, not something a tracker call can turn on by itself. Calling setUserId on a site still in anonymous mode does nothing: the id is not sent, and the browser console logs why.

The obligation you take on

We are the processor; the lawful basis for processing your own signed-in users is yours to determine, not ours. Anonymous mode is the position behind our Legitimate Interest claim for aggregate visitor analysis. Pseudonymous mode links a site's own visits to the id you supply, which is no longer purely aggregate, and in the UK it takes the site out of the statutory analytics exemption, which excludes connecting a visitor id to activity. Decide your own basis before switching a site on, the same way you would for any other feature of your product that recognises a signed-in user.

Turn it on

In that site's settings, open Identity Mode and choose Pseudonymous. Switching back to anonymous stops new identities immediately; rows already stored are not rewritten.

Call setUserId once you know who is visiting

The call is framework-agnostic: it is the same global the tracker snippet already defines, so it works anywhere that snippet loads.

window.verita('setUserId', 'usr_8f3a92');

Call it as soon as your application knows who the visitor is, and call it again on every page your own authentication confirms them, for example right after a login check resolves:

useEffect(() => {
  if (currentUser && window.verita) {
    window.verita('setUserId', currentUser.id);
  }
}, [currentUser]);

Calling it twice with the same id is one identity, not two, so a re-render or a route change that runs this effect again costs nothing. It only needs calling again after a full page reload, because that is the only thing that clears it.

What the id may and may not be

• An opaque value such as a UUID or your own internal account id. It identifies a person to you, the site owner, because you hold the mapping; we do not.
• Never a name, email address, or phone number. Ingest refuses a value shaped like one.
• Sent as given, not hashed again: it is already pseudonymous before it reaches us, so a second hash would only hide the value from you without protecting anyone further.
• Scoped to the one site that collected it. We cannot use it to connect that visitor's activity on a different site, including another site you run.

If the value your application passes looks like an email address or a phone number, the page view or event is stored as usual, just without an identity: the visit is not lost, only the id is dropped, and we count how often that happens so a misconfigured integration is visible rather than silent.

Privacy

A site in anonymous mode (the default) ties every event to the daily-salted visit identifier that resets every 24 hours, sets no cookies, and stores no IP address. A site switched to pseudonymous mode keeps its own supplied id stable across days by design, which is the point of turning it on; the rest of the handling (no cookies, no IP address on a stored row) is unchanged. See how a pageview works for the anonymous-mode mechanism, and our privacy policy for how both modes are described there.