Does MW support LocalStorage and do we have a wrapper for expirations?
Re: We do not want to store the token on SessionStorage as this is fresh per tab, does MW support LocalStorage and do we have a wrapper for expirations? (likely answer: no)
MediaWiki provides an abstraction around local and session storage,
mw.storage.session respectively. Those global variables are both instances of
SafeStorage. Unfortunately, that class doesn't implement TTLs but it shouldn't be too difficult to add to a subclass. Phuedx (talk) 18:36, 19 June 2019 (UTC)
Browser support for Page Visibility API
You note in the document that the browser will need to support the Page Visibility API. This shouldn't be an issue as browser support for the Beacon API is worse than for the Page Visibility API (see https://caniuse.com/#feat=beacon and https://caniuse.com/#feat=pagevisibility respectively) and there are issues with not using the former. Phuedx (talk) 18:36, 19 June 2019 (UTC)
Handling Page Lifecycle events
Google Chrome added support for the Page Lifecycle API in v68.
On a mobile device (more generally, a device with limited resources), there are two state transitions that a page could undergo that might impact our definition of session length:
- The page is discarded and then loaded: The page is frozen (as above), the user doesn't switch the tab to the foreground for some time, the browser discards the frozen tab to free memory but the tab (practically, the favicon and title) remain visible to the user. Some time later the user switches the tab to the foreground and the browser loads the page
I think that the current design will be resilient to #1 as instrumentation will pause and persist its state when the page is hidden, a state transition that MUST occur before the page is frozen, and vice versa. However, you might want to consider if the situation in #2 constitutes a single session or multiple sessions. Phuedx (talk) 12:55, 20 June 2019 (UTC)
There should be some way of calculating session length statistics (average, median, percentiles) using this data/stream by an experimental group. That is, Product teams will want to test UI/UX changes that move SessionLength-based metrics, so we want to be able to test the hypotheses (e.g. web team modernizing the desktop skin will likely cause users to stick around longer, as their experience will be more pleasant).
If there is a session ID that is included with pings, the client can send a separate event with (session id, experiment, bucket) info. Otherwise, I think the final schema for this will need to include an optional
experiment/group field that can be used to tag events from sessions enrolled in an A/B test. - Bearloga (talk) 13:23, 26 July 2019 (UTC)
- +1. It's unclear from the current documentation what the granularity will be, but it is essential that this is possible. I think the key thing is that these are either defined up-front in partnership with product or we can derive them from session depth counts. Jkatz (talk) 21:17, 21 August 2019 (UTC)