Thanks for correcting me on this, Dan. The scope of the upcoming API is well defined, and not the cure-all that I make it seem to be in my enthusiasm, sorry for causing confusion.
As you say replacing some of the traffic analyses will be separate task, yet to be defined.
- I say 'some' as not all of the reports have found a true user base
- I reckon the primary delivarable might well change from html to machine readable from which anyone can build nice more dynamic reports
From: analytics-bounces@lists.wikimedia.org [mailto:analytics-bounces@lists.wikimedia.org] On Behalf Of Dan Andreescu
Sent: Friday, July 24, 2015 19:08
To: A mailing list for the Analytics Team at WMF and everybody who has an interest in Wikipedia and analytics.
Subject: Re: [Analytics] proposal to axe current traffic reports
I agree with you Erik, but there are some details that need sorting out.
* The Pageview API that we'll deliver by the end of this quarter will not have the more detailed analysis that your traffic reports have (such as referrer stats, browser stats, etc). We should make a separate effort, probably as part of Wikistats 2.0 to cover those gaps.
* The data to power any of these reports is in great shape and is on the hadoop cluster in a neatly pre-aggregated hourly table. We could use that to start replicating these more detailed analyses from Wikistats.
On Fri, Jul 24, 2015 at 12:59 PM, Erik Zachte <erikzachte@infodisiac.com> wrote:
Hi all,
I think the time has come to disable the traffic reports based on webstatscollector (2.0) data.
See http://stats.wikimedia.org/cgi-bin/search_portal.pl?search=breakdown+of+traffic
- These reports are using outdated definitions for page views.
- The scripts haven't seen any maintenance for years.
Even with the new pageview API still in development more and more these reports are misreporting reality anyway.
There was a period were I felt imperfect reports were better than no reports at all, and I warned about unresolved bugs in the report header.
But the anomaly reported below served as a wake-up-call for me that mismatches are intolerably high anyway.
So I propose to put up a notice on the latest reports that those were the last release, and WMF is working to deliver a new infrastructure in the form of a pageview API, ETA later this year.
See also https://phabricator.wikimedia.org/T44259
Whether WMF will also assume responsibility for building new reports on top of that API (and if so in what form) is another matter, but first things first. Current focus is on providing that API, as it should be IMO.
Any thoughts?
Erik Zachte
From: Erik Zachte [mailto:erikzachte@infodisiac.com]
Sent: Friday, July 24, 2015 17:58
To: 'Андрей Лавров'
Subject: RE: Wikimedia Traffic Analysis Report - Operating Systems
Hey Andrey,
You're totally right of course. And not the only to notice. These traffic reports haven't seen much (maintenance) love lately. I'm tempted to disable them. I'm looking forward to the upcoming WMF pageview API as much more promising platform to build better reports: more up to date, more robust, more flexible. Of course there is always a hazard to stop maintaining a solution before a replacement is really there, but this is what actually happened long ago.
Thanks for heads-up.
Erik
From: Андрей Лавров [mailto:andrey.lavrov@wancastle.com]
Sent: Wednesday, July 22, 2015 11:09
To: erikzachte@infodisiac.com
Subject: Wikimedia Traffic Analysis Report - Operating Systems
Dear Erik,
Please, improve your analysis reports by including Chrome OS statistics.
Chrome OS has about 10% market share in US now. Almost all chromebooks are online every day. It is very strange to not see Chrome OS market share in your reports.
Best regards,
Andrey Lavrov
_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics