TapCub is live — analytics, insights and live chat, free on one platform
Help center

Identify users across web, app and mini-programs

Identified mode links a device to a login ID so one person is one row across devices and platforms. Here is what to call, when, and what merges.

Product analytics6 min readLast updated Sep 22, 2026TapCub team

Still have a question?

Could not find it? A person reads every message, usually within a few hours on business days.

Chat with us

Anonymous vs identified

By default TapCub counts visitors with a cookieless pseudonym and never builds a person profile. Identified mode adds two things: a device ID written once consent allows it, and a person created when your code reports a login. People who never log in still appear only in aggregates.

Identified mode is available from Pro and pins the collection tier at 3 (see collection tiers). Turn it on under InsightsProject settingsIdentity. The web script then lazy-loads the identity module; nothing to redeploy.

What to call

After identified mode is on, the script exposes four methods. Call login after your own sign-in succeeds, logout when the user signs out:

app.js

// after your sign-in succeeds
tapcub.login('u_123', { $name: 'Ada', plan: 'pro' });

// add other identifiers for the same person
tapcub.bind({ unionid: 'UNION_ID' });

// on sign-out
tapcub.logout();
MethodWhat it does
login(id, props, opts)id is required, up to 200 characters. opts.type defaults to your login ID and may be email, mobile, OpenID or UnionID. Emails are lowercased and hashed; phone numbers lose spaces and dashes. Name, email and phone inside props go to the profile.
bind(ids)Adds further IDs to the same person. One login-type ID per person; up to five each of email, mobile and UnionID.
logout()Clears the login and rotates the session marker so the next visitor on a shared device starts fresh.
setProps / setPropsOnceOverwrite profile fields, or write a field only when it is empty — for first campaign, for example.
anonymous, guest, null, all zeros and -1 are rejected as IDs and show up as warnings on the identity map. Calling before the identity module has loaded fails; queue the call or wait for the ready event. Exact method names are in the SDK reference.

What merges, and what does not

The first login on a device backfills that device's anonymous history onto the person, so the funnel from first visit to sign-up is complete. A later login with a different account on the same device does not move rows that already belong to someone: the device is pointed at the new person, a new analytics session starts, and only new events go to the new person.

Each person can have up to 50 devices by default. Devices beyond that are still counted, just not merged.

Apps and mini-programs

The native SDKs expose the same login and bind. A mini-program calls login after it has the OpenID, with the OpenID type; a UnionID bound on web and on a mini-program is what joins the two. Once joined, retention and funnels in InsightsUsers treat the person as one row across web, app and mini-program.

Privacy notes

  • Email and phone passed at login stay out of the profile unless you enable encrypted contact storage in the compliance center.
  • Viewers see direct identifiers fully masked by default; Analysts see them partially masked. See roles.
  • Logins are dropped entirely when a region rule or Global Privacy Control forces tier 1 for that visitor.

Was this guide helpful?

Your answer helps us decide which guides to expand next.

Thanks for the feedback. If something is still unclear, tell us what you were looking for.

See your data clearly. Find your growth.

Every click, backed by data. Install one line of code and see your first numbers in a minute.

No credit card · Free plans for analytics and chat · Cookieless analytics