Closed Bug 733468 Opened 12 years ago Closed 9 years ago

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

Categories

(Mozilla Metrics :: Frontend Reports, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Backlogged - BZ

People

(Reporter: cww, Unassigned)

Details

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

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.
Group: metrics-private
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]
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
Triaged.
Target Milestone: Unreviewed → Backlogged - BZ
Whiteboard: Telemetry -- needs PM project priority → [Telemetry] -- needs PM project priority
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.