Session timeout not working as expected

[ifbarrera]

Expected Behavior

We somewhat recently migrated from the JavaScript SDK to v2 browser SDK and immediately noticed our average session lengths blow up across the board (from about an an average of 11m / session to over 4 hours). Upon closer inspection, we noticed that events were no longer being grouped together correctly into sessions – events that happened hours apart are being grouped together into the same session (same session ID), while events that should have the same session ID, don't.

Current Behavior

Something seems to be wrong with the session timeout managed by the v2.0 browser SDK.

See an example below:

• 8 events all happened within a minute of each other (on Feb 20th at 7.46pm), the first of which was a sign in user event (this is commonly the first event recorded in a session for our app). However, the sign in event has a different session ID than the rest of the events, so it's actually grouped under a different session.
• Then, at 6.41pm on Feb 27th seven days later, another sign in user event is triggered – yet somehow, it gets the same session ID as the events that happened on Feb 20th. This gives this particular session a session length of over 7 days, which is clearly wrong.

Possible Solution

We're not really sure what's going on here. When we were using the JavaScript SDK we didn't have this problem, and nothing has changed in the way we've configured the two SDKs. See below for our configuration of the v2.0 browser SDK ("@amplitude/analytics-browser": "^2.3.7"):

amplitude.init(apiKey, {
    appVersion: PACKAGE_VERSION,
    defaultTracking: {
        attribution: true,
        pageViews: false,
        sessions: false,
        formInteractions: false,
        fileDownloads: false,
    },
    // logLevel: amplitude.Types.LogLevel.Debug, //uncomment for debug amplitude logging
});

Note that we have session event tracking disabled, but we originally had it enabled and that didn't seem to matter for this particular bug. We don't want Amplitude to track session start/end events, but that's shouldn't affect its ability to create session IDs and group events into sessions, from our understanding?

Prior to the v2.0 migration, this is how we configured the JavaScript SDK ("amplitude-js": "^8.2.0"):

amplitude.getInstance().init(apiKey);
amplitude.getInstance().setVersionName(PACKAGE_VERSION);

Steps to Reproduce

Not really sure how to reproduce, it happens for most of our sessions.

Environment

• JS SDK Version: "@amplitude/analytics-browser": "^2.3.7"
• Installation Method: npm install
• Browser and Version: all browsers and versions

Happy to share more examples if it's helpful. Thank you!

[izaaz]

@ifbarrera thanks for creating this issue. Can you please share the URL to a sample user that is running into this problem so I can take a closer look?

[ifbarrera]

@izaaz do you mind sending me an email? I'd rather not share URLs to our project/users on a public repo

[izaaz]

For sure. Please send the link to

[izaaz]

Synced offline @ifbarrera. The issue was that the page was fetching the session id before amplitude was initialized and was being passed to the server for server side event tracking. Since amplitude was not initialized yet, fetching the session id returned the previous session id and not the new one. Hence server side events were tied to the old session and not the new session.

@ifbarrera resorted to using Amplitude's server side session config: https://help.amplitude.com/hc/en-us/articles/115002323627-Track-sessions