This document will teach you how to use Firefox data to answer questions about our users. The source for this documentation can be found in this repo.
This documentation is divided into four main sections:
This section provides a quick introduction to analyzing telemetry data. After reading these articles, you will be able to confidently perform analysis over telemetry data.
Describes all available data we have on our users. For each dataset, we include a description of the dataset's purpose, what data is included, how the data is collected, and how you can change or augment the dataset. You do not need to read this section end-to-end.
Describes the tools we maintain to access and analyze user data. For each tool we include a description of the purpose, relative strengths and weaknesses, and what data you can access from the tool.
This section contains tutorials presented in a simple problem/solution format.
We're writing documentation as fast as we can, but there's always going to be confusing or missing documentation. If you can't find what you need, please file a bug.
If you have a problem with data tools, datasets, or other pieces of infrastructure, please help us out by reporting it.
Most of our work is tracked in Bugzilla in the Data Platform and Tools product.
Bugs should be filed in the closest-matching component in the Data Platform and Tools product, but if there is no component for the item in question, please file an issue in the General component.
Components are triaged at least weekly by the component owner(s). For issues needing
urgent attention, it is recommended that you use the
needinfo flag to attract attention
from a specific person. If an issue doesn't receive the appropriate attention within a
week, you can send email to the
fx-data-dev mailing list or reach out on IRC
When a bug is triaged, it will be assigned a priority and points. Priorities have the following meanings:
- P1: in active development in the current sprint
- P2: planned to be worked on in the current quarter
- P3: planned to be worked on next quarter
- P4 and beyond: nice to have, we would accept a patch, but not actively being worked on.
Points reflect the amount of effort required for a bug and are assigned as follows:
- 1 point: one day or less of effort
- 2 points: two days of effort
- 3 points: three days to a week of effort
- 5 points or more: SO MUCH EFFORT, major project.
There are bugzilla components for several of core datasets described in this documentation, so if possible, please use a specific component.
If there is a problem with a dataset that does not have its own component, please file an issue in the Datasets: General component.
Operational bugs, such as services being unavailable, should be filed either in the component for the service itself or in the Operations component.
When in doubt, please file issues in the General component.