session_end ts matches the session start of next session
Article ID: 132534
Updated On:
Products
CA App Experience Analytics
Issue/Introduction
Question about couple of last entries in the session where it seems like associated with next session.
Like to know if it is by design and purpose of these items where it does not see belong.
session_end ts matches the session start of next session
Like to know if it is by design and purpose of these items where it does not see belong.
session_end ts matches the session start of next session
Environment
Release:
Component: AXAENG
Component: AXAENG
Resolution
Details are as follows:
sessions do not overlap in terms of timestamps. (Verified crashes , and apis as well).
This is small summary of how session boundaries are controlled.
Mobile SDKs (Both Android & iOS)
Session is defined as an active use of an application for a continuous time period.
In AXA SDKs a session lifecycle is controlled by the following trigger points :
New Open Case : When application is opened from a closed state (i.e app process is not running before). The timestamp(epoch) of session start recorded here is current timestamp which device clock represents.
Timeout Case : When application is in background for more than a defined timeout (30 seconds - default ) and is reopened from its background state. This timeout ends the session (previous) with which App went background.
Previous session is marked ended with current device timestamp.
New session starts with current device timestamp,
App Killed Case : When App is killed
User decides to kill the app.
When user kills the app , the process is killed. The session lifecycle ends here. But session end cannot be marked in the case. The last event’s timestamp collected for session represents the session end timestamp.
App Crashes.
Process is killed in this case. Crashed timestamp represents session end. If a feedback comes at a later point of time to be marked against the crashed session.
Operating System sends an interrupt to force close app.
This case is same as “User decides to kill the app”.
Controlling Session boundaries.
New Sessions can be started via api through stopAndStart session , so app can control and sync with “App user”s post login sessions.
Gaps in sessions can occur for below use cases - when this can occur : Expected as timestamp is device clock.
If the user is in background for a longer time than intended , there can be gaps between sessions.
If the crash occurs - and the app has not reopened for a longer time. There can be gaps.
sessions do not overlap in terms of timestamps. (Verified crashes , and apis as well).
This is small summary of how session boundaries are controlled.
Mobile SDKs (Both Android & iOS)
Session is defined as an active use of an application for a continuous time period.
In AXA SDKs a session lifecycle is controlled by the following trigger points :
New Open Case : When application is opened from a closed state (i.e app process is not running before). The timestamp(epoch) of session start recorded here is current timestamp which device clock represents.
Timeout Case : When application is in background for more than a defined timeout (30 seconds - default ) and is reopened from its background state. This timeout ends the session (previous) with which App went background.
Previous session is marked ended with current device timestamp.
New session starts with current device timestamp,
App Killed Case : When App is killed
User decides to kill the app.
When user kills the app , the process is killed. The session lifecycle ends here. But session end cannot be marked in the case. The last event’s timestamp collected for session represents the session end timestamp.
App Crashes.
Process is killed in this case. Crashed timestamp represents session end. If a feedback comes at a later point of time to be marked against the crashed session.
Operating System sends an interrupt to force close app.
This case is same as “User decides to kill the app”.
Controlling Session boundaries.
New Sessions can be started via api through stopAndStart session , so app can control and sync with “App user”s post login sessions.
Gaps in sessions can occur for below use cases - when this can occur : Expected as timestamp is device clock.
If the user is in background for a longer time than intended , there can be gaps between sessions.
If the crash occurs - and the app has not reopened for a longer time. There can be gaps.
Feedback
Yes
No
Powered by
