Total number of views for a given pages seems like a reasonable addition to PageViewService.

Change 511006 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/PageViewInfo@master] [WIP] Add page totals

https://gerrit.wikimedia.org/r/511006

Change 511006 abandoned by Gergő Tisza:
[WIP] Add page totals

Reason:
Turns out this is not really useful for T220143 which needs pageview totals from a given day (the time the user first edited the page). That is a bad caching target so it requires a different approach.

Can be resurrected if there is a product need.

https://gerrit.wikimedia.org/r/511006

Moving to Triaged but Future -- if someone submits a patch we will happily review it, otherwise @MMiller_WMF if you want to prioritize this for an upcoming quarter please move it to a different column.

The (non-final, I think) mock for T313310: Impact module: Implement table list component includes a "past year" and "all time" option. The pageviews API can send data in daily or monthly increments, going back to about 2016 (it has data from 2015 July, not sure if it's reliable early on), with a different API serving 2008-2016 data. So "all time" will be since 2008 at best, since 2016 if we don't use the legacy API.

In T220143#8122476, @Tgr wrote:

The (non-final, I think) mock for T313310: Impact module: Implement table list component includes a "past year" and "all time" option. The pageviews API can send data in daily or monthly increments, going back to about 2016 (it has data from 2015 July, not sure if it's reliable early on), with a different API serving 2008-2016 data. So "all time" will be since 2008 at best, since 2016 if we don't use the legacy API.

@KieranMcCann is working on revised mocks for the Impact Module, so he'll keep this limitation in mind. The current mockups include filtering by:

• Past 30 days (new default)
• Past 60 days (existing)
• Past year
• All time

Open questions for product & design & anyone else who wants to chime in:

• Based on "All time" not being possible (and presumably rather data intensive to include even back to 2008). Should we simply remove that option?
• Is "Past 60 days" the right option, or was it chosen mainly because that's the current default? Should we consider a different increment of time?

Here are the design mocks showing the ability to configure the statistics timeframe...

The one data visualisation challenge is the yearly view of the ‘Your recent activity’ bar chart. In the image above I’ve included some exploration of this. The options I’ve visualised are:

• One bar = 1 week
• One bar = 1 month
• One bar = 2 days (this requires removing the gap between the bars)

My personal preference is for the one bar = 1 month option. Although we lose fidelity in this option I think it is the most readable of the options and provides the most value as a visualisation.

For the moment I’ve not explored the ‘All time’ option as I think this would be challenging to visualise whilst still providing a useful level of detail. If we did want to pursue this further then my suggestions would be to remove the charts and just include the number stats.

In T220143#8177406, @KieranMcCann wrote:

Here are the design mocks showing the ability to configure the statistics timeframe...

The one data visualisation challenge is the yearly view of the ‘Your recent activity’ bar chart. In the image above I’ve included some exploration of this. The options I’ve visualised are:

• One bar = 1 week
• One bar = 1 month
• One bar = 2 days (this requires removing the gap between the bars)

My personal preference is for the one bar = 1 month option. Although we lose fidelity in this option I think it is the most readable of the options and provides the most value as a visualisation.

For the moment I’ve not explored the ‘All time’ option as I think this would be challenging to visualise whilst still providing a useful level of detail. If we did want to pursue this further then my suggestions would be to remove the charts and just include the number stats.

Thank you for this.

@KStoller-WMF, one thing we could consider is splitting out the configurability of this into a separate task, and release initially with a hard-coded default of 30 days.