This article has been authored and contributed by Alexis Cazes, Lead Technical Support engineer at Adobe.
|Lifecycle Timeout||Minimum SDK Version - 4.0||
Default: 300 seconds
Specifies the length of time, in seconds, that must elapse between app launches before the launch is considered a new session. This timeout also applies when your application is sent to the background and reactivated. The time that your app spends in the background is not included in the session length.
The app is sent to the background when the user goes to the home screen, switches to another app, or when the phone locks. Any time the app goes to the background session length calculation is paused.
For example, my phone is set to auto-lock in 2 minutes, so when I have an app in the foreground and I engage with it for 3 mins, step away from my phone, and my phone auto-locks after 2 mins of inactivity on the device,.In this scenario, the 2 minutes before the app is sent to the background when the phone is locked is counted as part of the session, so the total length will be 5 minutes
Previous Session Length is a Lifecycle metric and is calculated in seconds.
For example: We install app ABC and launch and use it for 2 minutes and then close the app. No data is sent about it this session time. The next time we launch it, Previous Session Length will be sent with a value of 120. This metric also does not calculate the time the app is in the background, only when in use.
The name of this metric in the mobile services interface is "Total Session Length"
Average Session Length (Mobile) is a calculated metric. It is defined as:
[Previous Session Length] / ( [Launches] - [Installs] ) and measured in seconds.
As said above in the mobile services interface Previous Session Length is "Total Session Length" Installs would be First Launches :
So we have the following:
Launches : 1,433,763
First Launches : 807,184
Launches - First Launches = 1,433,763 - 807,184 = 626579
Total Session Length = 5,657.21 years = 178405774560 seconds (as per http://www.convertunits.com/from/year/to/second)
So, Average Session Length = 178405774560 / 626579 = 284729.8976824949 seconds = 3.2954849268881095 days = 3.30 days
So that is for the explanation on how all these metrics are calculated. Now if you used an SDK version below, then you need to be aware that there were issues with session length tracking .
iOS 3.3.2 / 4.0.1
Android 3.2.5 / 4.0.2
However if you always used a version equal to or greater than those versions then there should be no issue.
- An app is installed: First launches is incremented, Launches is incremented. It is the start of a new session. It is a start of a new visit
- If the default 30 min without image request sent to our servers: Adobe Analytics Visit is incremented. (For Adobe Mobile services : Launches is incremented and it is a new session ==> conditional that the lifecycleTimeout is not more than 30 min).
- If no image request is sent in the time specified in the lifecycleTimeout settings (either the app did not send any hits or App is in background ) then, Launches is incremented and a new session is started. Visit might or might not be incremented:
- If the lifecycleTimeout is 45 minutes, and the user come back from background after 35 minutes that would be a new visit, but not a new launch. If it after 45 then there will be a new Visit and a Launch
- If the timeout is 300s (5 min) and the user background the app for 10 minutes, then relaunches, that would be 2 launches in a single visit and no new Visit.
- The app crashes, it will always get a new session the next time the app is started. Launches incremented. Visit not incremented if under 30 minutes window.
- Otherwise, you will only get a new session if the time since the app was backgrounded is greater than the lifecycleTimeout value in the config file. Note that physically closing the app from task manager doesn't really play into this, as the app will be backgrounded prior to the user entering task manager mode.
Visits are measured by activity server-side with a 30 minute timeout, and app launches are measured device-side with a user-defined timeout, the two numbers don’t usually match.