As part of the work on T258183, we need to specify what exactly we will be measuring. This means either [[ https://wikitech.wikimedia.org/wiki/Event_Platform/Schemas#Creating_a_new_schema | developing a new EventPlatform schema ]] or extending/adapting an existing one like [[ https://gerrit.wikimedia.org/r/plugins/gitiles/schemas/event/secondary/+/master/jsonschema/analytics/legacy/searchsatisfaction/current.yaml | SearchSatisfaction ]].
Earlier @nettrom_WMF and I discussed potentially re-using the SearchSatisfaction schema here; the more I think about this, the less sure I am that this is how we ought to proceed. I think that re-using the SearchSatisfaction schema has both pros and cons worth considering:
- The schema already exists
- Ideally this would make it easier to compare metrics between the traditional **Special:Search** page and the new **Special:MediaSearch** page on Commons.
- SearchSatisfaction is a legacy schema, and there is a desire to start using the new platform in earnest
- Even if we do adapt the existing schema to MediaSearch, there are several features in the new UI that don't have any equivalent in the default search experience: tabs based on media type, the Quickview, etc. Eventually we probably will want some kind of schema to represent user interactions with these features.
Given the last point, I'm starting to think that even if we are able to extend or inherit from SearchSatisfaction for some things, we will need explicit definitions of some media-specific "actions". I'm using the [[ https://docs.google.com/document/d/1djZm--cRwzq52sO8IW2KSyk9sbWD9yz8XssSqRxruQs/edit#heading=h.xsfavbt0qjbe | Media Search Measurement Specifications ]] document as a starting point, but I'd like to try to go into a little more detail here. **Feedback on these would be greatly appreciated** – for one thing, I'd like to know if I'm thinking about these "actions" in too high-level of a way: is it better to log things at a very low level in terms of clicks, mouse movements, etc. to provide as much data as possible – especially when things go wrong? Or is this just going to kill our signal-to-noise ratio in the data?
| Action (high-level) | Description | Properties |
| --- | --- | --- |
| Search | User performs a new search for a given query | session ID, query, hits returned, media type, active filters |
| Load more | User scrolls or clicks within an existing set of results to continue a search without changing the query | session ID, query, hits returned, media type, active filters |
| Clear | User clicks the "X" button and clears the query along with all results in all tabs | session ID |
| Tab change | User changes tabs (which correspond to file types) without changing the search query or clearing existing results | session ID, query, hits returned, media type, active filters |
| Filter change | User updates a filter value within a given tab, forcing retrieval of a new set of results within that tab | session ID, query, hits returned, media type, active filters |
| Result click | User clicks on a result within a given tab. Exactly what happens depends on other factors (whether the tab allows quickviews, whether they explicitly ctrl-click, etc) | session ID, position (one-dimensional index starting at zero), pageID of result, click type?, media type |
| Display Quickview | Quickview panel is opened to display preview of a specific result within a given tab | session ID, pageID of result, media type |
| Quickview media play | User starts/stops playback of an audio/video quickview element; we probably also want to measure how long media is played for somehow | session ID, TBD |
| Quickview link click | User clicks a link inside quicview (could be from description wikitext, link to user who uploaded, etc) | session ID, TBD |
| Quickview snippet copy | User copies a snippet of wikitext for a quickview file to their clipboard through use of a dedicated button | session ID, TBD |
| Hide quickview | User dismisses quickview using the "X" button or keyboard | session ID, TBD |
| Concept chip click | User clicks a search suggestion/concept chip element | session ID, TBD |