When a user is logged and in opts into beta mode in Special:MobileOptions we set a preference, but this is not logged in Schema:PrefUpdate. It should be.
Currently WikimediaEvents Hook listens to UserSaveOptions hook, and when the user changes preferences it tracks the change in PrefUpdate schema. The Mobile Beta Mode (do not mix with Beta Features) preferences is stored in UserOptions, so it supposedly, all Mobile Beta Mode switches should be tracked by PrefUpdate schema. This doesn't happen because WikimediaEventsHooks::onUserSaveOptions logic tracks the Analytics Events only when User::saveOptions was called on:
- via API action=options call
All other events are just ignored. This is expected as most probably we don't want to track user preferences when user object is created (user creation) and during maintenance scripts.
We're planning to store the Advanced Mobile Contributions preference as UserOption and track user retention. The PrefUpdate schema looks like the best candidate but because of WikimediaEventsHooks:onUserSaveOptions logic we cannot use it.
Why WikimediaEvents tracks PrefUpdate only on Special:Preferences page submits and action=options API calls?
Answer: It's done this way to limit all analytics events only to user actions. We don't want to track PrefUpdate when maitenance script or custom logic enables features for users.
Can we remove that logic and track PrefUpdate on any page? There are not that many places that call User::saveSettings, definitely we have to not track events on maitenanceScripts, what about other places?
Answer: No, there are pages that update user options and we don't want to track those (because that are not user initiated actions), for example, we don't want to track:
- an ongoing experiment where we enable HelpPanel to 50% of users (https://phabricator.wikimedia.org/diffusion/EGRE/browse/master/includes/HelpPanelHooks.php$60), this shouldn't be tracked
- we override the default Page previews isEnabled state to all new accounts (https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/includes/PopupsHooks.php#L158)
Most probably there are more situations like two mentioned above.
The safest way is to just to add $title->isSpecial('Preferences') || $title->isSpecial('MobileOptions'), but maybe there is something we can improve.
There is a TODO in code
// TODO (mattflaschen, 2013-06-13): Ideally this would be done more cleanly without // looking explicitly at page names and URL parameters. // Maybe a userInitiated flag passed to saveSettings would work.