We will cleanup and clarify the information we log with regards to the beta mode.
- Remove all code relating to Schema:MobileOptionsTracking
Done in https://gerrit.wikimedia.org/r/#/c/404495/.
- 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 as inactive.
Done in https://meta.wikimedia.org/w/index.php?title=Schema_talk%3AMobileOptionsTracking&type=revision&diff=17650781&oldid=13302734.
- Notify Analytics Engineering that all MobileOptionsTracking data can be dropped.
See T185339: Archive and drop the MobileOptionsTracking EventLogging MySQL table.
- We have Schema:MobileOptionsTracking. This is meant to track activity to the beta field (e.g. opt-in and opt-out) and lives inside Special:MobileOptions. It uses server-side event logging.
- 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 MobileContext
- When a user is logged in and opts into beta we record this their preferences (https://phabricator.wikimedia.org/T67079#3815127).
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.
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.