Because of the differing nature of how visits and mobile app launches are calculated, it is possible to see different results in reporting.
- Visits: Originally designed for web analytics, a visit represents a period of visitor activity surrounded with 30 or more minutes of inactivity. See Visits for more information.
- Mobile app session: Because of differences in usage patterns with mobile apps, a mobile session is typically defined differently than a web visit. Each mobile app session begins with a launch event and ends with five minutes of the application being in background or closed. The count of mobile sessions is reported as a count of Launch events. See Mobile Metrics for more information.
Before June 2016, Adobe forgets session info once a visit expires (30 minutes of inactivity). Timestamped data matched up to a session that is considered done is counted as an extra visit. In June 2016, Adobe plans to retain timestamp-enabled session data for up to 92 days. This change does not alter the definition of a visit; visits are still groups of hits surrounded by 30+ minutes of inactivity. Instead it allows late-arriving timestamp hits to correctly tie to a visit, preventing visit inflation.
The following are potential reasons why visits would return values higher then launches for data before June 2016:
- Backdating of session info for SDK 4.1+: The Adobe Analytics mobile SDKs collect information about the length of each session, and about the number of crashes that occur. This data cannot be sent to data collection servers until the beginning of the subsequent session.
Before SDK 4.1, data for the previous visit was sent in the first image request of the subsequent visit. However, this data was temporally associated with the current visit instead of the previous visit. In SDK 4.1 and above, prior session information is sent in a separate hit and timestamps it with the previous session.
While backdating is more useful for calculating mobile metrics, it can cause a side effect. This separate hit that provides more information on the previous visit matches the criteria of a new visit. If a new session occurs more than 30 minutes apart from the previous mobile session, the backdated hit is considered an extra visit without incrementing Launches.
- Queued/batched data with offline tracking: If an app is configured for offline data collection, the mobile device caches the behavior that occurs while offline. When the device comes back online, the SDK sends the cached offline hits and starts sending online hits. If the time between the offline portions of user behavior is greater than 30 minutes, an extra visit is counted when sent to data collection servers.
Some mobile apps perform work while in the background. If those calls are sent more than 30 minutes apart (remember that 30 min without activity means a new visit in Adobe Analytics) while the mobile app is in the background, a new visit starts for each call without triggering a launch.
Technically, you can view a page (or Custom Link) that generates a new visit with no launch.
It is fundamentally important to understand that visits and launches are calculated differently:
- Visits are calculated server-side, based on server activity (timestamp of hits received in the server).
- Launches are calculated client-side, based on app activity.
Also, in iOS, you can use the method keepLifecycleSessionAlive to indicate to the SDK not to start a new session (Launch) when resuming from the background regardless of what the lifecycleTimeout value is on the config file:
From Version 4.13.6 of the SDK (iOS and Android) additional data is now automatically sent on every Analytics hit indicating whether the app was in the foreground or the background at the time the hit was generated:
Due to the differences of inactivity between mobile sessions and visits, multiple launches can fire in a single visit. For example, if a mobile user opens and closes the app once every 15 minutes for an extended time, many launches would be counted within a single visit.
If widely spaced trackLocation calls are inflating visits, reduce the time between trackLocation calls to less than 30 minutes or disable trackLocation.
- Create a hit-level segment defined as Exclude Hit where Custom Link equals ADBINTERNAL:SessionInfo
- Create a segmented calculated metric using the above segment against visits.
- Use this calculated metric instead of regular visits when viewing reports.
Note: If the above segment is applied to a report outside a calculated metric, the following side effects are seen:
- Crashes would report zeroes for date ranges where backdated hits exist
- Previous session length would report zeroes for date ranges where backdated hits exist
- Occurrences are reduced by the number of backdated hits
- Custom link instances are reduced by the number of backdated hits