Summarize telemetry data by including "acceptable" cutoffs for key metrics.

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
7 years ago
4 years ago

People

(Reporter: cww, Unassigned)

Tracking

unspecified
Backlogged - BZ
x86
Mac OS X

Details

(Whiteboard: [Telemetry] -- needs PM project priority)

(Reporter)

Description

7 years ago
In telemetry, for each measure (or some key measures) we should have a cutoff and then we should report what % of submissions are greater than cutoff. It's a much better way of counting than using mean or median or even percentiles and can boil metrics down to a single easy-to-track number.

Say the cutoff for GC_MS is 300. Just tell me what percent of hits are > 300 and let me slice and dice that on a graph to show how that changes over time or between releases or between OSes.

Updated

7 years ago
Group: metrics-private
(Reporter)

Comment 1

7 years ago
To clarify, the metrics team isn't responsible for coming up with cutoffs, that's the job of product/engineering/whoever is requesting the measure.  This probably only applies to a number of key summary metrics (like GC_MS, but not GC_SWEEP for example).
Whiteboard: [Telemetry]

Comment 2

6 years ago
Marking: in group of > 33 asks for Telemetry that need PM priority before triage/scheduling.
Status: NEW → ASSIGNED
Whiteboard: [Telemetry] → Telemetry -- needs PM project priority

Comment 3

6 years ago
Triaged.
Target Milestone: Unreviewed → Backlogged - BZ
Whiteboard: Telemetry -- needs PM project priority → [Telemetry] -- needs PM project priority
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.