<div dir="ltr"><div>While we have existing update metrics, reducing the latency in receiving signals from clients post-install/-update is the main goal here.<br></div><div>Also, having a signal before users can drop off is valuable.<br><br></div><div>Robert, having you review/feedback the implementation would be valuable to make sure the update semantics are covered correctly.<br><br></div><div>Georg<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 8, 2017 at 9:21 PM, Robert Strong <span dir="ltr"><<a href="mailto:rstrong@mozilla.com" target="_blank">rstrong@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The UPDATE_STATE_CODE_COMPLETE_<wbr>STARTUP or UPDATE_STATE_CODE_PARTIAL_<wbr>STARTUP histograms are recorded with a value of 10 on startup after a successful update. I don't know how long it is after startup that these (and other) histograms are sent though.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Robert<br><br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 8, 2017 at 12:04 PM, Ben Hearsum <span dir="ltr"><<a href="mailto:bhearsum@mozilla.com" target="_blank">bhearsum@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Post-update pings would allow us to do much more accurate throttled rollouts of Firefox updates than we do now, which Release Management has wanted for quite awhile.<br>
<div><div class="m_1609684662351450587h5"><br>
On Wed, Mar 08, 2017 at 02:08:47PM -0500, David Durst wrote:<br>
> We already have lots of telemetry around update -- is there a benefit to<br>
> having discrete pings instead?<br>
><br>
> --<br>
> David Durst [:ddurst]<br>
><br>
> On Wed, Mar 8, 2017 at 11:57 AM, Saptarshi Guha <<a href="mailto:sguha@mozilla.com" target="_blank">sguha@mozilla.com</a>> wrote:<br>
><br>
> > I wanted to chime in.<br>
> ><br>
> > 1. I am at least one of the people who want some way to capture<br>
> > first run from within UT. We measure downloads, installs and first runs<br>
> > from 3 different data sources (GA, stub installer, and GA ). When creating<br>
> > reports/analyses these data sources often give 3 varieties of the same<br>
> > number. What happens next is that we start pointing blame at data sources<br>
> > or ascribing the difference to the data source and leaving it at that. It<br>
> > would be streamlined if UT(which is in our control) could contain as much<br>
> > as possible. The analysts are very comfortable using UT and having these<br>
> > measurements in one data source would keep one thing constant: the data<br>
> > source.<br>
> ><br>
> > 2. I also advocate (strongly!) doing releases based entirely on UT data. A<br>
> > release (and even an experiment) can be released to profiles meeting some<br>
> > criteria e.g. Release, geo:US, locale: en-us memory: low-end *and*<br>
> > sampleid1 in 1, sampleid2 in 41.<br>
> > Here sampleid2 are independent versions of sample_id (e.g.<br>
> > crc32(salt(client_id)) %% 100 ). That way we can release to as small<br>
> > as 60,000 profiles. Moreover we can keep a file with this release history<br>
> > (what filters, what sampleids chosen etc) and keep it in the UT json itself.<br>
> ><br>
> > This echoes what Brendan mentioned before about releases being test<br>
> > driven. if we do the above, then we can release  to channel:Release,<br>
> > geo:US, locale: en-us memory: low-end *and* sampleid1 in 1, sampleid2 in 41<br>
> > of which 50% in control (no change) and 50% get the new release.<br>
> ><br>
> > This abstracts release management and experiments under a common<br>
> > conceptual umbrella. Moreover it will make the UT json somewhat self<br>
> > describing.<br>
> ><br>
> ><br>
> >  Saptarshi<br>
> ><br>
> ><br>
> > On Wed, Mar 8, 2017 at 8:21 AM, Alessio Placitelli <<br>
> > <a href="mailto:aplacitelli@mozilla.com" target="_blank">aplacitelli@mozilla.com</a>> wrote:<br>
> ><br>
> >> + Ben Hearsum<br>
> >><br>
> >> Thanks for the good questions, Benjamin! My answers are below.<br>
> >><br>
> >> 2017-03-08 15:35 GMT+01:00 Benjamin Smedberg <<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>>:<br>
> >><br>
> >>> Can you describe what questions these pings are meant to answer?<br>
> >>><br>
> >>><br>
> >> These pings are meant to answer, in "soft real-time", these questions:<br>
> >><br>
> >> - How quickly and how many people shift to a new version? e.g. low<br>
> >> latency answers to  “how many people are on 53”<br>
> >> - How likely is that a user that installs from a given source does more<br>
> >> page views?<br>
> >> - How does churn relate to the installation source?<br>
> >> - Given the discrepancy between download and first run numbers, where is<br>
> >> the truth?<br>
> >> - How many users are stuck on updates?<br>
> >><br>
> >><br>
> >>> For example, one of the use cases for release management is that we want<br>
> >>> to be able to roll out new versions progressively to specific numbers of<br>
> >>> people. Right now we do this by throttling the updates for a period of<br>
> >>> time. It would be faster and better to do a 100% update until we get the<br>
> >>> target number of people and then cut it off. But in order to serve that use<br>
> >>> case, I don't know whether we need the ping *after* update or the ping<br>
> >>> after the update is staged but before it is actually applied.<br>
> >>><br>
> >>><br>
> >> To address this scenario, we're considering sending the update ping<br>
> >> *before* it attempts to apply it and *after* it's applied.<br>
> >><br>
> >><br>
> >>> Similarly for the activation ping, the growth team probably cares most<br>
> >>> about new profiles, but release management might care also about people who<br>
> >>> don't "update" but "install" the new version.<br>
> >>><br>
> >>> Let's say somebody is running Firefox 56 and installs Firefox 57 with<br>
> >>> the installer (rather than updater). Would that send *either* of the<br>
> >>> install or update pings? Do we need to add a clear signal to the update<br>
> >>> ping about whether this is the result of a fresh install or an app update?<br>
> >>><br>
> >>><br>
> >> This would send the update ping when Firefox is started. Adding a clear<br>
> >> signal about whether this is the result of a fresh install or an app update<br>
> >> is a good idea, IMHO.<br>
> >><br>
> >><br>
> >>> What about if somebody is running Firefox 56 and reinstalls Firefox 56?<br>
> >>> Will that send any pings?<br>
> >>><br>
> >>><br>
> >> It shouldn't if the same profile is used.<br>
> >><br>
> >><br>
> >>> --BDS<br>
> >>><br>
> >>><br>
> >>> On Wed, Mar 8, 2017 at 9:26 AM, Alessio Placitelli <<br>
> >>> <a href="mailto:aplacitelli@mozilla.com" target="_blank">aplacitelli@mozilla.com</a>> wrote:<br>
> >>><br>
</div></div>> >>>> *tl;dr;* we're kicking off the work on two new ping types, the<br>
<span>> >>>> proposal is down below and we're gladly accepting comments.<br>
> >>>><br>
</span>> >>>> *Context*<br>
<span>> >>>><br>
> >>>> Data Platform will be supporting Firefox Growth by working on reducing<br>
> >>>> the data reporting latency, allowing client teams to make decision and<br>
> >>>> iterate quickly.<br>
> >>>><br>
> >>>> Along with the initiative of sending the "shutdown" ping when Firefox<br>
> >>>> shuts down (bug 1336360), we're considering adding the following new pings:<br>
> >>>><br>
</span><span>> >>>> *"Install" (aka "Activation") ping*<br>
</span><span>> >>>> Sent when Firefox is launched right after its installation, on a new<br>
> >>>> profile. This ping will contain:<br>
> >>>><br>
</span>> >>>>    - The client_id<br>
> >>>>    - The environment data (or a subset of the environment data).<br>
<span>> >>>><br>
> >>>> Having this clear installation signal would be useful for funnel and<br>
> >>>> churn analysis, along with giving us a clearer picture of the "download to<br>
> >>>> usage" patterns. The work for this ping is tracked in bug 1120370.<br>
> >>>><br>
> >>>> In the current state, the "Install" ping would be sent right after the<br>
> >>>> "Data Choices" infobar is displayed, which is 60s into Firefox execution.<br>
</span>> >>>> This *could *change in future releases as we will probably be dropping<br>
<span>> >>>> the infobar and opening a tab instead.<br>
> >>>><br>
> >>>><br>
</span>> >>>> *"Update" ping*Sent right after Firefox upgrades to a new version<br>
<span>> >>>> (i.e. restarts after applying the update). It will contain:<br>
> >>>><br>
</span>> >>>>    - The client_id<br>
> >>>>    - The previous installed version and channel<br>
> >>>>    - The current installed version and channel<br>
<span>> >>>><br>
> >>>> This will give us a clear signal of a version upgrade, helping to have<br>
> >>>> a quicker view on the version uptake of new Firefox releases. The work for<br>
> >>>> this ping is tracked in bug 1120372.<br>
> >>>><br>
</span><span>> >>>> There's a discussion going on about sending this ping *before *the<br>
</span>> >>>> update takes place and *after *it finishes, to quantify the problems<br>
<span class="m_1609684662351450587im m_1609684662351450587HOEnZb">> >>>> in the update process.<br>
> >>>> Alternatively, if we were able to detect failed updates when restarting<br>
> >>>> Firefox (under investigation), we could just be sending the "update" ping<br>
> >>>> once after an update attempt, regardless of its success, together with the<br>
> >>>> failure reason.<br>
> >>>><br>
</span><span class="m_1609684662351450587im m_1609684662351450587HOEnZb">> >>>> *Additional context*<br>
> >>>> <a href="https://docs.google.com/document/d/1NEOHfT4hBsmOmoK5M_wbsF7v" rel="noreferrer" target="_blank">https://docs.google.com/docume<wbr>nt/d/1NEOHfT4hBsmOmoK5M_wbsF7v</a><br>
> >>>> -NihTtCybHe-sxs9Hgw/edit?ts=58<wbr>b947d8#heading=h.byypvh46s2wo<br>
> >>>><br>
</span><div class="m_1609684662351450587HOEnZb"><div class="m_1609684662351450587h5">> >>>> ______________________________<wbr>_________________<br>
> >>>> fhr-dev mailing list<br>
> >>>> <a href="mailto:fhr-dev@mozilla.org" target="_blank">fhr-dev@mozilla.org</a><br>
> >>>> <a href="https://mail.mozilla.org/listinfo/fhr-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/fhr-dev</a><br>
> >>>><br>
> >>>><br>
> >>><br>
> >><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > fhr-dev mailing list<br>
> > <a href="mailto:fhr-dev@mozilla.org" target="_blank">fhr-dev@mozilla.org</a><br>
> > <a href="https://mail.mozilla.org/listinfo/fhr-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/fhr-dev</a><br>
> ><br>
> ><br>
</div></div><br>______________________________<wbr>_________________<br>
fhr-dev mailing list<br>
<a href="mailto:fhr-dev@mozilla.org" target="_blank">fhr-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/fhr-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/fhr-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
fhr-dev mailing list<br>
<a href="mailto:fhr-dev@mozilla.org">fhr-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/fhr-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/fhr-dev</a><br>
<br></blockquote></div><br></div>