Closed Bug 1525977 Opened 5 years ago Closed 5 years ago

Data review for Firefox Monitor as an in-tree system add-on


(Firefox :: Firefox Monitor, enhancement)

67 Branch
Not set



Firefox 68
Tracking Status
firefox67 + fixed
firefox68 --- fixed


(Reporter: nhnt11, Assigned: nhnt11)




(1 file)

Once the add-on lands in tree (with Telemetry disabled) we should get it data-reviewed again.

  1. What questions will you answer with this data?
  • How often does user encounter the feature?
  • How does user respond to the feature?
  1. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?
  • Provide information essential for advancing a business objective such as supporting OKRs.
  • Determine whether a product or platform change has an effect on user or browser behavior.
  1. What alternative methods did you consider to answer these questions? Why were they not sufficient?
  • There are no alternatives other than the event telemetry to learn how user interacts with this UI.
  1. Can current instrumentation answer these questions?
  • No.
  1. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the Mozilla wiki.
  • Technical and interaction data

Measurement Description: Events to measure user engagement with the doorhanger UI
Data Collection Category: Interaction data
Tracking Bug #: Bug 1485651

  1. How long will this data be collected?
  • I want this data to be collected for 6 months initially (potentially renewable).
  1. What populations will you measure?
  • Which release channels?

    • Release 66 onwards
  • Which countries?

    • N/A
  • Which locales?

    • all
  • Any other filters?

    • No.
  1. If this data collection is default on, what is the opt-out mechanism for users?
  • User can opt out under about:preferences#privacy.
  1. Please provide a general description of how you will analyze this data.
  • Follow our general practice to analyze event telemetry.
  1. Where do you intend to share the results of your analysis?
  • To Firefox team. Results will likely be shared on a mailing list and/or Bugzilla (bug 1485651)

Chris, this is a follow-up to bug 1485650, where you did the data-review for the initial rollout of Firefox Monitor.

6 months have passed since then and it's time to renew the data-review approval. The add-on has now landed in mozilla-central (in 67) with telemetry disabled for now until we get data-review+.

I pasted in the data-review doc in the comment above this one. It's the same as before except the target release has been updated to 66 onwards (we're still shipping the add-on via Balrog for 66 but it'll be in-tree for 67).

Please let me know if there's anything else you need to know for the review.

Flags: needinfo?(chutten)

Thanks for reaching out! For future data collection reviews please attach the review request as a file and set the data-review flag to ?.


Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

In future the collections may be hosted in the m-c Scalars.yaml in which case it will appear in the usual Telemetry places (Probe Dictionary, elsewhere)

Is there a control mechanism that allows the user to turn the data collection on and off?

Standard Telemetry mechanisms apply.

If the request is for permanent data collection, is there someone who will monitor the data over time?**

N/A, is not permanent.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction.

Is the data collection request for default-on or default-off?


Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No, only counts.

Is the data collection covered by the existing Firefox privacy notice? 


Does there need to be a check-in in the future to determine whether to renew the data? 

Yes. :nhnt11, you will be responsible to determine whether to renew or remove these probes before they expire.

Result: datareview+

Flags: needinfo?(chutten)

Thank you! I'm going to use this bug to land a patch to enable Telemetry.

Assignee: nobody → nhnt11
Pushed by
Enable Firefox Monitor telemetry. r=johannh
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

Is this something you wish to turn on in 67? Please request uplift to beta if yes.

Flags: needinfo?(nhnt11)

Yes, it is. I'll be requesting uplift next week, along with bug 1531838. It's unfortunate that these didn't make it into 67 without an uplift, but the test failure in the other bug should be solved now. Thanks for the heads up.

Flags: needinfo?(nhnt11)

Tracking both this bug and bug 1531838 to keep it on my radar as there are potential uplifts.

Comment on attachment 9051984 [details]
Bug 1525977 - Enable Firefox Monitor telemetry. r=johannh

Beta/Release Uplift Approval Request

  • Feature/Bug causing the regression: Bug 1525519
  • User impact if declined: No telemetry data on user interaction with Firefox Monitor UI - impacts our ability to determine the effectiveness of the feature.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): It just enables telemetry recording on release.
  • String changes made/needed: none
Attachment #9051984 - Flags: approval-mozilla-beta?

Comment on attachment 9051984 [details]
Bug 1525977 - Enable Firefox Monitor telemetry. r=johannh

Uplift approved for 67 beta 12, thanks.

Attachment #9051984 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify-
See Also: → 1561012
You need to log in before you can comment on or make changes to this bug.