Often, a survey should be posted to all users generally, or to users who fit a defined pattern, such as being admins. But sometimes, we want to talk to editors who have just done something, such as editing a page, uploading a file, or changing the filters in RecentChanges. It would be nice if a survey question could be limited to users who have performed a particular action.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T89970 Enable microsurveys for long-term tracking of editing experience | |||
| Open | None | T183995 Make it possible to survey users who have just taken or completed an action |
Event Timeline
Comment Actions
Removing MediaWiki-Page-editing so that this doesn't clutter searches related to actually editing pages in MediaWiki. This project should only be on the parent task, probably (T89970). [batch edit]
Comment Actions
Also, if a microsurvey appears as soon as the page is displayed, it might be annoying for someone who's just trying to check a quick fact. I believe that we'll usually get higher response rates from people who have done something other than just clicked a link to a Wikipedia article.
"Actions" don't have to be defined as narrowly as "saved an edit". One interesting trigger action for reading-oriented questions might be navigating to a second page on the same wiki.
Comment Actions
This seems like a natural application for experiment bucketing. If we add survey configuration to use a custom bucket name, and control the user's bucket cookie externally from QuickSurveys, we can wire to any kind of selection logic. The general problem is similar to the perceived performance case, see T255412#6227373.
Comment Actions
I want expand on this part,
control the user's bucket cookie externally from QuickSurveys, we can wire to any kind of selection logic
We came across a related use case of a survey that should only be administered to people with syntax highlighting enabled in preferences. I'd like to have an interface like: (campaign name) -> side effect that the user sees a survey popup for the campaign.
The simplest implementation would be as a cookie, settable from client or server. The cookie's contents will be a single value, the campaign name. For anonymous users, when Varnish receives this cookie it varies cache, triggering a special rendering of the current page which should not be cached. This rendering will embed a resourceloader JSON object for that survey campaign. The cookie will persist until the survey is displayed, and then is cleared.
I'm not sure about how to handle campaigns sampled at less than 100%, the least effort would be to rely on the existing sampling mechanism, and let the cookie persist until the survey is rendered. But this would be expensive because of the cache-vary, so it might make sense to limit who gets the cookie, sampling at that point, and then injecting an unsampled survey to be displayed immediately. We want the cookie immediately cleared. Another possibility and maybe an improvement to the whole system, would be to do a one-time transfer of active surveys to the user's browser storage. In this case the cookie would trigger a survey being added to the client's cache, but triggering that survey would still be controlled by the usual survey selection criteria.
Comment Actions
This task comes up regularly at our team discussions, mostly in a good way :-) If there are plans to work on it one day, please keep us in the discussion. It would be great to agree on a strategy, then there might be enough interest that a more complete proposed implementation attracts stray developers...