1254717 - PLACES_BOOKMARKS_COUNT histogram reports inconsistently

Status: RESOLVED WORKSFORME

(Cloud Services :: Metrics: Product Metrics, defect)

Description

[Ilana]

As described in https://mail.mozilla.org/pipermail/fhr-dev/2015-November/000704.html, the behavior of histograms/PLACES_BOOKMARKS_COUNT is hard to understand - it is only logged for a portion of the time amongst those who have opted in to extended telemetry.

Additionally, the dashboard at 

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-02-05&keys=__none__!__none__!__none__&max_channel_version=release%252F44&measure=PLACES_BOOKMARKS_COUNT&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-01-23&table=0&trim=1&use_submission_date=0

does not reflect a useful metrics (we know the percentage of users who have between 0 and 100 bookmarks which essentially tells us nothing). Is there a reason this shouldn't be a simple count?

Comment 1

[Georg Fritzsche [:gfritzsche]]

I think this histogram has a different background than your requirements (informing for technical decisions for the places database), it seems fine for what it is trying to do.

As you have different needs, i would suggest filing a bug with the requirements for that measurement.
There we could consider if that also happens to make PLACES_BOOKMARKS_COUNT redundant or not.

Comment 2

[Katie Parlante]

Agree with Georg, lets file a bug (or edit this bug) to spec out what we want for a bookmarks measurement that meets product requirements.

Comment 3

[Katie Parlante]

Link to thread about PLACES_BOOKMARKS_COUNT on fhr-dev, which was designed as a performance measurement: https://mail.mozilla.org/pipermail/fhr-dev/2016-March/000863.html

Comment 4

[Katie Parlante]

We believe the PLACES_BOOKMARKS_COUNT is working properly. The product metrics ask will be handled with the larger set of Q2 asks. Closing this bug.