1600623 - Review and cleanup the printing telemetry

Status: RESOLVED FIXED

(Toolkit :: Printing, task, P1)

Description

[Jonathan Watt [:jwatt]]

Filing this to follow-up on the comments here:

https://phabricator.services.mozilla.com/D51992?id=187604#1586178

The "kind": "count" lines there are deprecated, which is why the touched values appear in a whitelist in histogram-allowlists.json.

We should rewrite the existing telemetry probes to be scalars (in Scalars.yaml) and probably do a wider review of whether these probes even meet our needs as well as they could. (Maybe this should all just happen in bug 1569247, but filing separately for now and we can decide that later.)

In conversations with chutten he said changing to scalars would be "mildly disruptive". Chris, can you provide more details on that for the benefit of Martin so he can assess whether that would be a problem for him or not?

Comment 1

[Chris H-C :chutten]

The benefits of Scalars are felt in a few places. On the analysis side, instead of encoding the single number of a "count histogram" as a sum and value in a bucket, a Scalar sends just the number. In a lot of places our now-fairly-smart tooling takes care of this for you, though, so the benefits are now limited by our Data Platform engineering : /

On the client-side it is helpful during testing to be able to read the number directly. And the yaml file format is easier to organize (it has categories!) and supports things like multi-line descriptions.

It's one of a few different types of ways we can encode data to help answer the questions you need to answer about your features. I encourage that you undertake a review of what those questions are so we can better understand what we need to collect and how. I'm happy to advise on how I'd set up data collections to answer them effectively.

Comment 2

[:Gijs (out for now; he/him)]

Jonathan, are you planning to work on this? If so, can you mark this P1; otherwise, can you mark P3? Thanks!

Comment 3

[Jonathan Watt [:jwatt]]

Attachment: Bug 1600623. Add telemetry probes for print dialog/preview opens/cancels and print target type. r=bobowen,mbalfanz

Comment 4

[Jonathan Watt [:jwatt]]

Attachment: Data review form

Comment 5

[Jonathan Watt [:jwatt]]

Attachment: Data review form

Update names to reflect changes to patch.

Comment 6

[Jonathan Watt [:jwatt]]

Attachment: Data review form

Actually, this is category 2 data.

Comment 7

[Chris H-C :chutten]

Comment on attachment 9153869 [details]
Data review form

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. This collection is Telemetry so is documented in its definitions file [Scalars.yaml](https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Scalars.yaml) and the [Probe Dictionary](https://telemetry.mozilla.org/probe-dictionary/).

    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, Jonathan Watt 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 there need to be a check-in in the future to determine whether to renew the data?

No. This collection is permanent.

---
Result: datareview+

Comment 8

[Jonathan Watt [:jwatt]]

Comment on attachment 9153797 [details]
Bug 1600623. Add telemetry probes for print dialog/preview opens/cancels and print target type. r=bobowen,mbalfanz

Beta/Release Uplift Approval Request

• User impact if declined: This telemetry is important for both the Layout team (fragmentation work) and the Firefox frontend team (UX redesign). We would like to get it into Firefox 78 since this is an ESR release, and many of our corporate users who print more frequently, use ESR. It will help inform our decisions to be most impactful for users, and to measure success criteria.

Preemptively requesting uplift approval, although it's not actually made it into a Nightly release yet.

• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes (well, it has landed, so that's in process)
• 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): The patch adds telemetry and should not contain behavior changes. Really at worst the telemetry could in principal have been implemented incorrectly and we'll end up with useless data.
• String changes made/needed: none

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fc1b79b6057f
Add telemetry probes for print dialog/preview opens/cancels and print target type. r=bobowen,mbalfanz

Comment 10

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/fc1b79b6057f

Comment 11

[Julien Cristau [:jcristau]]

Comment on attachment 9153797 [details]
Bug 1600623. Add telemetry probes for print dialog/preview opens/cancels and print target type. r=bobowen,mbalfanz

extra telemetry for printing, approved for 78.0b3

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7635dd36137c