This is a quantum release criteria. Will need count of total sessions, and count of sessions with ghost_windows.
We are running into two problems here: 1. Looking at the current notebook which processes this metric for Quantum RC , it uses % of subsessions, not % of sessions. I'm not sure we can guarantee that these two metrics will be the same; subsessions will be skewed towards longer sessions. 2. We don't actually have the session_id in main_summary, meaning the best we could do is compute this value moving forward. We could do a backfill but this is difficult and expensive . [If it is important we correct this, it certainly can be done.] Now, in conjunction with each other, these issues solve itself - if we decide that % of subsessions is acceptable, then we can compute this value historically. Stuart, Harald mentioned you might have some idea about this?  Bsmedberg's daily latency metrics notebook
[Taking this while :sphilp is out] Frank, it seems hard to make that decision without better knowing the impact. - Are there alternatives, like usage hours? - Is there an analysis that compares subsessions to sessions. - One step further, is it possible to have a simple analysis that compares the aggregate of % of subsessions aggregate with % of sessions?
Are there valid reason to reset these counts on certain subsession splits? I can see something like an environment change, like installing a new addon, causing an increase in ghost windows for that new subsession could be pretty valuable information. Though we expect ghost windows will decrease with the move to webextensions, there seems to be some debate there and having this data would be useful. Perhaps there are other reasons too, like is there any risk of losing session data that more frequent subsession/aborted/daily pings might help collect? I'm not sure if we suspect ghost windows to be related to uptime, but that could also be useful to understand as well. I think subsession would be acceptable, but I also don't know BDS's reasoning for wanting sessions. Is this something that can wait until he is back from PTO (14th) or do we need to answer this this week?
(In reply to :Harald Kirschner :digitarald from comment #2) > Frank, it seems hard to make that decision without better knowing the impact. > > - Are there alternatives, like usage hours? Certainly, we could have a rate of Ghost Windows, with the denominator being session_hours. Alternatively, if we make the numerator sessions_hours and the denominator # of Ghost Windows, we could get MTBF. > - Is there an analysis that compares subsessions to sessions. > - One step further, is it possible to have a simple analysis that compares > the aggregate of % of subsessions aggregate with % of sessions? We don't have any analysis like this, but certainly makes sense to investigate the differences between the two.
Sphilp & Digitarald - I'm moving this to MC because we should implement this in error_aggregates. We will be doing a backfill (see bug 1388351). This means we can use % of sessions as intended, without making any tradeoffs. This implementation will parallel HLL Client Counts, where we can have one HLL that is count of distinct client-sessions, and another that is a Filtered HLL count of client-sessions with ghost_windows > 0. Then we can use the same calculation as client_counts to find % of sessions with ghost_windows > 0.