RFC: New "install" and "update" pings

Benjamin Smedberg benjamin at smedbergs.us
Wed Mar 8 14:35:38 UTC 2017


Can you describe what questions these pings are meant to answer?

For example, one of the use cases for release management is that we want to
be able to roll out new versions progressively to specific numbers of
people. Right now we do this by throttling the updates for a period of
time. It would be faster and better to do a 100% update until we get the
target number of people and then cut it off. But in order to serve that use
case, I don't know whether we need the ping *after* update or the ping
after the update is staged but before it is actually applied.

Similarly for the activation ping, the growth team probably cares most
about new profiles, but release management might care also about people who
don't "update" but "install" the new version.

Let's say somebody is running Firefox 56 and installs Firefox 57 with the
installer (rather than updater). Would that send *either* of the install or
update pings? Do we need to add a clear signal to the update ping about
whether this is the result of a fresh install or an app update?

What about if somebody is running Firefox 56 and reinstalls Firefox 56?
Will that send any pings?

--BDS


On Wed, Mar 8, 2017 at 9:26 AM, Alessio Placitelli <aplacitelli at mozilla.com>
wrote:

> *tl;dr;* we're kicking off the work on two new ping types, the proposal
> is down below and we're gladly accepting comments.
>
> *Context*
>
> Data Platform will be supporting Firefox Growth by working on reducing the
> data reporting latency, allowing client teams to make decision and iterate
> quickly.
>
> Along with the initiative of sending the "shutdown" ping when Firefox
> shuts down (bug 1336360), we're considering adding the following new pings:
>
> *"Install" (aka "Activation") ping*
> Sent when Firefox is launched right after its installation, on a new
> profile. This ping will contain:
>
>    - The client_id
>    - The environment data (or a subset of the environment data).
>
> Having this clear installation signal would be useful for funnel and churn
> analysis, along with giving us a clearer picture of the "download to usage"
> patterns. The work for this ping is tracked in bug 1120370.
>
> In the current state, the "Install" ping would be sent right after the
> "Data Choices" infobar is displayed, which is 60s into Firefox execution.
> This *could *change in future releases as we will probably be dropping
> the infobar and opening a tab instead.
>
>
> *"Update" ping*Sent right after Firefox upgrades to a new version (i.e.
> restarts after applying the update). It will contain:
>
>    - The client_id
>    - The previous installed version and channel
>    - The current installed version and channel
>
> This will give us a clear signal of a version upgrade, helping to have a
> quicker view on the version uptake of new Firefox releases. The work for
> this ping is tracked in bug 1120372.
>
> There's a discussion going on about sending this ping *before *the update
> takes place and *after *it finishes, to quantify the problems in the
> update process.
> Alternatively, if we were able to detect failed updates when restarting
> Firefox (under investigation), we could just be sending the "update" ping
> once after an update attempt, regardless of its success, together with the
> failure reason.
>
> *Additional context*
> https://docs.google.com/document/d/1NEOHfT4hBsmOmoK5M_
> wbsF7v-NihTtCybHe-sxs9Hgw/edit?ts=58b947d8#heading=h.byypvh46s2wo
>
> _______________________________________________
> fhr-dev mailing list
> fhr-dev at mozilla.org
> https://mail.mozilla.org/listinfo/fhr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/fhr-dev/attachments/20170308/3ff04349/attachment.html>


More information about the fhr-dev mailing list