Create separate telemetry probes for printing with the new print preview UI enabled
Categories
(Core :: Printing: Setup, task, P1)
Tracking
()
People
(Reporter: svoisen, Assigned: jwatt)
References
Details
(Whiteboard: [print2020_v81])
Attachments
(2 files, 2 obsolete files)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
3.86 KB,
text/plain
|
chutten
:
data-review+
|
Details |
We will need a telemetry probe to know when users have invoked the new print preview user interface, while preserving existing telemetry to know when users have invoked the old print dialog or print preview. Is it possible we could look at pp_open_count
and simply compare when the print.tab_modal.enabled
is true or false?
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
I don't think that's the right probe to use because we're shifting all the printing so that it invokes the preview, when previously it didn't. For instance, according to https://sql.telemetry.mozilla.org/dashboard/print-dashboard we can see pp_open_count
is way lower than dialog_without_pp_open_count
(MacOS: 368 vs. 728,041; Linus:31,910 vs. 271,700; Windows: 3M vs. 39M), but those numbers should be about the same in the new design…
![]() |
Assignee | |
Comment 2•5 years ago
|
||
(In reply to Sean Voisen (:svoisen) from comment #0)
Is it possible we could look at
pp_open_count
and simply compare when theprint.tab_modal.enabled
is true or false?
Martin, I think you were looking into that. Did you figure it out?
![]() |
Assignee | |
Comment 3•5 years ago
•
|
||
(In reply to Blake Winton (:bwinton) (:☕️) from comment #1)
I don't think that's the right probe to use because we're shifting all the printing so that it invokes the preview, when previously it didn't. For instance, according to https://sql.telemetry.mozilla.org/dashboard/print-dashboard we can see
pp_open_count
is way lower thandialog_without_pp_open_count
(MacOS: 368 vs. 728,041; Linus:31,910 vs. 271,700; Windows: 3M vs. 39M), but those numbers should be about the same in the new design…
As things stand with the current code, dialog_without_pp_open_count
should go to zero once all printing is via the new, print preview based UI (and pp_open_count
will basically go to 100%). dialog_via_pp_open_count
would count the number of times someone clicked "Print using the system dialog...". Finally, silent_print_count
would include the number of times users click the "Print" button in the new UI.
If anything, regardless of whether we can split the telemetry already based on the value of a pref, we probably want to separate out silent_print_count
to distinguish between "silent" prints (prints not involving the system dialog) coming from the new UI and those coming from extensions. We should also call that something other than "silent" too, since user interaction was needed to send the print to the printer.
Comment 4•5 years ago
|
||
I thought we can check if specific prefs are set because there are some fields in telemetry that sound relevant. However, after running a few examples, I think that only specific prefs are actually tracked.
So, I think we need to either add new telemetry or start tracking the value if print.tab_modal.enabled
as well.
![]() |
Assignee | |
Updated•5 years ago
|
![]() |
Assignee | |
Comment 5•5 years ago
|
||
![]() |
Assignee | |
Comment 6•5 years ago
|
||
Depends on D87302
![]() |
Assignee | |
Comment 7•5 years ago
|
||
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Comment on attachment 9170455 [details]
Data review
The review request here contains information that would excellently fill Q5 on the review request. I'm sorry I didn't make it clear in our conversation that the full form should be used, but it should.
Updated•5 years ago
|
Updated•5 years ago
|
![]() |
Assignee | |
Comment 9•5 years ago
|
||
Comment 10•5 years ago
|
||
Comment on attachment 9173445 [details]
Data review
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, :jwatt 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 11•5 years ago
|
||
Comment 12•5 years ago
|
||
bugherder |
![]() |
Assignee | |
Comment 13•5 years ago
|
||
Comment on attachment 9170427 [details]
Bug 1657220. Add telemetry for new print UI. r=bobowen,mbalfanz
Beta/Release Uplift Approval Request
- User impact if declined: No data on print overhaul reach and use.
- 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):
- String changes made/needed:
Comment 14•5 years ago
|
||
Comment on attachment 9170427 [details]
Bug 1657220. Add telemetry for new print UI. r=bobowen,mbalfanz
Approved for 81.0b6.
Comment 15•5 years ago
|
||
bugherder uplift |
Description
•