Anonymous activity lost at login: confirm the problem

When someone browses anonymously and then signs in, Amplitude should join both halves of that session into one profile. When the join breaks, everything the person did before login lands on a separate anonymous profile. Their acquisition and onboarding behavior vanishes from funnels and retention, even though you tracked it.

This is easy to miss. Both sets of events exist. They're just filed under two different people. Data Assistant doesn't check this transition, so you confirm it yourself. The lasting fix is an instrumentation change, but the diagram below shows exactly what has to hold true, and you can prove whether it does.

Run this audit when onboarding funnels drop off unexpectedly right at the login step, or as a check on your sign-in flow. You need a clean test environment and permission to open User Profiles. This procedure validates representative devices. It doesn't prove that every identity across your audience joins correctly.

Test the anonymous-to-known transition

1. Start with a private browser window, a new browser profile, or a test device with cleared app data.
2. Record the device ID. Event Explorer can locate the test device by IP address or device ID.
3. Complete two or more actions before you sign in.
4. Sign in with a test account and complete two or more authenticated actions.
5. In Amplitude, go to Users > User Profiles and search for the test account's User ID.
6. Open the profile and review the Activity timeline.
7. Confirm the timeline includes both the anonymous events and the signed-in events, in the expected order.
8. Search for the original device ID and confirm it resolves to the same person, not a separate anonymous profile.

Read the result

• If one profile holds the complete journey, the sample passes.
• If the pre-sign-in events stay on another profile, compare the raw device_id values immediately before and after sign-in.
• If the device ID changes at sign-in, or the first signed-in event has no user_id, that's the break. Record those details for your engineers.

What Amplitude can and can't do here

Amplitude joins an anonymous device to a known person going forward, once the instrumentation is right. It can't retroactively reunite activity that already split onto two profiles in a standard project. So the goal is to fix the login flow, and the audit above is how you confirm what broke.

Hand it to whoever owns your tracking

The fix is a code change in the login flow. Give your engineers the device-ID evidence. Copy this and fill in the brackets:

In Amplitude, anonymous activity isn't joining to the user at login. In a test
session, the anonymous events show device_id [D-BEFORE], but after sign-in the
events show device_id [D-AFTER] and/or the first signed-in event has no user_id.
The pre-login activity is landing on a separate anonymous profile. Keep
the same initialized SDK instance across login, don't regenerate the device_id,
and set the canonical user_id after authentication before the next event. This is
dropping onboarding activity from our funnels.

If you have no engineering resources

You can't repair the join 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.

When you're ready to preserve the device relationship at login, continue with the engineering solution.