Change Details

#####Background In 2024-2025 the iOS team built a personalized Wikipedia Year in Review feature T371946.We had to make tradeoffs in how we did our editing stats, using a mix of the userContributions API and the Growth Impact Module. The Mobile Apps team would like to include editing stats again in 2025's version, and improve how they were displayed and maybe expand what we show to users. Our goal with this spike is to understand what our options are for improving our access to editing statistics in a scalable way. One possibility discussed has been improvements to the Impact Module API, but this SPIKE has been edited to be solution agnostic. ####Relevant Product requirements for 2025 year in Review - [Highest priority] Total edit count for ALL of 2025, but not limited to 500 edits - [Second priority] Views accumulated in 2025 on pages they've edited (edits can be in 2025 or all time) - (Nice to have) # of days that they edited in 2025, with possibility for calculating edit streak - (Nice to have) List of article titles they've edited in 2025 - (Nice to have) Total bytes they've added in 2025 ####Engineering notes - For mobile apps we need the ability to query enough at a scale to cover Android & iOS active accounts holders + sufficient margin to allow for potential growth in response the features release. There will likely be a spike associated with the retreiving of statistics when YiR is released. If folks find out that the Apps feature is doing editing stats, we might get folks downloading the app and logging in just to see it but this tail should be more distributed. - The mobile apps would be making the calls as so there is a need for it to be retrievable via an externally accessible. We would need coordination on type of authentication mechanism. ####Open questions - Are there any changes could be done to the [[https://www.mediawiki.org/wiki/Help:Growth/Tools/Impact_module | Growth Impact Module's statistics]] so that clients could access the following statistics for the current calendar year (instead of last 60 days or past 1000 edits) for the above requirements? Please note if any are substantially easier than others (we don't need to use all of them in year in review!) - Is it possible to include timestamps with the dates in the response? This would be for time-of-day calculations for a slide like "In 2025, you edited most in the evenings", etc. If it's possible to receive a local edit time, that would be good. Otherwise we will just have to assume all edits were made from the device's timezone at the time of slide creation. ####Relevant tasks - {T377235} - {T376353} - For iOS Year in review 2024 , we used the Impact Module API to pull views on edits recently, but we could only access the past 60 days of data. - {T376320} - For displaying total edits in 2024, we used the userContributions API. To mitigate risk, we only called it once per user and got the first 500 edits. Those with more than 500 edits displayed "500+ edits" - {T341599} - The impact module is currently limited to the past 1000 edits, the growth team already has a task for increasing that to 10,000. If this would be useful for YiR, we should inform the growth team and let them know what we need. #####Relevant data 3% of freetext feedback asked for improved editing statistics: - Users got confused when editing stats did not cover the full year (edits viewed coming from Growth Impact Module API T376353) and assumed they are incorrect. - Users want to be reminded of **which** pages they edited - Users are interested to see graphs or lists about their edits - One user wanted specific edit count for year, not "500+ edits" Estimated for a 12-month period, ~95% of iOS editors have fewer than 500 edits, and 99.6% have fewer than 10,000 ([[ https://phabricator.wikimedia.org/T371555#10067792 | source ]]). So solutions that cover the past calendar year (2025), and support up to 1000 edits work for iOS (TBD for Android), and solutions that support up to 10,000 edits and the past calendar year would cover the vast majority of editors.

#####Background In 2024-2025 the iOS team built a personalized Wikipedia Year in Review feature T371946.We had to make tradeoffs in how we did our editing stats, using a mix of the userContributions API and the Growth Impact Module. The Mobile Apps team would like to include editing stats again in 2025's version, and improve how they were displayed and maybe expand what we show to users. Our goal with this spike is to understand what our options are for improving our access to editing statistics in a scalable way. One possibility discussed has been improvements to the Impact Module API, but this SPIKE has been edited to be solution agnostic. ####Wishlist 2025 year in Review - Update frequency: daily, and ability to support a batch request for users at scale in December 2025 - [Highest priority] Total edit count for ALL of 2025, but not limited to 500 edits - [Second priority] Views accumulated in 2025 on pages they've edited (edits can be in 2025 or all time) - (Nice to have) # of days that they edited in 2025, with possibility for calculating edit streak - (Nice to have) List of article titles they've edited in 2025 - (Nice to have) Total bytes they've added in 2025 ####Engineering notes - For mobile apps we need the ability to query enough at a scale to cover Android & iOS active accounts holders + sufficient margin to allow for potential growth in response the features release. There will likely be a spike associated with the retreiving of statistics when YiR is released. If folks find out that the Apps feature is doing editing stats, we might get folks downloading the app and logging in just to see it but this tail should be more distributed. - The mobile apps would be making the calls as so there is a need for it to be retrievable via an externally accessible. We would need coordination on type of authentication mechanism. ####Open questions - Are there any changes could be done to the [[https://www.mediawiki.org/wiki/Help:Growth/Tools/Impact_module | Growth Impact Module's statistics]] so that clients could access the following statistics for the current calendar year (instead of last 60 days or past 1000 edits) for the above requirements? Please note if any are substantially easier than others (we don't need to use all of them in year in review!) - Is it possible to include timestamps with the dates in the response? This would be for time-of-day calculations for a slide like "In 2025, you edited most in the evenings", etc. If it's possible to receive a local edit time, that would be good. Otherwise we will just have to assume all edits were made from the device's timezone at the time of slide creation. ####Relevant tasks - {T377235} - {T376353} - For iOS Year in review 2024 , we used the Impact Module API to pull views on edits recently, but we could only access the past 60 days of data. - {T376320} - For displaying total edits in 2024, we used the userContributions API. To mitigate risk, we only called it once per user and got the first 500 edits. Those with more than 500 edits displayed "500+ edits" - {T341599} - The impact module is currently limited to the past 1000 edits, the growth team already has a task for increasing that to 10,000. If this would be useful for YiR, we should inform the growth team and let them know what we need. #####Relevant data 3% of freetext feedback asked for improved editing statistics: - Users got confused when editing stats did not cover the full year (edits viewed coming from Growth Impact Module API T376353) and assumed they are incorrect. - Users want to be reminded of **which** pages they edited - Users are interested to see graphs or lists about their edits - One user wanted specific edit count for year, not "500+ edits" Estimated for a 12-month period, ~95% of iOS editors have fewer than 500 edits, and 99.6% have fewer than 10,000 ([[ https://phabricator.wikimedia.org/T371555#10067792 | source ]]). So solutions that cover the past calendar year (2025), and support up to 1000 edits work for iOS (TBD for Android), and solutions that support up to 10,000 edits and the past calendar year would cover the vast majority of editors.

