Event Telemetry: Difference between revisions
(→Client Testing: MOAR links) |
(→Communication: pick an irc channel) |
||
| Line 52: | Line 52: | ||
= Communication = | = Communication = | ||
* Conversation about Event telemetry on fhr-dev: https://mail.mozilla.org/listinfo/fhr-dev | * Conversation about Event telemetry on fhr-dev: https://mail.mozilla.org/listinfo/fhr-dev | ||
* IRC: #telemetry | * IRC: #telemetry | ||
* Slack: #fx-metrics | * Slack: #fx-metrics | ||
* [https://docs.google.com/document/d/1P0BmMRLSglX9G53-j5udU5CnrwDaqcHKP5fFjU5hEwo/edit Weekly Meeting notes] | * [https://docs.google.com/document/d/1P0BmMRLSglX9G53-j5udU5CnrwDaqcHKP5fFjU5hEwo/edit Weekly Meeting notes] | ||
Revision as of 22:25, 29 September 2016
The Telemetry wiki page has more information about using Telemetry -- this page describes the Event Telemetry project.
Overview
There is a common need across teams (fx-team, mobile, test-pilot, heartbeat, …) to have a mechanism for recording, storing, sending & analysing application usage in an event-oriented format. The Data Platform team wants to support this with a common API and mechanisms for dealing with the collected data, without owning the individual measurements. The solution here is to provide common client code, a standard data format, so we can come up with common processes and tooling for data pipeline & analysis work. Historically we already send a form of UITelemetry data, but the current format is too complicated to work with and to maintain.
Dates
- ...: Event data explorable in re:dash (from pre-release channels)
- Fx52 (~2017-03-07): Event data collection implemented in Firefox Telemetry
Goals for Event Telemetry
- Enable exploratory usage behavior analysis
- Enable event data collection from Firefox and addons
Documentation
Analysis and Reporting
- Raw data using a spark cluster (ATMO): https://analysis.telemetry.mozilla.org/
- re:dash event data tables (STMO): https://sql.telemetry.mozilla.org/
Project
Deliverables
- Establish a common event data format and tooling.
- Record event data with at least (object, method, timestamp) data.
- Enable categorizing of events, so we can serve different pings with the same API and data format.
- Allow distinguishing between opt-in and opt-out event recording.
- Allow easy recording & submission of events in batches.
- Events submitted with the main ping should have occurred in that pings subsession.
- Flat data format, not nested.
- Enforce client-side limits on event data to avoid spamming.
- Shipping new event recording without riding the trains.
- Validation of the data based on schemas.
- Enforcement of data review, quality control, documentation.
Client work
Client Testing
Event Implementation Plan
Communication
- Conversation about Event telemetry on fhr-dev: https://mail.mozilla.org/listinfo/fhr-dev
- IRC: #telemetry
- Slack: #fx-metrics
- Weekly Meeting notes
- EPM reports
Resources / Notes
People and Roles
- Georg Fritzsche (Data Platform, lead)
- Alessio Placitelli, :Dexter (Data Platform)
- Mark Reid (Data Platform)
- Roberto Vitillo (Data Platform)
- Sunah Suh (Data Platform)
- Rebecca Weiss (PM)
- Ilana Segall (Analysis)
- John Dorlus (Quality Engineering)
- Thomas Huelbert (project management)