I think C has been covered by the WebApk.Install.GooglePlayInstallResult. It has the succeeded number, and the sum of other cases (except the timeout) will be the failed number. I think we could add A (install start) in that histogram too, then we can have a clear idea of 1) how many times the install starts 2) succeeded cases 3) failed cases and why they failed.

For B, do you want a histogram for the duration of both succeeded and failed cases? The WebApk.Install.InstallDuration records the duration for succeeded cases only. To avoid records data in duplicated buckets, maybe we can have a similar WebApk.Install.InstallDurationForFailureCases histogram, rather than one histogram includes both succeeded and failed case.

One thing to mention is the source of the data of the two histograms that I mentioned. The "WebApk.Install.GooglePlayInstallResult" records play install data only, while the "WebApk.Install.InstallDuration" records data from both play install and "unknown source" paths. I can modify the code to make the duration for play install only, if play install is the only interesting one. We begin to remove "unknown sources" code, it will be less confusing in the future since these histograms will contain google play install data only.

That makes a lot of sense. Let's just add a bucket to WebApk.Install.GooglePlayInstallResult. One logistical note: we will have to slice by milestone during analysis since the histogram will mix across different Chrome versions.

I'd be happy to see a histogram for how long it took to fail, but the thing that had me more worried were cases where we don't record something as a success or a failure because Chrome stops running before an install times out. You could imagine, for example, a user starting an install and leaving Chrome if they were frustrated with how long it took. But I think adding the bucket above will at least let us quantify the number.

I think it probably makes sense to limit InstallDuration to installs through Play, but as you've said I don't think it'll be a big issue numerically. (Just people on old versions of Chrome with the flag flipped, I think?)

 

I guess I understand what you want to record for B now, but I'm not sure who to record this histogram. Perhaps we set up several time point for mile stores like: A) chrome receive token from WAM server, B) Chrome call Install API, C) Chrome get broadcast from Play, etc. For an install, when it passes any time point, we check the time elapsed, and if it falls in a new time range that it hasn't been, then add it to the range?

After a second thought, I don't think we need to worry to much about the missing cases. The most time consuming part is after Chrome calls Play's install API. After that, everything is handled by Play, and Chrome just wait for the broadcast. If user is impatient and closes Chrome, I guess they just swap Chrome from recents, right? If my assumption of the user action is correct, the Chrome process is still running (only the activity/renderers are gone), and the WebAPK install receiver is still alive. As long as the API is called, I think 99% we will receive the Play's broadcast. That means, if we records the histogram to when the broadcast is received, we will records almost 99% results. This should be an easy change.

Since Yaron's CL to remove unknown sources is in CQ, I will hold off the changes to InstallDuration. After removing that code path, this histogram will just record play install data:) Yes, except people with old Chrome, but would be very limited number.

The CL landed. We only use Play to install now.

Anything still to do here?

Yes, 1) we need to add "InstallStart" in "WebApk.Install.GooglePlayInstallResult". 2) Record this metrics when the broadcast is received by Chrome, not in the calling of callback of WebApkInstaller. Thus we will have very less chance to miss any record of an Play install.

That plan SGTM!

The total number (banner+menu) in the "WebApk.Install.InstallSource" is actually the "InstallStart" we want. The combination of the "InstallSource" and  the "GooglePlayInstallResult" can give us a good understanding of the data that we missed to record.

I also found a bug in "GooglePlayInstallResult" which also records data from WebAPK update cases. A CL (https://chrome-internal-review.googlesource.com/c/352289/) is created to fix the bug.

We could see what the data shows before making the changes of step 2) in comment#6.