This is a follow-up to @Sgs's work from T414020: Impact Module: Investigate using Wikimedia Analytics API. The goal of this task is to create a table that shows for every metric offered by GrowthExperiments-ImpactModule (determined as visible by the end user at Special:Impact):
- the name of the metric,
- definition of what it means,
- link to a Wikimedia Analytics API that can compute it (if it exists),
- a proposed decision whether that metric would be included in the MVP of the new Impact module.
This would be the basis to start migrating Impact module metrics to their new home.
Result
Current metrics
| Metric name | Definition | Current technical limitations (*) |
| Editcount | Value of user_editcount | None |
| Thanks received | Number of thanks received via Thanks | Capped to 1,000 thanks |
| Last edit | Relative timestamp of the user's last edit in any namespace | None |
| Longest streak | Longest editing streak of the user | Only evaluated on the last 1,000 edits |
| Edit histogram | Histogram of edits in the last 60 days | Only evaluated on the last 1,000 edits |
| Total views on articles edited | Total number of pageviews from last 60 days on articles the user edited | Only evaluated on the last 1,000 edits |
| Histogram of pageviews | Per-day number of pageviews the user edited in the last 60 days | Only evaluated on the last 1,000 edits |
| Most 5 viewed articles | Top 5 articles with the most visits (from articles the user edited in the last 60 days) | Only evaluated on the last 1,000 edits |
(*) Technical limitations describe current behaviour of Special:Impact. Those limitations should be lifted if possible.
Available data sources
| No | Name | Provider (AQS / MW) | Notes/Limitations |
| 1 | Total editcount | MW | Also available as CentralAuthEditCounter::getCount() for global data access; sufficiently trivial to call |
| 2 | Last edit timestamp | MW | UserEditTracker::getLatestEditTimestamp() should be computationally trivial (similar to an AQS call); no global equivalent |
| 3 | Thanks received/given | MW | Fairly complex query, likely should be moved to AQS if we want to keep it |
| 4 | Edit count per day | AQS | Global-only as of now; per-wiki filter should be trivial to add (T414020#11925837) |
| 5 | Page views for top-viewed articles | AQS | Global only as-of now; project filter is likely to be addable "if napkin math allows" (T414020#11925837); displays data only after the month is complete (getting daily data "might not be possible") |
| 6 | Page views for user | AQS | Global-only as of now; uncertain if we can add filtering by project |
Possible paths forward
To be finished global description
Option A: Global module
The global module would include data computed across all Wikimedia projects (resulting in exactly the same data regardless of the project the impact module would be viewed from).
| Can be included? | Metric name | Definition | Notes/justification |
| ✅ | Editcount | Value of user_editcount | Available in data source no 1 |
| 🚫 | Thanks received | Number of thanks received via Thanks | Computation via MW is possible, but likely over the "AQS threshold" (see open questions) |
| 🚫 | Last edit | Relative timestamp of the user's last edit in any namespace | Global data is unavailable both in MW and in AQS |
| ✅ | Longest streak | Longest editing streak of the user | ComputeEditingStreaks::getLongestEditingStreak can be applied to data source no 4 |
| ✅ | Edit histogram | Histogram of edits in the last 60 days | Available in data source no 4 |
| ✅ | Total views on articles edited | Total number of pageviews from last 60 days on articles the user edited | Available from data source 6 (sum of the row below) |
| ✅ | Histogram of pageviews | Histogram of articles the user edited in the past 60 days | Available as data source 6 |
| ✅ ⚠ | Most 5 viewed articles | Top 5 most viewed articles on any project (updated monthly) | Available as data source 5 |
Option B: Local module
The local module would include data computed for the specific Wikimedia project (resulting in different impact modules for each project it is viewed from).
| Can be included? | Metric name | Definition | Notes/justification |
| ✅ | Editcount | Value of user_editcount | Available in data source no 1 |
| 🚫 | Thanks received | Number of thanks received via Thanks | Computation via MW is possible, but likely over the "AQS threshold" (see open questions) |
| ✅ | Last edit | Relative timestamp of the user's last edit in any namespace | Available in data source 2 |
| With DPE support | Longest streak | Longest editing streak of the user | Per-project filtering needs to be added by DPE to data source no 4; then ComputeEditingStreaks::getLongestEditingStreak can be applied |
| With DPE support | Edit histogram | Histogram of edits in the last 60 days | Per-project filtering needs to be added by DPE to data source no 4 |
| With DPE support | Total views on articles edited | Total number of pageviews from last 60 days on articles the user edited | Sum of the row below (possibility of per-project data was not confirmed yet) |
| With DPE support | Histogram of pageviews | Histogram of articles the user edited in the past 60 days | Per-project filtering needs to be added by DPE to data source no 6 (possibility of this was not confirmed yet) |
| With DPE support ⚠ | Most 5 viewed articles | Top 5 viewed articles the user edited on that project (updated monthly) | Per-project filtering needs to be added by DPE to data source no 5 |
Open questions
For DPE
All of those questions will be answered via T433983: Make the AQS endpoints more usable for the ImpactModule extension and its subtasks.
- Is it possible to add Thanks data into AQS?
- Is it reasonable to add filtering-by-project to the per-user page views dataset in AQS?
- Can we compute Page views for top-viewed articles for the last floating month rather than for the last calendar month? Does this depend on whether project filtering is available?
For Growth
- (PM) Would Product & Design (in Growth) be OK with having a global-only Impact module?
- Answer: No, we want local stats.
- (Engineers) In the new Impact module, should non-AQS data lookups be allowed? If so, to what extent?
- One of the benefits is to remove the internal DB caching layer, which is unnecessarily complicated. "Challenging" lookups should definitely be in AQS. But what puts us to the level of "challenging"?
- Would it be reasonable to read user_editcount from DB? CentralAuth's "global user editcount"? Number of Thanks received?
- Split to T434222: Decide to what extent should non-AQS data lookups be allowed in ImpactModule