How to Identify Logged-In Users in Session Replay (Safely)

Short answer: call an identify function once after login with your internal user ID and a few non-sensitive attributes such as plan. Use an opaque ID as the key, send only what a teammate should be able to read, never send passwords, tokens, or payment details, and make sure your privacy notice and consent cover it.

Table of Contents

1. Why Identify Users
2. How It Works
3. What to Send
4. What Never to Send
5. Where to Call It
6. Privacy and Consent
7. Checking Your Setup
8. Key Takeaways

Why Identify Users

Without identification, every session is an anonymous visitor. That is fine for a marketing site and limiting inside a product.

• Support can find the session behind a ticket instead of asking the customer to describe it.
• Engineering can reproduce a bug with the exact steps and account state.
• Product can compare users who activated with those who did not.
• Success teams can see how a key account actually uses the product.
• Deletion requests can be fulfilled, because you can find a person's data.

How It Works

A visitor starts with a persistent anonymous ID. When you call identify, that anonymous profile is linked to your own user ID. In DeepSync, every past and future session from that person becomes searchable by it (SDK API).

deepsync("identify", user.id, {
  email: user.email,
  plan: "pro",
  signupDate: user.createdAt,
});

Call it once after login. Most installs never need any other SDK call.

What to Send

Use an opaque internal ID as the key, not an email address. IDs do not change when someone updates their email, and they reveal nothing by themselves.

Whether to include email is a judgement. It makes support lookups easy and it is personal data. If you include it, restrict dashboard access and state it in your privacy notice. If you would rather not, look users up by internal ID from your own admin tool.

What Never to Send

• Passwords or password hashes
• Session tokens, API keys, or reset links
• Full payment card or bank details
• Government identifiers
• Health, financial, or other sensitive categories
• Free-text notes about the customer

The DeepSync docs give a simple test: whatever you pass is stored and becomes visible in the dashboard, so send identifiers and attributes you would be comfortable having a teammate read.

Where to Call It

• After a successful login, once you have the user object.
• On page load when a session already exists, so returning users are identified without logging in again.
• After signup, as soon as the account is created.

In a single-page app, call it from the place that resolves the current user. Guard it so it runs once per user rather than on every render.

The loader is asynchronous. If your code might call identify before the SDK has finished loading, add the command-queue stub from the SDK docs above the loader tag so the call is buffered.

On logout, make sure the next person on a shared device is not attributed to the previous user. Check the SDK reference for how to reset identity, and test it by logging out and in as a different account.

Privacy and Consent

1. Consent still applies. In consent-required mode, nothing is collected until consent is given, including identification (consent modes).
2. Tell users. Your privacy notice should say that product usage is recorded and linked to accounts, and why.
3. Mask what the page shows. Identifying a user does not unmask anything, but logged-in pages display more personal data. Audit them (PII masking).
4. Limit access. Not everyone needs to look up individual customers.
5. Use it to help. Looking up a session to fix a customer's problem is the purpose. Browsing individuals out of curiosity is not.
6. Honour deletion. Identification is what makes erasure possible; DeepSync provides export and erasure on every plan (privacy tools).

Checking Your Setup

1. Log in with a test account.
2. Browse for a minute.
3. Search sessions for the test user's ID.
4. Confirm the session appears with the attributes you sent, and nothing you did not intend.
5. Log out, log in as a second test account, and confirm the sessions are attributed separately.
6. Watch the recording and check that on-screen personal data is masked.

Key Takeaways

• Identify once after login, keyed on an opaque internal ID.
• Send only attributes a teammate should be able to read.
• Never send passwords, tokens, or payment details.
• Cover it in your privacy notice and test logout.

Conclusion

Identifying users turns session replay from a research tool into a support and debugging tool. Done carefully, it also makes privacy requests easier to honour.

Read the SDK API docs.