Identity

Every event belongs to a person, and Fidero keeps one profile for each. It works the same way from a visitor’s first anonymous page view to their renewal years later: every event attaches to that one profile, whether or not you know who the person is yet.

This page is the mental model: the two IDs, how anonymous becomes known, and what holds identity together across domains and devices.

Anonymous from the first page

On the first page load, the SDK gives the visitor an anonymous ID – first-party, created and managed by Fidero, stable across pages, tabs and visits on that browser. Every event carries it, so a profile builds up before you know who the person is – the pages viewed, the ad that brought them, the trial they started.

Becoming known

The moment you know who someone is – they sign up, they log in – tell Fidero their ID in your system:

fidero.updateIdentity({
  userId: "user_7d21c4",
  traits: {
    email: "leo@example.com",
  },
});

Fidero merges the anonymous history into the person’s profile, so the events from before the signup belong to them too. From then on, events carry both IDs, and any traits you set stay on the profile.

Note

Already logged in when the page loads? Set userId at init instead. On logout, reset() clears the identity and starts a fresh anonymous visitor.

Across domains and devices

Few journeys stay on one domain: marketing site, checkout on a payment domain, app on a subdomain. Each hop would normally start a new identity. Between your own domains, Fidero carries the anonymous ID across the link, so the visitor lands on the next domain as the same person. Which domains it does this for is part of your project configuration – Projects & configuration covers the boundary.

Devices are different: browser storage can’t move between them, so the userId is what carries identity across. Someone who signs in on their laptop and later on their phone is one profile, because both devices set the same stable ID.

So the biggest lever you have on identity coverage is identifying users early. An anonymous ID lives in browser storage, and browsers limit how long that survives, Safari more than most. A stable userId doesn’t expire.

No guessing

Fidero merges on exact keys only: the anonymous ID it manages, and the userId you set. There’s no probabilistic matching and no fingerprinting, so a profile never contains someone else’s events. What that lets Fidero guarantee, and what’s measured as coverage instead, is on Guarantees & coverage.

The profile itself lives on Fidero’s server, not in the browser – the platform overview covers the architecture behind that.

The edge case

One case needs your help: a conversion that reaches Fidero from your server before the user exists in your system. A checkout webhook can fire while the visitor is still anonymous, and your backend has no userId to send. Pass the visitor’s anonymous ID to your backend before the conversion fires. Read it with getIdentity() and attach it to whatever reports the conversion, such as Stripe’s client_reference_id. Connecting anonymous → server covers the pattern end to end.

Related

Attribution The campaign context a profile carries, and how it reaches server-side conversions.

Connecting anonymous → server The one edge case in full: conversions that fire before a user ID exists.

Guarantees & coverage What identity resolution is guaranteed, and what's measured as coverage.