Hello @ammar, 

This kind of behavior can happen depending on your organization’s has set up user identification within your events. I did notice that the device_id that shows up in your screenshot ends with an “R” which signifies it was a randomly generated UUID set by our SDK.

If you are not setting custom device_id values, then it could be the case that you are regenerating your device_id somewhere within the users’ event flow. One thing that is interesting here is that these don't look like the device_id's that the JS SDK creates so it could be good to look into how your team is setting this value.

You could potentially be sending events from multiple pages. Since we rely on initializing our SDK on each page for cross-domain tracking, it could be the case that the SDK is being initialized on the second page without passing the device_id as we mention here: https://help.amplitude.com/hc/en-us/articles/115003135607#h_f717e48c-460c-4a17-abd7-102327673798

If you are using an SDK v6.x.x— we’ve also made some changes to our infrastructure since then which addressed reusing device_id's from cookies

Hope this helps! 

Adding to Jarren’s response -

In our analytics setup we set the custom device_id values on our end.  When I login to our web application from two different browsers, I end up starting two parallel sessions for my user_id in the event stream  - each with it’s own device_id. 

From what I understand is the expected behavior for a given session, the device_id should be constant till the end of the session. 

Hi @jarren.patao 

Thank you for your feedback, I will communicate this case with my technology team. We consider that the anomaly start after 6th January, and this date same with the new release that you mentioned regarding some changes. Sure thank you @Saish Redkar for adding the response. I’ll confirm here when my issue have already solved.