I assume we'd also move the logging code to WikimediaEvents for consistency with other events so tagging WikimediaEvents.

Mikhail has estimated that around 20% of survey responses could be lost if we do not migrate it.

In T417185#11609493, @Jdlrobson-WMF wrote:

I assume we'd also move the logging code to WikimediaEvents for consistency with other events so tagging WikimediaEvents.

I appreciate the desire to keep things loosely coupled but, in the case of QuickSurveys, it doesn't make sense to have a soft dependency on TestKitchen (previously EventLogging). To put it another way: What would be the point of deploying QuickSurveys without TestKitchen? You could run a survey, sure, but you wouldn't ever record any impressions or responses.

I suggest that we take this opportunity to make QuickSurveys have a hard dependency on TestKitchen.

@mpopov summarised it as:

The instrumentation isn't for feature analytics, it’s half of the feature itself.

I appreciate the desire to keep things loosely coupled but, in the case of QuickSurveys, it doesn't make sense to have a soft dependency on TestKitchen (previously EventLogging). To put it another way: What would be the point of deploying QuickSurveys without TestKitchen? You could run a survey, sure, but you wouldn't ever record any impressions or responses.

QuickSurveys supports third party (external) surveys. That's why it's a soft dependency. I don't know if any third parties use it just for that, but its feasible in future we might decide to lean into a third party API for surveys?

QuickSurveys supports third party (external) surveys.

In the case of external surveys, we track impressions and the click of the link to the external survey.

Just adding a comment here that captures internal discussions within the Research team on what would be enabled (for us) by this work (should it be prioritized):

1. Reader retention has become the primary metric for the readers teams and defines audiences within the funnel vision. However, if survey measures (demographics, attitudes, off-platform behavior) are to help us better understand potential causes of retention (or even differential rates of retention), they should be connected to direct measures of retention.
   1. Recent work we've conducted suggests that there might be some important limitations to self-reported measures of retention (there are few observable differences between readers at different stages of the engagement funnel except for highly-active readers: this is consistent with well-known shortcomings of recall-based survey measures). (https://phabricator.wikimedia.org/T424853). Summary deck available here.
2. Similarly, any future work on "Reader Archetypes" that builds on the updated reader use case taxonomy as well as the volunteer archetypes project would be much more impactful if use cases could be measured at the level of the reader rather than individual visit. This will allow us to identify clusters of typical mixtures of self-reported use cases and reader content interactions.

@Krinkle has suggested an alternative that I think we should definitely consider:

Perhaps QuickSurveys should call a MediaWiki REST API or Action API and then log the event server-side. I would expect that the scale at which we're willing to put surveys on-screen is generally on-par with what MW can handle and much lower than typical passive counters (statsv/prometheus) and passive instruments (EventLogging).

That could actually be a better way of collecting responses.

And then for T417288: QuickSurveys awareness of experiments conducted with Test Kitchen we could do something like:

experiment.send( 'quicksurvey_responded', {
  action_context: JSON.stringify( {
    survey_id: surveyId,
    response_id: responseId
  } )
);

where surveyId and responseId allow us to look up the exact response.