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?
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.
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.
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
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.