Quick answer
Identity resolution maps device identifiers to a known user ID — usually through an identify or login call after sign-in — and merges their activity into one person profile.
Why it is needed
Without identity, analytics sees devices, not people. The same customer on a work laptop, a phone and a tablet is three visitors. Retention looks worse than it is, because a person returning on a new device looks like a new person, and lifetime value per customer cannot be computed at all.
When the visitor signs in, the site knows who they are. An identify (or login) call passes that user ID to analytics, which links the current device to the person, and from then on — and usually for the device's earlier anonymous visits too — counts their activity as one.
How it works
- Device ID → user ID. Each device has an anonymous ID. At sign-in, it is mapped to the user ID.
- Backfill. Activity from that device before sign-in is attributed to the person, so the first visit and the acquisition source are not lost.
- Several devices. Each device that signs in with the same ID joins the same person.
- Safeguards. Shared devices and test accounts can produce wrong merges; limits on devices per person and rejected IDs (such as "0" or "null") catch the usual problems.
Identity and privacy
Identifying people is a different privacy posture from anonymous counting. It usually needs a legal basis and notice, and users must be able to ask for their data to be erased. Only send a stable internal user ID, not an email address or phone number, as the identifier.
Identity in TapCub
Identity is a per-site choice. In anonymous mode TapCub counts visitors with a server-side hash and keeps no person profiles. In identified mode you call tapcub.login(id, { $name, $email }) after sign-in, or configure a zero-code identity source, and TapCub maps device → login ID → person. A device's anonymous history from before sign-in is backfilled to the person.
The identity page shows the counting difference this makes (web visitors, devices and reconciled users side by side), every device binding and mapping change, and warnings such as devices over the limit, rejected login IDs and personal data stripped from properties. People with an erasure or restriction request are marked, and their new events are dropped.
Common mistakes
- Using email as the ID. It changes, and it is personal data. Use an internal user ID.
- Calling identify with a placeholder. "guest" or "0" would merge every anonymous visitor into one person. TapCub rejects common placeholders like these and reports them as a warning, but fix the call.
- Forgetting logout. On shared devices, reset the identity at sign-out so the next person is not merged in.
Related guides: Server-Side Tracking and B2B Website Metrics.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.

Technical Engineer
Focuses on tracking code, SDKs, and API integrations, with practical guidance on implementation checks and troubleshooting.