While those are worthwhile feature requests, we should talk about those separately from this project. This project is solely for visualization of the existing data, with the existing methods for querying it. I'll post Danny's initial post now that we're on the public list:
[From: Danny Horn] Hi everyone,
I'd like to talk about the Pageview stats tool that I think everyone on this email is planning to work on. :)
For the Community Tech team, this was voted as wish #7 on the Community Wishlist Survey, so we've been talking to Leila and Marcel about what we wanted to build.
I also saw on the Phabricator ticket that Jan has some students working with WMSE who are interested in working on the project too, and Dan (Millimetric) offered to help.
So we ought to talk, and figure out what we'd like to do. I'd be happy for our team to help support the students' work, if that's the best way to get something built.
My question is: How are we going to define the requirements for the tool? I was planning to get some community input on defining which stats would help contributors the most. What do you think?
On Fri, Jan 15, 2016 at 2:44 PM, Felix J. Scholz <felixjacobscholz@gmail.com
wrote:
I think it would be interesting to be able to search for articles by views while retaining the existing qualifiers.
An example query might be: List articles with 500 - 750 views during the time of 12/15/2015 and 12/17/2015 (or maybe, if that is easier, just one day), only real users (no bots / spiders) accessing from mobile devices.
The data is already there, it is just a different way of accessing it.
While it is currently already possible to do this, if one wants to crawl a whole project, you need millions of API requests (at least for the bigger wikipedias like en or de and whatnot).
Best, Felix
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail This email has been sent from a virus-free computer protected by Avast. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#328807949_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Jan 15, 2016 at 2:31 PM, Oliver Keyes okeyes@wikimedia.org wrote:
Those sound like relatively advanced features a bit beyond the initial offering, but like useful things to provide in the long-term, yeah. I'm not sure what the status of the redirects inclusion (which is sort of a question about the underlying data source rather than the endpoint) is.
On 15 January 2016 at 11:28, Alex Druk alex.druk@gmail.com wrote:
Hi all,
My two cents to discussion about endpoints to pageview API:
- stats for categories that include all subcats and all pages,
- include redirects to article counts
All the best,
On Fri, Jan 15, 2016 at 6:05 PM, Nuria Ruiz nuria@wikimedia.org
wrote:
Trying again, adding analytics@ (public e-mail list)
On Fri, Jan 15, 2016 at 5:22 AM, Marcel Ruiz Forns <
mforns@wikimedia.org>
wrote:
I also think we should start with exposing the 3 api's endpoints in a GUI, which - as Dan says - we know respond to community interests.
And then
ask the community for more input, that could mean improvements to the
tool,
new endpoints or completely new ideas...
On Thu, Jan 14, 2016 at 10:45 PM, Dan Andreescu dandreescu@wikimedia.org wrote:
I'm ok if people want to take an iterative approach, I just want to point out that the usage information is not very indicative of value
at this
point. The API is not widely used and the per-article endpoint is
expected
to be hit much much more than per-project or top simply because the
queries
are many orders of magnitude more granular. So we can't really judge importance from that comparison.
On Thu, Jan 14, 2016 at 4:43 PM, Leila Zia leila@wikimedia.org
wrote:
> > > On Thu, Jan 14, 2016 at 1:09 PM, Dan Andreescu > dandreescu@wikimedia.org wrote: >>> >>> My question is: How are we going to define the requirements for
the
>>> tool? I was planning to get some community input on defining
which stats
>>> would help contributors the most. What do you think? >> >> >> My opinion here is that we should just expose everything the
pageview
>> API is capable of. It's only 3 different end points and they were
chosen
>> based on what the community found useful. As we add more
endpoints we can
>> keep checking if visualization is important. But of course if
others have
>> other more specific plans, we can wait for those tools to be built
and
>> iterate. > > > Building up on Dan's suggestion: I'd go with communicating and/or > discussing the following with the community: > > * the 3 different metrics we can offer a UI for > * what other metrics they find useful for their work. This will
help us
> collect information about what other kind of metrics we should
offer as an
> end-point if we decide to add to the end-points (pageview per
article by
> country has come up many times, for example) > * whether they consider the wish as satisfied if we offer a UI for
the
> 3 different metrics, and perhaps over time add more metrics to the
UI as
> they become available (not necessarily in 2016). > > Leila > >
-- Marcel Ruiz Forns Analytics Developer Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Thank you.
Alex Druk, PhD wikipediatrends.com alex.druk@gmail.com (775) 237-8550 Google voice
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Oliver Keyes Count Logula Wikimedia Foundation
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