New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 596959 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Email to this user bounced
Closed: Aug 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Need metrics to understand why precache coverage is so low.

Project Member Reported by bengr@chromium.org, Mar 22 2016

Issue description

Precache.Fetch.FailureReasons is supposed to capture all of the reasons that precaching doesn't happen for the population that has access to it. These include Deprecated: UPDATE_PRECACHING_ENABLED_NEVER_CALLED, SYNC_NOT_INITIALIZED, PRERENDER_PRIVACY_PREFERENCE_NOT_ENABLED NATIVE_SHOULD_RUN_IS_FALSE, NO_POWER, NO_WIFI, Deprecated: SCREEN_ON, NOT_ENOUGH_TIME_SINCE_LAST_PRECACHE, and CURRENTLY_PRECACHING.  

In addition, we should track whether the native library failed to initialize when precaching started, and when the native library was not initialized when UMA were written.

 

Comment 1 by bengr@chromium.org, Mar 22 2016

In addition, we should confirm that the failure reason metrics continue to report correct values after https://bugs.chromium.org/p/chromium/issues/detail?id=542862 is fixed. CL: https://codereview.chromium.org/1751183002/
Status: Started (was: Assigned)
Perhaps we are misunderstanding the first UMA above. If I use a different UMA and then filter by Precache, then the number is in agreement with the other Precache metrics. For example, using  Net.DailyContentLength gives 33,376 users with Precache enabled.

https://uma.googleplex.com/p/chrome/histograms/?endDate=03-23-2016&dayCount=7&histograms=Net.DailyContentLength%2CNet.ErrorCodesForMainFrame3&fixupData=true&uniqueUsers=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C2%2Cfinch%2Cstgr_filter%2C2655433701%7C1061820383%7C1423453153%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial
Precache.Fetch.FailureReasons and Net.ErrorCodesForMainFrame3 get logged at different locations and with very different frequencies, so the number of users reporting these UMAs are not expected to match up.

There are multiple reasons why a UMA being recorded less frequently will see a smaller number of users, such as loss of connectivity, device restart, process being killed before UMA is sent across the wire, etc.

Comment 5 by bengr@chromium.org, Mar 29 2016

This appears to be a reporting issue. The number of users who save data due to precaching is around 50.5% of all users in the experiment (25,473). See:

https://uma.googleplex.com/p/chrome/histograms/?endDate=03-23-2016&dayCount=7&histograms=Precache.Saved&fixupData=true&uniqueUsers=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C2%2Cfinch%2Cstgr_filter%2C2655433701%7C1061820383%7C1423453153%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

I believe the reporting issue is that UMA is not reliably reported each time precache runs, because the process often will complete and shutdown before reporting can take place. See https://bugs.chromium.org/p/chromium/issues/detail?id=583440

I guess this issue is obsolete now.
We have more understanding of these UMA and/or fixed a bunch of issues around it.

Comment 7 by bengr@chromium.org, Aug 18 2016

Status: WontFix (was: Started)

Sign in to add a comment