<div dir="ltr">Hi all,<div><br></div><div>I've been thinking about Telemetry and FHR unification, and I think we have to be careful around the new ping semantics. Client-side changes require backend architecture changes, and both ultimately determine which analyses are convenient or even feasible.</div><div><br></div><div>To recap, we are merging 3 measurement systems with different semantics:</div><div><ul><li>Telemetry's measurements are implicitly "<b>per session</b>". Telemetry creates a new ping a the beginning of every Firefox session and records a "saved-session" ping at the end of the session. </li><ul><li><i>There is also an "idle-daily" ping sent during the session at most every 24 hours, but there are backend problems so idle-dailies are <i>currently </i>not <i>being </i>used for anything</i></li></ul><li>FHR's reporting of user activity & browser state is mostly with respect to <b>calendar days</b></li><li>TelemetryExperiments focus on differences between the test group and the control group</li></ul></div><div>We wish to unify the FHR & Telemetry pings into a single ping and make data collected during A/B TelemetryExperiments more precise.</div><div><b><br></b></div><div><b>So first off, let me describe my intepretation of the <a href="https://docs.google.com/document/d/1IGpzsYGi_sq3YFQDAPyKOkU_BKvXAC95fZYA2i4ceVs/edit#">current unification proposal</a>:</b></div><div><ul><li><font color="#ff0000">Whenever a new ping is started, all the FHR & Telemetry measurements for the current session will be reset</font></li><li>In the new system, Firefox starts collecting a new ping whenever:</li><ol><li>a new Firefox session is started</li><li>a new day has begun (not sure if it's every 24 hours of uptime, or if it's based on local time e.g. midnight local time)</li><li>whenever the Firefox "environment" changes</li><ul><li>Examples: a user enables or disables an addon, the graphics driver is updated, an A/B experiment begins or ends (this happens in the middle of a session), Firefox HW acceleration is disabled, etc<br></li></ul></ol></ul>This proposal has some nice properties unique to it:</div><div><ul><li>Relatively straightforward to implement on the client</li><li>No duplicated measurements (the existing Telemetry "saved-session" pings duplicate the measurements in the "idle-daily" pings)</li><li>Data is sent to Mozilla servers quickly (no ping covers more than a 24-hour period, so no waiting for a session to end)</li></ul></div><div>However, I think these semantics would create a lot of problems for Telemetry analysis:</div><div><ul><li>It will be hard to do per-session analyses</li><ul><li>It's going to be hard to re-construct sessions from session fragments on the Telemetry server</li><ul><li>A 2-week long session will have at least 14 pings scattered across 14 daily archives</li></ul><li>The reconstruction process could get messy and fragile<br></li><ul><li>Code for merging different histogram types, dealing with missing session fragments, storing and updating the merged pings, backfills, correcting errors, etc.</li><li>For FHR's needs, I think this is unavoidable (and easier!), unless we go back to submitting 6-month user histories in every ping as FHR does now</li><li>It's better not to do these kinds of reconstruction jobs unless if we absolutely have to </li></ul></ul><li>Many of the 1000+ Telemetry measurements are inherently "per-session" and can't meaningfully be split into session fragments:<br></li><ul><li><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe#Choosing_a_Histogram_Type">Flag histograms</a> track feature usage per-session.<br></li><ul><li>They are automatically initialized to a value of "false" at the beginning of a session, and can only be set to "true" once.<br></li><li><span style="color:rgb(204,0,0)">If we reset Telemetry measurements every time we create a new ping, we'll be reporting nonsense: pings from the same session will contradict each other on whether a feature was ever used during the session</span><br></li><ul><li>This would feed bad data to both the dashboards and any custom analyses<br></li></ul></ul><li><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe#Choosing_a_Histogram_Type">Count histograms</a> are also per-session measurements. You can't aggregate a count-histogram value from the middle of a session together with final values from other sessions<br></li><li>You might be saying: "So only report those histogram types in the final ping of the session!"</li><ul><li>We don't know all the histograms that need this treatment. Other histogram types are being used to represent per-session measurements such as configuration settings or feature usage, e.g. "CANVAS_2D_USED" boolean histogram<br></li><ul><li>Some keyed-histograms have per-session semantics, some don't</li></ul><li>Some Telemetry users want measurements expressed in "per session" terms and those measurements aren't necessarily in count & flag histograms</li><li>See next point about custom analyses</li></ul></ul><li>For custom analyses, we sometimes want to correlate measurements from the beginning of a session with measurements from the end of a session (which could have lasted several days), e.g. histograms related to startup performance vs later performance</li><ul><li>We would need that messy server-side session reconstruction process to get at per-session data.</li><li>More generally, a ping generated as a result of local time & environment changes is not inherently meaningful to us, unlike a full user session</li></ul><li>Resetting Telemetry and FHR data when a TelemetryExperiment begins removes valuable context from the experiment ping. It's possible to reconstruct it, but that's yet another server-side job to run</li><li>There's overhead from sending a new ping for each mid-session environment change</li><ul><li>There's also a small privacy issue with creating ordered, fine-grained reports of user actions, e.g. when a user goes through their add-ons list and disables 5 addons, we report each user action</li><li>Either coalesce successive environment-change pings, or carefully vet which mid-session environment changes generate a new ping</li></ul></ul>I'd like to propose that we implement the following modifications to the FHR/Telemetry v4 document:<br><ol><li>Do not reset <u>Telemetry</u> measurements when a session crosses the 24-hour boundary</li><ul><li>Continue to "reset" Telemetry measurements when we start a new session</li><li>There's no need to reset Telemetry on most environment changes (e.g. amount of memory installed) since those can't happen without a Firefox restart anyway.</li></ul><li>Record mid-session environment changes (add-ons and TelemetryExperiments) in a special section in the ping.</li><ul><li>For each such environment change, document the change in the section and also attach a snapshot of the Telemetry & FHR data at the time of the change</li><li>After the snapshot is saved, reset Telemetry and FHR measurements for the current session. In other words, snapshot & then build up a diff<br></li><li>For each additional environment change during the same session, just repeat and append to the new section<br></li><li>Telemetry backend scripts (dashboard, regression detector etc) can just ignore experiment/add-on change pings</li></ul></ol>This model has some nice properties:</div><div><ul><li>The <b>final ping</b> of a session is equivalent to a Telemetry saved-session ping</li><ul><li>Per-session analyses are as easy to do as before</li></ul><ul><li>No need to run any session reconstruction jobs!</li></ul><li>Every main ping submitted is meaningful without needing any reconstruction steps. All pings will contain the current FHR state + all the Telemetry measurements from the current session<br></li><li>Most pings will only have one environment change, so the relevant measurements that happened after the change are all going to be in the regular Telemetry/FHR section</li><li>However, when deeper analysis is required, Experiment pings will also have information about what was happening BEFORE the experiment began</li><li>Analyzing pings with multiple environment changes won't be much harder</li></ul><div>Admittedly, there is a trade-off to not resetting Telemetry after the 24-hour period. </div></div><div><ul><li>Since each main ping submitted will contain Telemetry data from the start of the session, getting Telemetry data collected over a single day will be hard. I think this is an acceptable tradeoff.</li></ul><div>I want to mention a few other solutions, but these are not as appealing:</div></div><div><ul><li>Collect and submit both per-session and per-ping Telemetry data... This doubles Telemetry run-time memory use</li><li>Reconstruct sessions by merging saved pings on the client-side... I think this would be a mess</li><li>Have TelemetryExperiments take effect on restart instead of mid-session... This biases the experiment data against longer-running sessions, and addons would still be an issue</li></ul><div><br></div></div><div>Let me know what you think.</div><div><br></div><div>Thank you,</div><div><br></div><div>Vladan</div></div>