Page MenuHomePhabricator

Implement User Satisfaction Test Schema 2.0.0
Closed, ResolvedPublic

Description

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.

Event Timeline

Ironholds raised the priority of this task from to Needs Triage.
Ironholds updated the task description. (Show Details)
Ironholds added a subscriber: Ironholds.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 18 2015, 5:25 PM
Ironholds renamed this task from Create User Satisfaction Test Schema 2.0.0 to Implement User Satisfaction Test Schema 2.0.0.Aug 18 2015, 9:27 PM
Ironholds set Security to None.

Change 232896 had a related patch set uploaded (by EBernhardson):
V2 of user satisfaction test for search

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

This patch was tweaked again yesterday due to a caching issue. It now needs code review again.

Change 232896 merged by jenkins-bot:
V2 of user satisfaction test for search

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

Deskana closed this task as Resolved.Aug 31 2015, 6:14 PM

Above patch was merged. This is done.

Krinkle added a subscriber: Krinkle.Sep 5 2015, 6:17 PM

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?