The analysis of the data coming out of the TestSearchUserSatisfaction schema says that we're dropping events and ending up with a weirdly narrow set of browsers - probably due to the JS complexity.
Redesign the schema so that it's simpler and less liable to drop events.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| V2 of user satisfaction test for search | mediawiki/extensions/WikimediaEvents | master | +36 -48 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | EBernhardson | T109482 Implement User Satisfaction Test Schema 2.0.0 | |||
| Resolved | Ironholds | T109523 Create TestUserSatisfaction 2.0.0 schema |
Change 232896 had a related patch set uploaded (by EBernhardson):
V2 of user satisfaction test for search
This patch was tweaked again yesterday due to a caching issue. It now needs code review again.
I don't know if it's intentional, but I noticed today (when I got selected for the campaign) that from the search results page onwards every subsequent link I clicked in that reading session was tracked with wprov=cirrus. Even after being far away from the original search query.
E.g. searching X and open result X-Y, then XY-Z1 and XY-Z2, from there open XYZ-1-A, XYZ-2-B etc. each time it kept re-adding it to all links in the page. Initially I thought this was because the previous result was a disambiguation page (still kind of search-result-ish) but looking over the code that isn't the case.
I just wanted to double check that is intentional. Most of these events will not be an indicator of search success. One can't assume the link trail to be logical order (since beacons are async, and also because users can several trails in different tabs, but originating from the same search page). I also worry that the link trail may be privacy sensitive, something to keep in mind.
This was the original plan for tracking search pathways but I thought
Erik and Max had come up with a smarter solution. Erik?