Drive-by before I get to the Data Review Request:

This is an very-frequently-sent event. As we can see from the Measurement Dashboard over 1.7B pages have been loaded over the course of Firefox Beta 106. Release is a couple orders of magnitude higher.

Has cost/benefit been weighed for this data collection? (Prior art: bug 1774048)

Comment on attachment 9302570 [details]
data-review-1799727.md

PRELIMINARY NOTES:
Since this data collection is (in part) Glean and in Firefox Desktop, you can use mach data-review to help fill in the data collection review request.

DATA COLLECTION REVIEW RESPONSE:

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

Yes.

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

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

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

Yes, Denis Palmeiro is responsible.

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?

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

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

Yes.

Does the data collection use a third-party collection tool?

No.

Result: datareview+

(In reply to Chris H-C :chutten from comment #3)

Drive-by before I get to the Data Review Request:

This is an very-frequently-sent event. As we can see from the Measurement Dashboard over 1.7B pages have been loaded over the course of Firefox Beta 106. Release is a couple orders of magnitude higher.

Has cost/benefit been weighed for this data collection? (Prior art: bug 1774048)

We still feel the benefit is high for us, but these new keys should give us better insight into more actionable data. That being said, I think sampling this data down to 1% or even deleting anything older than 6months should not be a problem to reduce the cost. Is there a glean solution for this, or is it better I do some kind of internal sampling with a counter?

Thanks!

Funny you should ask. Travis is presently working on our intended sampling solution in bug 1798919. The way it'll look is you ship metrics turned off (with disabled: true) and then these Server Knobs will allow enabling the data collection only for configurable portions of configurable populations for configurable durations.

This'll take a while to hit primetime, though, so I'm afraid there's nothing here for today.

Deleting things on a reduced retention period might require sending this event only in its own custom ping (as retention policies are set per table, and pings get their own tables).

One thing I would caution while you consider client-side sampling is to involve Data Science in its construction. Different questions are answerable if you sample "send 1 of every 100 pageloads per profile" vs "every 100 profiles send their pageloads"

Backed out for causing mochitest failures in dom/base/test/browser_page_load_event_telemetry.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/71933e707ffa2874d2e63ec7c27260692e39cba8

Push with failures

Failure log

INFO - Buffered messages finished
[task 2022-12-12T22:59:22.087Z] 22:59:22     INFO - TEST-UNEXPECTED-FAIL | dom/base/test/browser_page_load_event_telemetry.js | false == true - JS frame :: chrome://mochitests/content/browser/dom/base/test/browser_page_load_event_telemetry.js :: <TOP_LEVEL> :: line 32
[task 2022-12-12T22:59:22.087Z] 22:59:22     INFO - Stack trace:

https://hg.mozilla.org/mozilla-central/rev/5c221dfabdf5
https://hg.mozilla.org/mozilla-central/rev/cb93209595ee
https://hg.mozilla.org/mozilla-central/rev/ddf35887e212