holding space for instrumentation work getting done this sprint while we determine scope

There is additional feedback from @HFan-WMF and Jennifer on the parent task https://phabricator.wikimedia.org/T414368

Currently the clickTracking instrument captures some overlapping metrics that the ReadingListAB test does.

clickTracking logs:

1. an init event on every page load
   • Fires once per page when the DOM is ready.
2. click events when users interacts with:
   • Vector menu links (.vector-menu a )
     • This captures: #ca-bookmark and #ca-more-bookmark
   • Elements with data-event-name attributes that are <a>, <button> or <input> elements
     • For Vector this captures: #ca-bookmark-sticky-header
     • For Minerva this captures: it's only icon #ca-bookmark

clickTracking uses the mediawiki.web_ui_actions schema. Which has a default sampling rate of 20% but for English it is 1%. This sampling is deterministic per session. So all events from that session are sent if the session is in sample.

They slightly differ in contextual attributes. In ext-EventStreamConfig.php, mediawiki.web_ui_actions includes performer_pageview_id, performer_groups and user-agent while mediawiki.product_metrics.reading_list includes page_content_language and performer_is_temp.

So I believe we can use clickTracking to log page-load and click events to the readingList icons. We just might need to account for the slight difference in contextual attributes.

This is in line with what I remember - thanks for taking the time to look into it and write up the finer points!

Over to @HFan-WMF/@jwang for sign-off - I'd imagine the remaining question is whether those metrics are indeed redundant given the sampling/contextual attribute discrepancies

Upon further discussion, I think it makes more sense to keep the tracking of ReadingList icons to the ReadingList instrument, as opposed to using the clickTracking instrument. As this part of the clickTracking instrument is not used elsewhere anymore and can be cleaned up/decommissioned.