Life Cycle, Session, User
This section covers the way Smartlook automatically follows application life cycle, and introduces the concept of recording sessions and users.
Apart from the initial Smartlook setup when a new instance of an application starts, Smartlook follows the life cycle of the application automatically. When the application is suspended to the background, recording is paused automatically. When the application resumes to the frontend again, the recording resumes. There is no need to call API methods to achieve this basic behaviour.
Sessions roughly correspond to individual application “runs”.
This does not mean, however, that each interval when the application is on screen is always recorded as a separate session. When an application is suspended to the background just for a short period of time (e.g., it is interrupted by an incoming call, notification), the original session continues when the application is resumed. If the application is closed for several minutes, a new session will start at the next application opening.
To change this default behaviour, an API method that resets the session must be called when appropriate, as described later in this document.
Smartlook records user interactions with the application in sessions.
Every session has a single user. A single user can have multiple sessions.
User can be uniquely identified by a respective identifier:
This call associates the current user with the provided id. If a user with such an id already exists in one of your Smartlook projects, the session is automatically assigned to that user.
When this method is called again with a different user identifier, it does not create a new user, it changes the id of the user currently associated with the session. To “login” a new user, use the resetSession method described in the following section.
The application remembers the last user id and reuses it as the default user id with each new session (i.e., when the application is launched again on the device). This happens even when the user is not identified explicitly. This ensures that when the application runs again on the same device, the implicit users are by default associated together.User identification API Reference
In some use cases it makes sense to explicitly control the session and users flow. For example, when a device with an application is shared among many users. In these cases the application should always start with a fresh session (or user). To do so, use one of the following setup option:
When it is desired to start a new session, or login a new user while the application is running, it is also possible by using a dediceted
resetSession method. This method takes one paramter, the indicates, whether the user identity should be also reset, or whether the new session should retain the user from the current session:
It is not recommended to call this method when the application is being closed. Smartlook is busy with cleaning up when the application is going to background, and calling this method may create ephemeral sessions as an unwanted consequence. If it is prefered that sessions do not continue with the next application launch under any circumstances, the setup resetSession options when initializing Smartlook should be used instead.
Smartlook follows the application life cycle automatically and it is not necessary, under normal circumstances, to stop and restart recording programmatically.
However, in situations when it is practical to record just a small part of the application, it is still possible to stop and start recording programmatically. Smartlook API has methods to stop and start the recording, as well as a property that returns the current recording state.Start and Stop Recording API reference
When the recording is controlled programmatically this way, the time the user spends in the rest of the application is not visible on the timeline. Thus, for just a short recording interruption (e.g., when the user fills in some form full of sensitive data), consider switching to some combination of rendering and event tracking modes. This way, the time the user spents incognito is visible on the timeline. More about this can be found in Handling Sensitive Data.
In many cases, it is convenient to associate some custom properties to the current session and user. Details could be found in the respective API Reference
Currently, only string values are accepted both as property keys and values.