Closed Bug 1757353 Opened 2 years ago Closed 2 years ago

Add telemetry for links in about:preferences

Categories

(Firefox :: Settings UI, task, P3)

task

Tracking

()

RESOLVED FIXED
100 Branch
Tracking Status
firefox100 --- fixed

People

(Reporter: daisuke, Assigned: daisuke)

References

Details

Attachments

(1 file)

This is a follow-up of bug 1756917.

:Gijs said in https://phabricator.services.mozilla.com/D139576#inline-768713, currently, as it seems that we don't take any telemetries for links on about:preferences page, we add them.

Severity: -- → S3
Priority: -- → P3

So I'm curious how we feel about a change like this. We already get scalar telemetry for all the checkbox/button clicks in about:preferences. We've now had a few features (more from mozilla, firefox suggest) where product have asked for telemetry for links as well. Should we just broaden the telemetry to include the link clicks?

Curious about a product perspective as well - Venetia?

Flags: needinfo?(vtay)
Flags: needinfo?(mconley)
Flags: needinfo?(jaws)

Considering we already get telemetry from all the checkbox and button clicks, I don't think there is a material difference between gathering telemetry on the link clicks. I am open to expanding the default collection and thus simplifying the code by not having to litter the wants-telemetry class everywhere.

Flags: needinfo?(jaws)

My only concern is that this presumably makes it easier to collect more information while maybe forgetting to request review from our Data Stewards. Like, with this, presumably I could add a text-link to about:preferences, and we'd automagically start collecting a scalar for it, and I might not even realize it (and therefore not realize that a data-review is probably required). I think that's my only concern.

Going to transfer needinfo to chutten to get a Data Stewards take.

Flags: needinfo?(mconley) → needinfo?(chutten)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)

My only concern is that this presumably makes it easier to collect more information while maybe forgetting to request review from our Data Stewards. Like, with this, presumably I could add a text-link to about:preferences, and we'd automagically start collecting a scalar for it, and I might not even realize it (and therefore not realize that a data-review is probably required). I think that's my only concern.

Going to transfer needinfo to chutten to get a Data Stewards take.

Yep - it's worth noting that this is already what happens for checkboxes/buttons and a few other elements. If it has an ID it ends up in the keyed scalar. To help make :chutten's life easier, the data review for that stuff happened in bug 1620358.

Data Steward hat: on. Angle: jaunty.

The collection of data of the form "Piece of the UI with id X was interacted with" is Category 2 collection suitable for default-on collection in all channels. New and expanded data collections in Mozilla projects are subject to Data Collection Review. (by process)

Put these two things together and it sure looks as though adding a new checkbox to about:preferences should require a Data Collection Review, doesn't it.

However, this is where the "Collection" part of "Data Collection" rears its multiple-meaning head. Yes, we're reviewing the collection (verb meaning gathering) of data, but we're also reviewing the data collection (noun meaning group). If you want to collect data about the counts of types of network errors Firefox experiences, then should the introduction of a new kind of error trigger Review?

When it comes to that I defer to the Data Collection Review as written. If it says "Counts TLS Errors" and we start detecting and collecting data about TLS handshake errors, then that's covered. No additional review needed (though Stewards will be happy to have a look and even add a review if you'd prefer it). But if we decide to start collecting QUIC errors as well as TLS, well... that's not covered in the original review.

(A guideline you can follow is that if you're adding a new metric definition, you probably need a new review. If you're adding a new label or other parameter to an existing definition, you might not: check the original review (linked to in the definition)).)

So if a Data Collection Review Request comes up here about the collection of interactions with links in the about:preferences UI, then I'll have some questions: Do these links change in ways that users can control (ie, do we hide data collection in this interaction. Do some links only appear if certain settings are enabled? Do some contain Fx Accounts ids or something?)? Do we identify these links in the data collection by their URL or by some baked-into-the-binary id like other UI elements? (and maybe others I'll think of later). But on the face of things, that'll probably get data-review+ and subsequent additions of links that :mconley (or anyone) might add would be covered under this initial review.

(( This, by the by, is one of the reasons it is important to have our data collection reviews publicly-available and easy to find ))

Does this address your concerns, :mconley?

Flags: needinfo?(chutten) → needinfo?(mconley)

I think so, yes. It doesn't look like this changes the definition of the probes that these named scalars fall into, so that coupled with what chutten wrote assuages my concerns.

Flags: needinfo?(mconley)

As other PMs such as Ray & Romain touch about:preferences, I've also consulted them.

AFAICT most links are "Learn More" links that point to SUMO pages. In the past, Romain has worked around this by checking in traffic on SUMO that comes from these in-product links and never hit limitations in his ability to understand patterns.

Overall, having clicks on links reported in a similar fashion to other UI telemetry could be valuable as long as we remain consistent with the current approach where keyed scalars are used (i.e a link would become a new key on existing scalars) - this way we can benchmark use of preferences entries in ways that are comparable.

Flags: needinfo?(vtay)
Pushed by dakatsuka.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/92fdc79bc3a3
Add browser usage telemetry for links in about:preferences. r=Gijs,preferences-reviewers
Regressions: 1759618
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch
Regressions: 1782991
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: