Needs more discussion about the priority of Year in review.

Can we consider this a timeboxed (1-2 points) research spike?

DPE is planning to work on more contributor metrics (for Year in Review and the Impact Module) and we simply want to answer the question: will their recent work actually work for Special:Impact?

Change #1260014 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/GrowthExperiments@master] Compare Impact pageviews to Wikimedia analytics

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

Impact module displays page views based on edit history on the target wiki. All AQS endpoints that could be relevant to use in Growth's impact module lack some sort of filtering or parameters in the request spec to fit the current module outcome. The next section elaborates on this highlighting the problems on each endpoint

Pageviews

List most-viewed pages for an editor's edited pages

GET /pageviews/v3/top_pages_per_editor/{user_central_id}/{granularity}/{start}/{end}

Response excerpt:

"items": [
    {
      "timestamp": "2025-11-01T00:00:00.000Z",
      "top_k": 10,
      "rank_items": [
        {
          "rank": 1,
          "wiki_id": "labswiki",
          "page_id": 4108,
          "view_count": 11882
        },
        {
          "rank": 2,
          "wiki_id": "testwiki",
          "page_id": 127601,
          "view_count": 648
        },
        {
          "rank": 3,
          "wiki_id": "mediawikiwiki",
          "page_id": 1294743,
          "view_count": 222
        },
...

This endpoint aggregates page views for edits made in all wikis rather than on a single wiki, there's no {project} parameter in the endpoint path. The response contains the wiki_id so it is possible to filter the views by the relevant wiki. It also returns the page_ids so the titles could be printed. However, the granularity param can only be set to monthly. In my tests, the endpoint wouldn't return any fresh data for the last 60 days. Run with end=20260514 I had to set the start to 9 months earlier to start getting results, start=20250914. Is this expected? Maybe @Dbrant as someone who's worked before with this API knows more about it. Ideally we'd also benefit from having {project} filtering there, and daily granularity, but these are no blockers.

Question 1: is it expected to not have data calculated from the last 9 months?
Question 2: can daily granularity be added in this endpoint?
Question 2: can project filtering be added in this endpoint?

Get number of page views for an editor's edited pages

GET /pageviews/v3/per_editor/{user_central_id}/{granularity}/{start}/{end}

Response excerpt:

...
"items": [
    {
      "timestamp": "2026-03-16T00:00:00.000Z",
      "view_count": 397
    },
    {
      "timestamp": "2026-03-17T00:00:00.000Z",
      "view_count": 1381
    },
    {
      "timestamp": "2026-03-18T00:00:00.000Z",
      "view_count": 243
    },
...

As opposed to the prior endpoint, this endpoint has daily granularity and returns fresh data. However it lacks returning wiki_ids for the edited pages or having {project} filtering capability. It can't neither be used to build the list of top viewed edited pages. The prior endpoint seems more relevant as it handles already the view ranking logic but this was worth exploring in case we could compute the ranking from it.

Get number of page views for a page

GET /pageviews/per-article/{project}/{access}/{agent}/{article}/{granularity}/{start}/{end}

This endpoint has the {project} filter on its path and would be convenient for getting the number of page views displayed alongside every top viewed article. Based on an already computed list of articles, it can be used to get the pageviews for each. However it seems like a dog/tail problem, for computing the ranked list, a request to this endpoint for each article edited by the user should be run. Not ideal, but may be an optimization worth considering, see more in conclusions.

Edits

I also looked into the edits API to see if it could fit Impact's streak section Your recent activity (last 60 days)

Get number of edits made by an editor

GET /edits/v3/per_editor/{user_central_id}/{page_type}/{granularity}/{start}/{end}

Response excerpt:

"items": [
    {
      "timestamp": "2026-04-01T00:00:00.000Z",
      "edit_count": 1
    },
...

Once again, the aggregation is for all wiki projects and no {project} filter is provided or wiki_ids returned. This could be fair to show (more of a product/design decision), but is not how currently impact module works. It only shows edits in the visited wiki.

Conclusions

It doesn't seem possible to fully move the impact module data retrieval from the existing API to AQS API until we figure out the freshness issue with the top_pages_per_editor endpoint. If that endpoint is not usable for computing the ranked list of articles the per_editor endpoint can't be used as fallback because it lacks both {project} and/or wiki_ids on its response.

Currently, the only (micro) optimization that could be done is using the Get number of page views for a page endpoint instead of the current query-driven approach. If done in the client it could also save some bits of storage in the growthexperiments_user_impact table. However the saving would only be in terms of data storing, in terms of querying, the same queries would still be necessary to compute the view-ranked list of articles. This opportunity is much smaller, and (imo) almost not worth. cc @KStoller-WMF

Who should we talk to know more about the Pageviews/Edits AQS API limitations and how difficult is to improve/expand this endpoints? cc @DMburugu

In terms of rate limits I only found https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/documentation/access-policy.html#rate-limits which states there's no fixed limit. Seems strange, there's always a limit to requests but seems we don't need to care about it at this point.

Hey @GGoncalves-WMF and @Ahoelzl, we just did an analysis on whether the pageview and edits APIs that DPE provided could be replace the current ones on the Impact Module and it might be useful to share these with your team and get their feedback on our findings.

Hi, thanks for the detailed analysis and I'm asking the team about the data gap in top_pages_per_editor.

Let me see if I understand the use case, referencing the green boxes from this ticket.

Looks like you'd implement "Views on articles you've edited" by calling top_pages_per_editor for the last 60 days, with daily granularity, and adding up the pageviews.

For "Most viewed (since your edit)", I'm not sure how you'd do the "since your edit" part. I think top_pages_per_editor doesn't do that kind of filtering. The documentation says:

The list of pages for which pageview counts are summed is the list of pages ever edited by the user on the resulting timeseries date.

So I guess the workaround would be like:

• Find the pages edited by the user in the last 60 days, and the edit dates.
• For each page, call /pageviews/ starting at the date of the user's edit to get the pageviews count.
• Compute the page ranking locally.

Does that sound about right?

A couple of follow-up questions about your requirements please:

• Do you have an estimate for the volume of traffic we'd be receiving?
• What are the expectations for data freshness? It sounds like you're ideally looking for daily granularity and freshness, is that right?
• What are the expectations for query latency? What happens if an API request takes, say, 200ms?
• What are the expectations for availability of the API? What happens if AQS is down?

Question 1: is it expected to not have data calculated from the last 9 months?

No, this is not expected. This is a problem. Data should be present shortly after the the first day of each month. Looking into it...

FWIW, the data exists correctly in the Hive table wmf_readership.pageviews_top_pages_per_editor. I don't yet know why the API is returning empty data.

Question 2[3]: can project filtering be added in this endpoint?

Probably, but because top_k is not an additive metric, it means that we have to precompute everything separately. I don't think precomputing project would explode data size too much, but we'd have to do some more napkin math to be sure(r). :)

Question 2: can daily granularity be added in this endpoint?

It may be possible, but the size of the data might be too large. We never really considered aggregating at finer granularities, but the data model would support it if we can store it.

From Design_Review/Global_Editor_Metrics_2025#Dataset:_pageviews_top_pages_per_editor

As of 2025-11, we only intend to store monthly aggregations. By including granularity as a field, we keep ourselves open to storing e.g. yearly aggregations in the future.

[...]

We had considered storing pageviews per page per user daily in one table to serve both aggregate pageviews and top k pages viewed per metrics, but after initial data sizing estimations, we decided that this data would be large and it would not be worth storing all if it just to serve the top k use case. See https://phabricator.wikimedia.org/T401260#11230961 for more details. After doing some real data sizing, this may be possible to store, but would require more platform support (e.g. aggregations in Data Gateway). It was decided that the product didn't really need this flexibility, so we are going with monthly precomputations.

edits per editor

Once again, the aggregation is for all wiki projects and no {project} filter is provided or wiki_ids returned

https://wikitech.wikimedia.org/wiki/SRE/Data_Persistence/Design_Review/Global_Editor_Metrics_2025#Dataset:_mediawiki_history_reduced

I think project/wiki_id could be added very easily. It would only be AQS code query changes. No new data computation needed.

I'm not quite sure we didn't add it in the API to begin with, except that I suppose it wasn't requested!

Filed T426426: AQS pageviews/v3/top_pages_per_editor not returning data to investigate missing top pageviews per editor data.

Looks like you'd implement "Views on articles you've edited" by calling top_pages_per_editor for the last 60 days, with daily granularity, and adding up the pageviews.

To be clear, what the current implementation of the UserImpact module does is that it looks at the last 1000 (or more if it would be possible) edits the user makes, extracts the set of edited articles from that, and the timestamps when these were first edited with in that set of 1000 edits, and then sums up the page views starting from that timestamp (but no older than the last 60 days).

Filed T426426: AQS pageviews/v3/top_pages_per_editor not returning data to investigate missing top pageviews per editor data.

BTW! Looks like they fixed this! It was a misconfiguration that was loading the data to staging!

In T414020#11924959, @GGoncalves-WMF wrote:

So I guess the workaround would be like:

• Find the pages edited by the user in the last 60 days, and the edit dates.
• For each page, call /pageviews/ starting at the date of the user's edit to get the pageviews count.
• Compute the page ranking locally.

Does that sound about right?

This sounds like it would work. There's an important question to clarify, what is the meaning of locally here, but that's probably a separate conversation. If we need to do an ad-hoc data aggregation for honoring the since you edited premise, we'd probably want to cache it somewhere, be it DB table like currently happens or in some client/device storage. Otoh if product/design would be fine loosening the premise to something like pageviews in the last 60 days in an article you've edited sometime in the last 60 days we could avoid having custom aggregations for this module. cc @KStoller-WMF

A couple of follow-up questions about your requirements please:

• Do you have an estimate for the volume of traffic we'd be receiving?

This is tricky to answer because it depends on the design we decide to go for the ImpactV2. In the current Impact implementation the module is shown only in the homepage but the traffic of that page does not directly map to a single request or several. The current module is backed by a layer of cache (a mysql table growthexperiments_user_impact). This table is populated, updated and cleaned via a maintenance scripts ( eg: refreshUserImpactData) that run daily. The number of users for which this is done is limited by a defined impact cohort. With the current implementation the majority of requests come from these scripts. Additionally, cached records are created/updated when a user in the cohort edits. And finally also if someone visits Special/Impact:<username> and the impact data for that user wasn't cached or is out of date.

TL;DR: Depends if we keep having a caching layer for the module or completely rely on AQS. We would need to do some math to get an approximate N of requests, but with current status quo I'd say the main take away is: medium-high traffic during script execution, low based on site traffic.

• What are the expectations for data freshness? It sounds like you're ideally looking for daily granularity and freshness, is that right?

Ideally yes since this is already the user expectation, the module informs users to comeback after 24h to see an updated number of pageviews for a recent edited article.

• What are the expectations for query latency? What happens if an API request takes, say, 200ms?

I'd say 200ms latency is ok as this is requests are always happening in the background and should not impact page response time.

• What are the expectations for availability of the API? What happens if AQS is down?

With the current design we'd had cached data for a substantial amount of the impact data requests so if AQS is down we should be able to serve some data. For not cached impacts we wouldn't be able to display anything but that's fair. If apis are down during script runs we should have some signal/alert and decide if it's worth to take some remedy action like refreshing the data manually.

Re granularity

In T414020#11925837, @Ottomata wrote:

Question 2: can daily granularity be added in this endpoint?

It may be possible, but the size of the data might be too large. We never really considered aggregating at finer granularities, but the data model would support it if we can store it.

From Design_Review/Global_Editor_Metrics_2025#Dataset:_pageviews_top_pages_per_editor

As of 2025-11, we only intend to store monthly aggregations. By including granularity as a field, we keep ourselves open to storing e.g. yearly aggregations in the future.

[...]

We had considered storing pageviews per page per user daily in one table to serve both aggregate pageviews and top k pages viewed per metrics, but after initial data sizing estimations, we decided that this data would be large and it would not be worth storing all if it just to serve the top k use case. See https://phabricator.wikimedia.org/T401260#11230961 for more details. After doing some real data sizing, this may be possible to store, but would require more platform support (e.g. aggregations in Data Gateway). It was decided that the product didn't really need this flexibility, so we are going with monthly precomputations.

Thanks for the context. It seems one of this situations where the value and impact of the feature needs to be very well justified to dedicate specific larger resources. Otoh there's already aggregation/caching machinery built around Impact module that could be used to fill the gaps in the AQS apis. cc @KStoller-WMF

edits per editor

Once again, the aggregation is for all wiki projects and no {project} filter is provided or wiki_ids returned

https://wikitech.wikimedia.org/wiki/SRE/Data_Persistence/Design_Review/Global_Editor_Metrics_2025#Dataset:_mediawiki_history_reduced

I think project/wiki_id could be added very easily. It would only be AQS code query changes. No new data computation needed.

I'm not quite sure we didn't add it in the API to begin with, except that I suppose it wasn't requested!

It seems to me that this is the most low hanging fruit from all the cases mentioned here.

Thank you all for the great context here! The purpose of this task was to get a better understanding of what's currently possible to migrate from Impact implementation to AQS calls and we have a lot of valuable information already. The future of the Impact module is probably moving towards its own extension, so before requesting official changes improvements in the AQS endpoints, Growth engineers need to discuss internally about the design and next steps for it.

Change #1260014 abandoned by Michael Große:

[mediawiki/extensions/GrowthExperiments@master] Compare Impact pageviews to Wikimedia analytics

Reason:

This change served its purpose and we closed the related investigation. Thank you! Abandoning it now as it was never intended to be merged.

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