The purpose of this page is to gather all the different documents, discussions and ideas related to Mobile Analytics and to define a list with the *most* important metrics. Please feel free to add any missing data, this document is almost certain to be incomplete.
Mobile Page Views
Phil Chang is the point of contact for this reporting.
First Priority -- A breakdown of mobile page views from more sources than currently being tracked in Erik Z's report. The most meaningful breakdown:
- Total mobile page views, per Wikipedia, subdivided into 8 raw numbers:
- Mobile website singapore(3 numbers)
- From browser
- Apps using Safari WebKit screen-scraping
- Official apps (2 numbers currently)
- Official iOS
- Official Android
- Desktop site page views from mobile device (1 number)
- API (2 numbers)
- MediaWiki API
- Mobile Frontend API (eventually part of MW API), does not include screen scraping of mobile site
Notes on the above:
- Page views on zero.wikipedia.org should be included in mobile frontend
- Official WindowsMobile and Java apps will be added in Q2 2012; Reporting should be flexible to include that
- 1+2+3 should be the total number of mobile page views that we communicate and rally behind as an organization
- 4 may take add'l time to analyze and convert into page views; this should not delay the urgency of getting 1+2+3
- We'd ultimately like to see this analysis in the same way as stats.wikimedia; until then, would like to see the data monthly in whatever friendly format can be done
Second priority - Page Views by country
- Goal: Report of mobile page views by country on a monthly basis; similar to the overall page view by country report, but also in a way we can see month-to-month trend
- The aggregate page view number should equal the total outlined in "first priority" above
- Would like to put on the roadmap that we can get the same subdivided breakdown outlined in "first priority" on per country basis
- Status: Nimish will be running ad hoc reporting for mobile page views by country on monthly basis beginning Feb 2012; need to transition this to the analytics team and work towards automation
Third priority - Trending articles by country
- Fort each of countries in "second priority", would like a report of top 50 articles with the most page views over a 30-day period
- The page views on which the ranking is based do not necessarily have to be restricted to mobile page views -- hence, this is not a mobile analysis per se, but its application will be mostly in mobile
- Once developed this data will be put into an RSS feed (Max will develop) that can be integrated into mobile portals
Partner Page Views
Kul Wadhwa and Dan Foy are the contacts for this reporting.
First Priority - Page views from operator partners that are providing Wikipedia without data charges. This is extremely high priority, and we need to be able to report on this as each partner launches (beginning in March 2012). Additional details:
- Partners will be providing us with IP address range; this can be used as the identifier by which to create report (IP list is located here
- We anticipate around 10 operators by end of July; 30 by end of 2012
- Would need the report on a monthly basis; report cannot be on a public (non-password) url. Note that new operators will be added to the report each month.
- Page views is the only metric required; Report can ideally report two numbers per language wiki for each operator:
- Page views to *.m.wikipedia.org sites
- Page views to *.zero.wikipedia.org sites (note a third url of *.xx.wikipedia.org may be implemented later)
Second Priority - Page views from link referrals. Operators are beginning to place links to Wikipedia in their portals to help us generate traffic in new markets. We would need a system in which we can both measure and report the amount of page views generated from sessions originating in these links:
- Looking to analytics team for best solution, wondering if it is an option to append a tracking id to the url the operator puts on their site, such as http://en.wikipedia.org/wiki/Main_Page/?trackingid=12345
- Need a mechanism by which we generate and log these tracking IDs
- Need to address question of if the tracking ID would stick with the user throughout the session
- Need reporting on these IDs on a monthly basis
- Note the difference between this and "first priority" is that this is to measure impact of specific integration rather than overall impact of a partnership
- Once this is scoped, Amit will work with legal to ensure we can do this under our user agreement
Third Priority - Reporting analysis of external clicks on free Wikipedia programs. Background -- when operators are providing Wikipedia for free, we serve their users a banner (based on IP) that says "free access by Operator". Whenever the user clicks on an external link or an image in the case of Wikipedia Zero, the banner renders a message that says "Data Charges May Apply. Continue? Yes/No".
- For each operator that we report on in "first priority" above (note: we will have their IP addresses), we need two metrics reported:
- 1) Number of times this message ("Data Charges May Apply...") is shown.
- 2) Number of times that "Yes" is clicked.
- Would need this on a monthly basis, reported at same time of the "first priority" report.
Device and Content Partners
First (and only) Priority - Page views generated from content partners and device manufacturers who have integrated Wikipedia using API. Note this is different from third party app developers.
- There is documentation on identifying user agents but there is no mechanism by which we report on them.
- There are several big partners (some with official agreements in place) that utilize this form of integration including Sony, TripAdvisor, Asus. We would like to even implement this with Apple so we can see the impact of default search on the iphone
- It is important to understand how much these integrations are used so we can make decisions on the type of priority and investment we put towards them. So the needs are:
- A structure that we can give to these partners (including mostly those who have already launched) on exactly what they should name their user agents
- A place we can collect these user agents, and report on page views from them on a monthly basis
Mobile Unique Visitors
This is all Diederik.
First (and only, but huge) Priority - We rely on comscore currently for UV measurement, which is our most trumpeted figure in terms of Wikipedia's reach. We have a huge issue, though, in that Comscore does not provide us with Mobile UVs. Much effort is being made so that many of our new readers from the Global South will be accessing on mobile only, so our UV count will not be growing at the rate we expect without including mobile. This also means our current number (roughly 470 million) is an underestimation of our current reach. We have set a public target of 1 billion Unique Visitors by 2015, so it is crucial we get some measure of mobile UVs now. Some notes:
- Best thing we can do now is get this from Comscore, under the current scope. Kul/Amit/Barry can help make the case if add'l, but reasonable, cost cannot be avoided.
- We should be building capacity for our own measures of UVs, including mobile. "1 Billion by 2015" is going to be an increasingly visible goal, and we should be the ones to have a grip on it.
- For add'l consideration -- we will soon be implementing programs for Wikipedia access by SMS, so need to be thinking about how/if that usage can be measured as UV equivalent.
Data Sources and Data Formats
Some mobile analytics data are shown at Analytics/Pageviews/Mobile/Results
- Ad hoc statistics related to mobile usage on Wikipedia:
- Of the top 1000 articles viewed from mobile devices in Singapore (based on Feb 2012), 422 were articles from the main (non-mobile) site
- 450 articles make up 10% of all page views on mobile, while 630 articles make up 10% on non-mobile. Also based on India Feb 2012 data.
- 3.7% of page views to the mobile site come from non-mobile browsers (from Andre, Mar 5, 2012)
- This needs to be added to the summary report
- Breakdown of mobile browsers by user agents that *do not* go to the mobile site