Is this still needed?

Also see Issue 900694 which seems to be capturing the same goals?

I think it would be useful to understand how much additional coverage we would get from this on a per-user basis. 

However, this cannot really be done accurately unless we have a Bloom filter of what hosts we even analyzed which I don't really want to support just for this calculation that is only going to be used temporarily to guide the API client design. (But that's just a caveat that we need to add to the analysis rather than this stopping us from adding the UMA. I think it gives us an upper bound of the potential.)

For this metric to be meaningful, we'd need to send down a whitelist of slow hosts with the component; otherwise, there'd be no way of knowing what a top host not being in the component hints means.

The other potential benefit of the whitelist would be to allow us to avoid making unnecessary OnePlatform requests on hosts that aren't slow and will never be available on the server.

I'll go ahead and add a bug for the whitelist, mark this as blocked by it, and if we decide not to do the whitelist, then we can close this one out.

I'm not sure what's the goal here? Is it to motivate the implementation of 1P API? If so, is the data from  Issue 900694  sufficient?

Or, is the goal to motivate fetching hints for top hosts at startup (assuming 1P API has already been implemented)?

Posted the last comment before I saw Sophie's comment.

I think the biggest use of the bloom filter would be to avoid OnePlatform requests when the server hasn't analyzed the host.

I'll keep this on my radar if Sophie thinks it's useful without the filter.

> I think the biggest use of the bloom filter would be to avoid OnePlatform requests when the server hasn't analyzed the host.

That seems like a not-so-critical optimization? If so, let's change this to P3, and remove milestones.

re: comment 6: motivate the implementation of 1P API. I think showing that there is a long tail of slow sites is useful. 

re: comment 7 - I think this metric is still useful without the filter. 

re: comment 9 - I think these are separate concerns. I'd like to leave this as P2 and analyze it as an upper bound.

Re-whitelist from comment 7. Agree with comment 9 that it is non-critical and I probably would not support it on the server side since I think requesting the hosts allows us to understand what we're not analyzing and allows us to fill in gaps. 

Refreshed during triage