Forwarding to mobile-l in case anyone is interested. Analytics for
mobile including statistics around alpha and beta usage.
---------- Forwarded message ----------
From: David Schoonover <dsc(a)wikimedia.org>
Date: Tue, Apr 23, 2013 at 2:45 AM
Subject: Mobile Site Session Data (with Bonus Analytics!)
To: mobile-tech <mobile-tech(a)wikimedia.org>, Analytics List
<analytics(a)lists.wikimedia.org>
Cc: Diederik van Liere <dvanliere(a)wikimedia.org>, Maryana Pinchuk
<mpinchuk(a)wikimedia.org>, Arthur Richards <arichards(a)wikimedia.org>
Howdy all,
Now that the stars have aligned and:
- The Mobile Frontend release with X-Analytics logging the site mode
cookie (mf-m) has been out for a bit, and shows up in our logs;
- We've deployed the patch to fix a critical Hadoop bug[1][2] that was
blocking the job
- I've personally "conquered" the wikiplague again (after being out
half last week)
- And finally, the script works and its results look valid and complete
...I'm happy to report the Mobile site sessions job[3] is ready to
ship. I'm pretty sure this is the first view of mobile site sessions
ever, so I was pretty excited. I've included some Bonus Stats from my
test run which I generated 'cause I was curious :)
Before we get too excited, though, I've held off on enabling the daily
job (as well as backfilling March) because it turns out that a day's
worth of data generates about 16GB worth of sessions. This isn't a
problem for the cluster, but we'd pretty rapidly compromise stat1001's
public data storage with daily syncs. So to go forward, access to the
data would probably have to be provided via private rsync. A third
option is to work with the data on the cluster itself via any of the
available tools; I've been using a SQL tool called Hive to validate
various job runs and I can't say I'm missing MySQL. (If people are
interested, I'd be happy to go over the options in more detail.)
So, we're looking for guidance on going forward.
- Is the granular session output still the desired result, given the
job's size? Current the job ends by coalescing the data into one giant
TSV; instead it could generate a summary, or a selection of stats
about the run.
- If so:
- Is it helpful to backfill March?
- Does the data need to be publicly accessible via HTTP, or can we
explore other options for providing access to the team?
I'm happy to answer any other questions as well.
Thanks!
Dave for Team Analytics
[1] The bug: https://issues.cloudera.org/browse/DISTRO-461
[2] The fix: https://mingle.corp.wikimedia.org/projects/analytics/cards/595
[3] Feature request:
https://mingle.corp.wikimedia.org/projects/analytics/cards/240
---
BONUS STATS!
Notes:
- As a reminder, a session (or "visit") is defined as all activity
with less than 30 minutes between each hit.
- The test job looked at all requests on 4/21, which is 75.17 GB of
request logs.
- It took ~17 minutes to process the day into 15.3 GB of sessions. (It
then took 51m44s to concatenate those 28 files into one monstrous TSV
for "ease" of delivery to y'all.)
- The summary below took maybe 10 minutes to set up/write in Hive, and
the job took maybe 7 minutes.
Visits to Mobile Site, 4/21/2013
- Total Visits: 51,624,103
- Unique Visitors: 37,736,120
- Total Pageviews: 104,972,033
- Avg Pageviews per Session: 2.0334
- Max Pageviews in one Session: 141,882
Standard Site
- Visits: 51,603,221
- Unique Visitors: 37,723,188
- Pageviews: 104,910,382
- Avg Pageviews per Session: 2.033
Alpha Site
- Visits: 986
- Unique Visitors: 822
- Pageviews: 7,087
- Avg Pageviews per Session: 7.188
Beta Site
- Visits: 19,896
- Unique Visitors: 16,235
- Pageviews: 54,564
- Avg Pageviews per Session: 2.742
Those numbers look sane to you guys?
--
David Schoonover
dsc(a)wikimedia.org
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
I've been playing around with skins a lot recently. The MobileFrontend
extension has had to do various transformations to the content
pre-rendering to ensure certain things do not get rendered on mobile
(for example table of contents) as well as allow us to do collapsible
sections.
When rendering content skins are currently limited to rendering the
'bodytext' key. They cannot retrieve the underlying content. I would
like to remove restrictions to skin designers - for instance currently
a skin designer has no control over where the table of contents should
do. They could not easily put it in a side bar for instance.
I was experimenting with using the onOutputPageParserOutput hook [1]
(running based on the current skin) and think it might be a better
approach to run the transformations on smaller chunks of data. For
instance the table of contents is known to be in the lead section so
it seems like it would be more efficient to look for it there rather
than throughout the entire document. The solution is not complete but
provides an approach that I think would be more efficient on the long
term.
It seems like a good idea to experiment with this approach in
MobileFrontend extension with the goal to upstream it to core.
Would appreciate comments from people who know this area of code
rather well - Max comes to mind :)
Thoughts welcomed!
[1] https://gist.github.com/jdlrobson/5439509
There seem to be a few teething problems but with help from Matt
Walker we managed to set up a banner on test wiki [1] (beta and alpha
versions of the site) today that runs on mobile only and only for
Android devices (albeit it's not 100% reliable yet in that it won't
target Android devices viewing a MediaWiki instance in Opera
Mobile/Mini).
Currently it simply shows a banner suggesting the user downloads the
Wikimedia Commons app with a "yes please" button and "no thanks"
button. The "yes please" button links to the Google Play store, the no
thanks button closes it and sets a cookie so it isn't shown again.
The campaign is configured here:
* http://test.wikipedia.org/w/index.php?title=Special:CentralNotice&method=li…
and the banner configured here:
* http://test.wikipedia.org/w/index.php?title=Special:NoticeTemplate/view&tem…
/
Currently there is no UI on the Special:CentralNotice page to target
certain devices (Matt had to make some changes behind the scenes for
this time) but soon it should allow banners to be targeted to
'desktop', 'iphone' and 'android' so it will be possible to run iphone
only campaigns.
Obviously there are new and big challenges with running banners on a
mobile device - space is even more important so any campaigns that do
run on these devices will need to be very creative!
Thanks to Matt and the Fundraising team for working with us to get
this live! Please feel free to ask any questions or start
conversations around banners on mobile / interesting uses. I'm happy
to provide my knowledge on what is possible and what is not possible
and I cross my fingers that people will start thinking about mobile in
designing their banners rather than pushing a desktop tested banner on
to a mobile phone :-)
[1] https://test.m.wikipedia.org/wiki/Main_Page?mobileaction=beta
I was very happy to just notice www.wikivoyage.org
Who should I speak to about optimizing the wikivoyage landing page for
mobile...?
(Sorry... I can never remember how to find the equivalent wiki page :-))
I just received this mail from a user:
"...I upgraded to Mediawiki 1.20 on me dev machine, and things
seem to work fine.
However using MF for MW 1.20 has no auto-detect, so it's not very
useful to me :)
Is there any chance you fix this on the master version as well (which
has built it auto-detect)?"
It seems various other people are being confused with how mobile
detection works [1], myself included so I have setup this basic stub
of a page [2] to hopefully document this. Please share your knowledge
here!
[1] http://www.mediawiki.org/w/index.php?title=Extension_talk:MobileFrontend&of…
[2] http://www.mediawiki.org/wiki/Extension:MobileFrontend/Configuring_Browser_…
On Wed, Apr 3, 2013 at 8:34 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> Eek. I'm afraid getting this to work on an older MediaWiki/MobileFrontend
> extension is extremely problematic. So much has changed both in core and the
> MobileFrontend extension to this....
>
> Are you sure migrating your wiki will be as problematic as you suspect?
>
> Best wishes and sorry to the be the bearer of bad news!!
> Jon
>
>
> On Tue, Apr 2, 2013 at 6:50 AM, ויקיפועל <wikipoel(a)gmail.com> wrote:
>>
>> Hi, thank you for fixing this bug I opened. I appreciate it. However
>> I'm using MW 1.18 and an older version of MobileFrontend without
>> skins. I know it's a lot to ask for, but perhaps you'd be willing to
>> see if such a small fix can also be applied for older versions of the
>> extension?
>> Migrating my entire wiki to 1.20 just for this is problematic
>>
>> Thank you
>>
>>
>> https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend…
>
>
Hi,
After upgrading my site's MediaWiki install to 1.21rc1, we noticed the
MobileFrontend (at master) was throwing a fatal error. I mentioned it in
#wikimedia-mobile and Ori found that it depends on a core change that was
only merged recently (https://gerrit.wikimedia.org/r/#/c/49071/).
Since MobileFrontend is considered to be stable, it would be nice if there
was a REL1_21 branch so that we could get the features that have been
introduced since REL1_20 was branched, and that don't require 1.22.
Thanks!
-- Legoktm
http://enwp.org/User:Legoktm