all open questions now answered in T171162: [Spike] Answer open questions on instrumentation for printing on desktop web

OK. I think I've folded in everything that @bmansurov found out in T171162: [Spike] Answer open questions on instrumentation for printing on desktop web. Let's see if the estimate shrinks a little!

We re-estimated this and again landed on an 8. The reason for the 8 and not a 5 is that we think there is some risk relating to sign off to avoid the issues we had with Popups. We want to capture testing and verifying fixes into the score, however thanks to @bmansurov we think this is a much better defined 8 and the risk has been mitigated somewhat!

Further to @Jdlrobson's explanation of our estimate above, we all agreed that, amongst other things, we must invest more effort in QA'ing instrumentation prior to merging/signing off. Also, given the number of browsers that we're hoping to support, testing this will require a concerted effort.

@phuedx: 0.1% of all distinct browser sessions seems to be a sensible default. This yields a peak rate of 5 events per second for the NavigationTiming instrumentation, for example.

But that's not a good comparison, considering that this schema will only send events for a fraction of all sampled sessions (those where a print action occurs). Per T167237#3402915 , the "printable version" link is clicked on less than 1/1000 of pageviews, i.e. a sampling rate of 100% would get us less than 6 of these events per second on average ;) Regarding our other planned event (browser print actions), we don't have an idea about their frequency yet - that's part of the goal here - but let's assume for now that they occur on less than 1/100 of pageviews. Altogether, assuming that these ratios hold through session sampling, a sampling rate of 10% should still result in an average event rate that's safely below the 10/second (average, not peak) that the Analytics Engineering team currently states as the limit above which one should check with them.

I stand corrected!

Adding to sprint, as print styles work is in signoff, as agreed during kickoff.

So this is not lost: We cautiously moved this back to "upcoming" as nobody is currently free to work on this and the print styles work is not done.. there could be follow up work in sign off (T169823) and Baha's patch (T169826) is still in flight.

@Tbayer could you take a look at the schema: https://meta.wikimedia.org/wiki/Schema:Print

Please feel free to update as needed. Thanks!

@Tbayer, since some browsers trigger onbeforeprint for each time a preview is rendered, do you think it would be wise to send this event only once per page view? So no matter how many times a user prints a page, this event will be sent only once. Or do we want to capture all such events for a given page when the user prints the page multiple times without reloading?

Similarly, with regards to the user clicking on the printable version link, do we want to capture all such clicks for a given page? Or is it enough to capture only the first such click?

In T169730#3589751, @bmansurov wrote:

@Tbayer, since some browsers trigger onbeforeprint for each time a preview is rendered, do you think it would be wise to send this event only once per page view? So no matter how many times a user prints a page, this event will be sent only once. Or do we want to capture all such events for a given page when the user prints the page multiple times without reloading?