#####Background In 2024-2025 the iOS team built a personalized Wikipedia Year in Review feature T371946.We had to make tradeoffs in how we did our editing stats, using a mix of the userContributions API and the Growth Impact Module. The Mobile Apps team would like to include editing stats again in 2025's version, and improve how they were displayed and maybe expand what we show to users. Our goal with this spike is to understand what our options are for improving our access to editing statistics in a scalable way. One possibility discussed has been improvements to the Impact Module API, but this SPIKE has been edited to be solution agnostic. ####Relevant Product requirements forWishlist 2025 year in Review - Update frequency: daily, and ability to support a batch request for users at scale in December 2025 - [Highest priority] Total edit count for ALL of 2025, but not limited to 500 edits - [Second priority] Views accumulated in 2025 on pages they've edited (edits can be in 2025 or all time) - (Nice to have) # of days that they edited in 2025, with possibility for calculating edit streak - (Nice to have) List of article titles they've edited in 2025 - (Nice to have) Total bytes they've added in 2025 ####Engineering notes - For mobile apps we need the ability to query enough at a scale to cover Android & iOS active accounts holders + sufficient margin to allow for potential growth in response the features release. There will likely be a spike associated with the retreiving of statistics when YiR is released. If folks find out that the Apps feature is doing editing stats, we might get folks downloading the app and logging in just to see it but this tail should be more distributed. - The mobile apps would be making the calls as so there is a need for it to be retrievable via an externally accessible. We would need coordination on type of authentication mechanism. ####Open questions - Are there any changes could be done to the [[https://www.mediawiki.org/wiki/Help:Growth/Tools/Impact_module | Growth Impact Module's statistics]] so that clients could access the following statistics for the current calendar year (instead of last 60 days or past 1000 edits) for the above requirements? Please note if any are substantially easier than others (we don't need to use all of them in year in review!) - Is it possible to include timestamps with the dates in the response? This would be for time-of-day calculations for a slide like "In 2025, you edited most in the evenings", etc. If it's possible to receive a local edit time, that would be good. Otherwise we will just have to assume all edits were made from the device's timezone at the time of slide creation. ####Relevant tasks - {T377235} - {T376353} - For iOS Year in review 2024 , we used the Impact Module API to pull views on edits recently, but we could only access the past 60 days of data. - {T376320} - For displaying total edits in 2024, we used the userContributions API. To mitigate risk, we only called it once per user and got the first 500 edits. Those with more than 500 edits displayed "500+ edits" - {T341599} - The impact module is currently limited to the past 1000 edits, the growth team already has a task for increasing that to 10,000. If this would be useful for YiR, we should inform the growth team and let them know what we need. #####Relevant data 3% of freetext feedback asked for improved editing statistics: - Users got confused when editing stats did not cover the full year (edits viewed coming from Growth Impact Module API T376353) and assumed they are incorrect. - Users want to be reminded of **which** pages they edited - Users are interested to see graphs or lists about their edits - One user wanted specific edit count for year, not "500+ edits" Estimated for a 12-month period, ~95% of iOS editors have fewer than 500 edits, and 99.6% have fewer than 10,000 ([[ https://phabricator.wikimedia.org/T371555#10067792 | source ]]). So solutions that cover the past calendar year (2025), and support up to 1000 edits work for iOS (TBD for Android), and solutions that support up to 10,000 edits and the past calendar year would cover the vast majority of editors.