Problem: To be notified when an article has an unusual spike in page views/traffic. This usually indicates there has been an external news story or event driving traffic to Wikipedia, typically signaling the article needs updating with new information/sources.
Who would benefit: Anyone keeping an article up to date
Proposed solution: Integrate Pageview API data into the watchlist
More comments: Spikes in traffic are normal and are usually short-lived (1 day spires see example graphs) These can be safely ignored. However when there is a sustained build-up and trailing off, looking more like a mountain than a spire, this can be determined to be a probable external event driving traffic to the article.
Phabricator tickets: A similar ideas was proposed at T168527 though based on page view rankings to help editors discover articles needing attention. Such a system could also include data about velocity of ranking changes.
Pageviews normally lag behind (by a day) so this would probably miss any one day spikes, and on enwiki there is already a tool that displays the last 30 days of pageviews at the top of the page when you look at it. (you can enable it in gadgets, its labeled as xtools). and of course there is the pageviews tool itself to look at an article history, and various lists which are bot updated, which display the "most popular start class articles" and most popular articles, even some most popular articles by project. But this could be useful in addition to all these things as a more personalized list. A Den Jentyl Ettien Avel Dysklyver (talk) 15:25, 9 November 2017 (UTC)Reply[reply]
Yeah I was thinking of an algorithm that would crunch data over the prior 7 or 14 days to determine there is unusual traffic pattern and visually it adds a small flag in the watchlist, which might then link to a graph (or not). But the system could be smart to notify users of unusual traffic patterns. -- GreenC (talk) 16:02, 9 November 2017 (UTC)Reply[reply]
@GreenC: I like the idea, but I'm not sure if the proposal as currently written would solve your needs. I suggest more editing of the proposal, to clarify. -- There are 2 components to the request: (1) some new code that can identify "pageview spikes", and (2) a way to tell interested people (readers/editors/watchlisters/etc) about any recent spike. For (2), if the method was to display that info inside the Special:Watchlist page, then we would not be able to see if there was a pageview spike unless there was also recent editing activity. -- For (imperfect) example, I saw this youtube video (a comedy show that picks 1 or more Wikipedia articles, and asks the guests to guess at interesting facts within) which was uploaded on June 8 and mentioned w:en:Lyall's wren (history, pageviews for 1 year) (I don't know where the July pageview spike came from); In that case, there were a few page edits that coincided with the two major pageview spikes, but there might not have been. -- I suspect (IANAD) that it would be best to simply make this proposal about component #1, and then [if that's feasible and voted on and] once we have the info available, it could easily be displayed wherever desired via gadgets and such. Quiddity (WMF) (talk) 01:19, 18 November 2017 (UTC)Reply[reply]
Quiddity (WMF), excellent point you are right about separating the work. (With the survey closing in less than 24hrs it might be too late to start a new proposal..) Well maybe next year unless someone wants to take it on independently. -- GreenC (talk) 21:09, 18 November 2017 (UTC)Reply[reply]
@GreenC: Only the proposals phase closes in 24 hours! Then there's a week to further refine the proposals, and then the voting begins on the 27th. Please do overhaul/update the proposal above, however would be beneficial. We want the proposals to be both clear/concise to everyone, and practical/feasible, when the voting begins and the deluge of visitors (who have ~230 proposals to read!) arrive. :) Quiddity (WMF) (talk) 17:18, 19 November 2017 (UTC)Reply[reply]