User IDs set too early: confirm the problem

A user_id should appear only after your product reliably identifies a user. If your product sets the ID too early, Amplitude associates unrelated anonymous activity with the same identity. For example, a shared device or an ID cached from a previous account can merge events from different people into one inaccurate profile.

Charts still render, so the problem isn't obvious. Merged profiles make acquisition, onboarding, and first-session analysis inaccurate. Data Assistant doesn't detect identity timing problems, so you must confirm the problem manually.

Run this audit when a new visitor's profile contains more activity than expected. You can also use the audit to validate a new anonymous journey. You need a clean test environment and access to the product. Amplitude can't determine when your application considers a user authenticated. Therefore, a full audit requires raw event data and a product-specific authentication signal. This procedure tests one journey at a time.

Create a clean anonymous journey

1. Use a private browser window, a new browser profile, or a test device with cleared app data.
2. Open the product without signing in.
3. Complete several actions that an anonymous visitor can take.
4. Find the test device in Event Explorer by IP address or device ID. You can also use Users > User Profiles if you know the device ID.
5. Open each pre-authentication event and inspect its raw properties.
6. Confirm user_id has no value before your product authenticates the user.
7. Sign in, trigger another event, and confirm the post-sign-in event uses the expected User ID.

Read the result

• If pre-authentication events have no user_id and post-sign-in events use the stable account ID, the sample passes the audit.
• If an anonymous event carries a placeholder, an email address, a cached ID from another account, or another premature value, write down the source library and the first affected event.
• If your product restores a valid signed-in session on launch, setting the known User ID during initialization isn't an error. The product must be able to identify the user reliably at that moment.

Amplitude can't repair merged profiles

No chart or agent can separate a profile created with an early User ID. In a standard event-based project, Amplitude can't split an established User ID into the different people whose events it combines. Fixing the problem requires an instrumentation change that prevents early User ID assignment. Use Amplitude to verify the incorrect timing and identify its source.

Give the evidence to your tracking owner

Send your engineers the timing evidence. Copy this and fill in the brackets:

In Amplitude, we're setting user_id before authentication. On a fresh anonymous
session, event [EVENT NAME] from [SOURCE / SDK] arrives with user_id already set
to [VALUE, e.g. a placeholder / cached email / previous account id]. That merges
unrelated anonymous activity onto one identity. Leave the User ID unset
for unknown visitors and assign the canonical user_id only after authentication
confirms who the person is. Also confirm logout clears the User ID on shared
devices.

Get help without engineering resources

You can't correct the timing inside Amplitude. Reach out in this order:

• Your Amplitude account team or Customer Success Manager.
• A partner or agency that manages your website or app analytics.
• Amplitude Support at gethelp.amplitude.com for product questions.

For implementation guidance about User ID timing and logout behavior, go to the engineering solution.