Jump to content

EventLogging/Universal Language Selector October 2012

From Wikitech

In October 2012, the mw:Wikimedia Language engineering team evaluated the different available tracking tools for the metrics it needed, in particular for mw:ULS; this assessment is copied from etherpad:l10n-tracking. (As of July 2013, the EventLogging tracking is being implemented.[1])

Conclusion: Interface directly

Extension EventLogging

The Analytics Team is aiming to have a prototype end-point operational by mid November to start receiving traffic from the new EventLogging extension.

-> Not ready for our use at this point. Maybe if development continues at fast pace.

Extension ClickTracking

  • https://www.mediawiki.org/wiki/Extension:ClickTracking (AFAIK, Clicktracking will be deprecated October 30th)
  • Above page says documentation is very limited, and I can confirm
  • Contains some very specific code of interest to us like
    • $wgClickTrackSidebar
    • 'namespacenumber' => 'the namespace number being edited',
    • seems to be tailored to count page edits over time (?)
  • Logging to database & file
  • The code has not been maintained recently
  • There are quite many things done for scalability that make the code and logic confusing and which we likely won't need
    • For example the primary table has integer eventids with a mapping of string to ids in another table. From my experience with revtag table in Translate, this is annoying and in fact was dropped as unneeded.
  • There is some code for user bucketing (e.g. placing some users in control groups), but it's not documented too well nor am I sure that it is useful for us in the way it is implemented
  • Uses cookies (not necessarily bad thing)
  • PHP side API is awkward, calling the WebAPI internally (and that is messy in my experience)
  • The core JS API is not too bad, though if redone today I'm sure it would be implement in a different way
  • Was developed by Trevor, Nimish (later Roan and Krinkle) two years ago
  • Only few commits here and there in the last year, mostly by Ori and Roan
    • The original authors are unlikely to be available for help
    • Is Ori shifting his attention to EventLogging extension now? That would mean that we would be on our own with this. <- SM: Not acceptable. I'm reiterating that we are not going to design and write analytics code. If it's not provided, then we won't do it. It's a waste of our domain knowledge.
    • Does not seem to support collecting statistics over multiple wikis (and considering same user in multiple wikis as one user) <- SM: Hard requirement.
    • Is not intergated into any analytics infrastructure as far as I know. <- SM: This is a huge issue wrt analytics in time. Pondering if this is MUST have or SHOULD have. If I'd ask Diederik, I'm almost certain he'd call this a blocker.
    • Help with the raw number of clicks, but for example tracking the signup process, and detecting why and where user aborts it is not immediately available. There are no helper tools to process the data anyway.

-> Looks like a dying extension. Irrelevant* functionality and missing docs make usage hard, while still leaving everything more complicated than giving the raw number of times each action is made to us.

-> Certainly, it can be used to track things like "how many users enable/disable webfonts", but it's not going to help with things like "what is the active translators group using Translate and their activity preferably combined for all Translate enabled wikis".

-> I would love to know if and how the E3 or other teams are actually using this extension (or something else) as part of AB-testing and stuff.

(*) I believe it is irrelevant, but lack of docs makes it hard to confirm.

PS: git log --format="%an %ar: %s" | grep -v "Localisation updates"