Session length, i.e. the duration of a user session on a site, is a key movement metric that has long been sought by leadership. Previous work on this issue resulted in the 'reading depth' instrument, which was enabled in production for a while but was seen by leadership as failing to answer the questions that they had. It is now disabled.
**Definition (session) **
- A user session is defined relative to a domain and a browser instance (i.e. the actual browser process running on the user's device)
- Different tabs and windows are part of the same browser instance.
- A browser instance will end when the browser process is terminated.
> A session for a domain begins when the browser instance navigates to a page under the domain, and the browser instance detects no session currently in progress for the domain.
>- A session for a domain begins when the browser instance navigates to a page under the domain, and the browser instance detects no session currently in progress for the domain.
- A session for the domain ends when the browser instance terminates, or when the browser instance has not interacted with any page under the domain for 30 minutes.
User interaction is identified with browser events. We have selected a subset which should be informative and able to be optimized.
- scroll (see notes below)
**Definition (session length)**
The length of a session is measured in ticks. A tick is a unit of time representing a certain number of milliseconds. Every user session's length begins at 0. When a tick has passed, the length becomes 1. After another tick passes, its length will be 2, and so on. Roughly every tick, a session will send its current length as an event. The difference between the number of 'n' ticks received and the number of 'n+1' ticks received, represents the number of sessions of length n. For more details, see: https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Traffic/SessionLength
#### Preview environment
Will update with beta link as soon as merge happens (next day or two).
#### Which code to review
#### Performance assessment
Please initiate the performance assessment by answering the below:
- What work has been done to ensure the best possible performance of the feature?
- Cross browser testing. No direct tab-to-tab communication. The existing asynchronous queue is used to pass information within a tab. The code will not execute when the page is not visible. The timeout intervals are long and can be adjusted via a config change.
- What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance?
- The key area will be to prevent event handlers from slowing the UI.
- Are there potential optimisations that haven't been performed yet?
- Use of vendor-specific features such as passive event handlers for scroll, Chrome's idle event, or debouncing. We wanted to arrive at the best approach through consultation.
- Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: [[ mailto:firstname.lastname@example.org | email@example.com ]].