I think we can be pragmatic about this and choose whichever is easier to implement. (It doesn't seem to be a very important product question.) If we we go with the second option and log multiple events during one pageview, we will be able to connect them using pageTitle and namespaceId.

Similarly, with regards to the user clicking on the printable version link, do we want to capture all such clicks for a given page? Or is it enough to capture only the first such click?

Ditto, it should be fine to do whichever is easier to implement

BTW, it would be good to document the eventual choice in the schema page.

In T169730#3585982, @bmansurov wrote:

@Tbayer could you take a look at the schema: https://meta.wikimedia.org/wiki/Schema:Print

Please feel free to update as needed. Thanks!

Looks good to me!

I started the schema documentation on the talk page, please check and make edits if necessary (wasn't sure which project to attach): https://meta.wikimedia.org/wiki/Schema_talk:Print
@ovasileva, I listed you and Baha as maintainers, let me know in case you prefer to instead include me or someone else from the team.

Once it is up and running, we also need to whitelist it, I'm adding a subtask for that.

In T169730#3590362, @Tbayer wrote:

In T169730#3585982, @bmansurov wrote:

@Tbayer could you take a look at the schema: https://meta.wikimedia.org/wiki/Schema:Print

Please feel free to update as needed. Thanks!

Looks good to me!

I started the schema documentation on the talk page, please check and make edits if necessary (wasn't sure which project to attach): https://meta.wikimedia.org/wiki/Schema_talk:Print
@ovasileva, I listed you and Baha as maintainers, let me know in case you prefer to instead include me or someone else from the team.

Once it is up and running, we also need to whitelist it, I'm adding a subtask for that.

sounds good. Thank you @Tbayer!

@Tbayer thanks! I've updated the schema talk page. I decided to log events only once because it's easier to implement and less headache for dealing with duplicate events.

• Implement the schema's purging strategy by submitting a patch to the whitelist or filing a task with Analytics Engineering.

@Tbayer what should be the strategy? The default is 90 days, and no change is needed if we want to keep it.

In T169730#3592061, @bmansurov wrote:

• Implement the schema's purging strategy by submitting a patch to the whitelist or filing a task with Analytics Engineering.

@Tbayer what should be the strategy? The default is 90 days, and no change is needed if we want to keep it.

I already specified one in the talk page template - I think we should keep the non-sensitive data for later reference (like we do for the Popups schema).

I've created T175395: Implement Schema:Print purging strategy and removed the requirement from this task.

@Tbayer I've set up event logging for print at http://reading-web-staging.wmflabs.org/wiki/Main_Page. The sampling rate is set to 90% for easy bucketing. Please let me know if you need anything else for testing.

Change 376427 had a related patch set uploaded (by Bmansurov; owner: Bmansurov):
[mediawiki/extensions/WikimediaEvents@master] Add support for Schema:Print

https://gerrit.wikimedia.org/r/376427

@Tbayer can you verify this works properly?

Change 376427 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@master] Add support for Schema:Print

https://gerrit.wikimedia.org/r/376427

Ping @Tbayer. Following on from T169730#3611297 and T169730#3605628, should I set up a meeting with you and @bmansurov to go through the instrumentation on the staging server?

Thanks @phuedx - since @bmansurov and I already had a call about this earlier (with testing on his local installation), I did some checks on reading-web-staging my own already.

It successfully sent clickPrintableVersion events from Firefox and Chromium under Ubuntu from various pages. I also checked the value of event_isAnon after logging in, and tried generating an event on a non-mainspace (File:..) page.

Under Chromium, the onBeforePrint events worked too, but I wasn't able to generate them in Firefox (via File --> Print). Looking at the EL table, Baha did actually generate onBeforePrints under Firefox too on his local installation, albeit only for Special:Book. Could someone look into this?

With an eye on T175918, I checked that events were being sent on three consecutive pageviews in the same session. They were, although that's of course not yet a guarantee that that bug won't affect this schema as well.

BTW, at first it did not send events for me at all in Firefox when using private browsing (even when bucketed and with DNT disabled). It look like this was due the new(ish) additional tracking protection: https://support.mozilla.org/en-US/kb/tracking-protection-pbm After deactivating it in the Firefox settings, events were sent.

For the record, the events I generated can be found via SELECT * FROM log.Print_17199246 WHERE userAgent LIKE '%Ubuntu%';
`

BTW, it looks like this schema is active on Minerva too - is this intentional?

 SELECT event_skin, COUNT(*) FROM log.Print_17199246 GROUP BY event_skin;
+------------+----------+
| event_skin | COUNT(*) |
+------------+----------+
| apioutput  |       22 |
| minerva    |    18600 |
| modern     |        4 |
| monobook   |       38 |
| vector     |   290994 |
+------------+----------+
5 rows in set (1.56 sec)

Yes, we're instrumenting on all skins: related code.

OK - just wondering if Minerva is considered desktop web in this context.

As explained at T175395#3662739 , including Minerva actually causes some problems with the purging strategy (or, precludes an easy option to resolve these); so I have suggested there to simply restrict the instrumentation to desktop, consistent with the original task description. @ovasileva, let us know in case we actually need data for mobile web too.

In T169730#3662743, @Tbayer wrote:

As explained at T175395#3662739 , including Minerva actually causes some problems with the purging strategy (or, precludes an easy option to resolve these); so I have suggested there to simply restrict the instrumentation to desktop, consistent with the original task description. @ovasileva, let us know in case we actually need data for mobile web too.

@Tbayer - we do. We are changing the usage for the download to PDF option on mobile to have the button trigger the print modal for all Android devices. We would need this schema to be able to track usage there: T177215: Build download button for mobile PDF download

Change 386911 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/WikimediaEvents@master] Limit logged skins for print event only to vector and minerva

https://gerrit.wikimedia.org/r/386911

Change 386911 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@master] Limit logged skins for print event only to vector and minerva

https://gerrit.wikimedia.org/r/386911

@bmansurov BTW, i just noted that Chrome 63 and later seem to now support the beforeprint and afterprint events as well. Apparently this made it into the HTML5 Living standard now.

Thanks for the ping, @TheDJ. Yeah, I forgot to comment that support for the {before,after]print events landed in Chromium on September, 27th: https://bugs.chromium.org/p/chromium/issues/detail?id=218205

Good news. Now, the easy part is left: upgrade our users' Chromes. 😜