User Identity Tracking: How to Link Analytics to Individual Users

Most analytics tools count visitors as anonymous sessions. That works fine for measuring traffic volume — but when you want to understand how a specific customer moved through your app, or why a power user churned, anonymous session data gives you very little to work with. User identity tracking bridges that gap by associating your existing user IDs with the analytics record.

This guide explains what identity tracking is, how to implement it with statpx in a few lines of code, and what guidelines to follow around user traits and privacy.

Anonymous Visitors vs. Identified Users

By default, every visitor is tracked as an anonymous session. statpx assigns a temporary session ID to each browsing session — useful for measuring aggregate traffic, bounce rates, and popular pages, but not for linking two visits from the same logged-in customer. If that customer visits your pricing page on Monday and upgrades on Thursday, those two sessions look like two unrelated visitors.

Identity tracking changes that. When a user logs into your app, you call a single JavaScript function that tells statpx "this session belongs to user ID 4821" (or whatever your internal identifier is). From that moment forward, pageviews and events in that session are linked to that user. If the same user comes back next week and logs in again, statpx can connect the dots across sessions and show you their full history.

The identifier you pass is your own — a database primary key, a UUID, or any string your backend already uses. statpx stores it alongside the session data; it never generates or manages your user IDs.

How to Implement Identity Tracking with statpx

The _st('identify', ...) call is the only code change required. Add it in your app after confirming the user is authenticated — typically right after your session or auth check on any logged-in page:

The first argument is always 'identify'. The second is your user ID string. The third (optional) is a plain JavaScript object of key-value traits you want to store alongside the identity.

Important: only call _st('identify', ...) when the user is confirmed to be logged in. Never call it on public pages where authentication has not been verified. Calling it with an empty string or an unauthenticated placeholder will pollute your identity data. A clean pattern is to echo the identify call from your server-side template only on authenticated pages:

What the Users Page Shows

Once identity calls start flowing in, the Users tab in your statpx dashboard becomes populated. For each identified user you can see:

• The user ID you passed
• Their stored traits as a JSON object
• First seen and last seen timestamps
• Total session count and total pageview count
• A chronological list of pages visited in their most recent sessions

The list shows the last 100 identified users sorted by last_seen descending, so your most recently active users are always at the top. You can click any user to drill into their full session history.

User Traits: What to Capture and What to Avoid

Traits are metadata about the user that help you segment and filter your analytics. The most actionable traits are ones that describe the user's account or behavior in your product:

• plan — free, starter, pro, enterprise
• role — admin, editor, viewer
• account_age — days since signup (calculated server-side)
• company — useful for B2B products

These let you answer questions like "do pro users engage with the Reports tab more than free users?" or "which features do admins use that editors don't?"

Never store passwords, payment card data, social security numbers, or any credentials in traits. These are passed through the browser and stored in your analytics database — they belong only in your secure backend. Email is low-risk from a security standpoint, but consider your privacy policy and whether your users expect their email to appear in analytics systems before including it.

Identity vs. cookies

The statpx identify call does not set any browser cookies. Identity data is stored in localStorage on the client and transmitted to the statpx collector via the existing tracking request. Because no third-party cookies are set, GDPR cookie consent is not required for identity data stored client-side — though you should still disclose analytics in your privacy policy. This keeps the implementation clean without any consent-banner dependencies.

Using Identity Data for Segment Analysis

The real payoff from identity tracking is segmentation. When you filter the Users list by plan, you can directly compare which pages and features pro users visit versus free users. If pro users consistently visit the Integrations page but rarely reach the Billing page, that's a signal about what makes the pro tier valuable to them. If free users hit a feature page repeatedly before converting, that's a candidate for a targeted upgrade prompt.

Combined with custom event tracking, identity data becomes even more powerful. An event like export_clicked paired with the user's plan tells you exactly which segment is using that feature — and which isn't.

For teams building privacy-conscious products, identity tracking in statpx is designed with minimal data collection in mind. There are no third-party scripts, no advertising network integrations, and no data sharing. Everything stays in your own statpx account. If you want to understand the full privacy architecture, see our guide on privacy-friendly analytics.

The Bottom Line

Anonymous traffic data tells you what pages are popular. Identity tracking tells you who is using them. The implementation is a single JavaScript call after your auth check, and the insight it unlocks — a full per-user session history, trait-based segmentation, and cross-session journey tracking — is substantial. For any product with logged-in users, identity tracking is one of the most direct ways to turn raw analytics data into actionable product decisions.