Change Details

We will cleanup and clarify the information we log with regards to the beta mode. == Acceptance criteria [] Remove all code relating to [Schema:MobileOptionsTracking](https://meta.wikimedia.org/wiki/Schema:MobileOptionsTracking) [x] Update https://grafana.wikimedia.org/dashboard/db/mobile-dashboard?orgId=1 explaining what they actually mean. They are not mobile web opt ins. [] Mark [the MobileOptionsTracking schema](https://meta.wikimedia.org/wiki/Schema_talk:MobileOptionsTracking) as inactive. [] Notify Analytics Engineering that all MobileOptionsTracking data can be dropped. == Background 1) We have [[ https://meta.m.wikimedia.org/wiki/Schema:MobileOptionsTracking | Schema:MobileOptionsTracking ]]. This is meant to track activity to the beta field (e.g. opt-in and opt-out) and lives inside [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/specials/SpecialMobileOptions.php | Special:MobileOptions ]]. It uses server-side event logging. 2) We also log opt ins to beta/stable via wfIncrStats (statsd) for `mobile.opt_in_cookie_set` and `mobile.opt_in_cookie_unset`. It lives inside [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/MobileContext.php | MobileContext ]] 3) When a user is logged in and opts into beta we record this their preferences (https://phabricator.wikimedia.org/T67079#3815127). The current implementation of the new form in the `specialpages` branch introduces asynchronous saving via JavaScript. This means it cannot use server-side event logging, i.e. it breaks #1. If we want to continue using #1, we'll need to create some new client-side code to log this. It does not break #2 or #3. Which of these do we actually need and what can be removed? Consider the following questions that we want to answer about the mobile site's beta mode: - The changes in current (and historical) number of users in the beta feature over time - The ratio of pageviews with beta mode enabled to all pageviews of the mobile site 👍 - This is possible without any changes. See T182235#3833724. = Closed Questions If we want to understand how people interact with the form pages differently post the redesign (T67079), we will likely need track these interactions directly, as it may not be possible to isolate their impact on the beta pageview ratio and/or the number of number of beta users (for which we have data, see above). We need to work out how to do this with statsd or EventLogging or something new. The EventLogging is broken and written on server side. Fixing this would require fixing the instrumentation in the master branch AND rewriting it in the new branch. Statsd may be easier but may not be measuring exactly what we need, and it may be harder to debug (because it's not queryable by event). @phuedx: This is answered/dismissed in T182235#3887715.

We will cleanup and clarify the information we log with regards to the beta mode. == Acceptance criteria [x] Remove all code relating to [Schema:MobileOptionsTracking](https://meta.wikimedia.org/wiki/Schema:MobileOptionsTracking) Done in https://gerrit.wikimedia.org/r/#/c/404495/. [x] Update https://grafana.wikimedia.org/dashboard/db/mobile-dashboard?orgId=1 explaining what they actually mean. They are not mobile web opt ins. [] Mark [the MobileOptionsTracking schema](https://meta.wikimedia.org/wiki/Schema_talk:MobileOptionsTracking) as inactive. [] Notify Analytics Engineering that all MobileOptionsTracking data can be dropped. == Background 1) We have [[ https://meta.m.wikimedia.org/wiki/Schema:MobileOptionsTracking | Schema:MobileOptionsTracking ]]. This is meant to track activity to the beta field (e.g. opt-in and opt-out) and lives inside [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/specials/SpecialMobileOptions.php | Special:MobileOptions ]]. It uses server-side event logging. 2) We also log opt ins to beta/stable via wfIncrStats (statsd) for `mobile.opt_in_cookie_set` and `mobile.opt_in_cookie_unset`. It lives inside [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/MobileContext.php | MobileContext ]] 3) When a user is logged in and opts into beta we record this their preferences (https://phabricator.wikimedia.org/T67079#3815127). The current implementation of the new form in the `specialpages` branch introduces asynchronous saving via JavaScript. This means it cannot use server-side event logging, i.e. it breaks #1. If we want to continue using #1, we'll need to create some new client-side code to log this. It does not break #2 or #3. Which of these do we actually need and what can be removed? Consider the following questions that we want to answer about the mobile site's beta mode: - The changes in current (and historical) number of users in the beta feature over time - The ratio of pageviews with beta mode enabled to all pageviews of the mobile site 👍 - This is possible without any changes. See T182235#3833724. = Closed Questions If we want to understand how people interact with the form pages differently post the redesign (T67079), we will likely need track these interactions directly, as it may not be possible to isolate their impact on the beta pageview ratio and/or the number of number of beta users (for which we have data, see above). We need to work out how to do this with statsd or EventLogging or something new. The EventLogging is broken and written on server side. Fixing this would require fixing the instrumentation in the master branch AND rewriting it in the new branch. Statsd may be easier but may not be measuring exactly what we need, and it may be harder to debug (because it's not queryable by event). @phuedx: This is answered/dismissed in T182235#3887715.

We will cleanup and clarify the information we log with regards to the beta mode. == Acceptance criteria [x] Remove all code relating to [Schema:MobileOptionsTracking](https://meta.wikimedia.org/wiki/Schema:MobileOptionsTracking) Done in https://gerrit.wikimedia.org/r/#/c/404495/. [x] Update https://grafana.wikimedia.org/dashboard/db/mobile-dashboard?orgId=1 explaining what they actually mean. They are not mobile web opt ins. [] Mark [the MobileOptionsTracking schema](https://meta.wikimedia.org/wiki/Schema_talk:MobileOptionsTracking) as inactive. [] Notify Analytics Engineering that all MobileOptionsTracking data can be dropped. == Background 1) We have [[ https://meta.m.wikimedia.org/wiki/Schema:MobileOptionsTracking | Schema:MobileOptionsTracking ]]. This is meant to track activity to the beta field (e.g. opt-in and opt-out) and lives inside [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/specials/SpecialMobileOptions.php | Special:MobileOptions ]]. It uses server-side event logging. 2) We also log opt ins to beta/stable via wfIncrStats (statsd) for `mobile.opt_in_cookie_set` and `mobile.opt_in_cookie_unset`. It lives inside [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/MobileContext.php | MobileContext ]] 3) When a user is logged in and opts into beta we record this their preferences (https://phabricator.wikimedia.org/T67079#3815127). The current implementation of the new form in the `specialpages` branch introduces asynchronous saving via JavaScript. This means it cannot use server-side event logging, i.e. it breaks #1. If we want to continue using #1, we'll need to create some new client-side code to log this. It does not break #2 or #3. Which of these do we actually need and what can be removed? Consider the following questions that we want to answer about the mobile site's beta mode: - The changes in current (and historical) number of users in the beta feature over time - The ratio of pageviews with beta mode enabled to all pageviews of the mobile site 👍 - This is possible without any changes. See T182235#3833724. = Closed Questions If we want to understand how people interact with the form pages differently post the redesign (T67079), we will likely need track these interactions directly, as it may not be possible to isolate their impact on the beta pageview ratio and/or the number of number of beta users (for which we have data, see above). We need to work out how to do this with statsd or EventLogging or something new. The EventLogging is broken and written on server side. Fixing this would require fixing the instrumentation in the master branch AND rewriting it in the new branch. Statsd may be easier but may not be measuring exactly what we need, and it may be harder to debug (because it's not queryable by event). @phuedx: This is answered/dismissed in T182235#3887715.