We discussed this with @AndrewTavis_WMDE today and I quickly looked at some data.
I'll comment on the 3 points in reverse order:

• The 40k number in the wikistats file includes anonymous edits. If you split the data by the Editor Type dimension, you'll see that the number of logged-in editors is not far from the number in Grafana (24k).
• The Grafana and wikistats number being close enough, I would trust them and think that there is an issue with the co-editors computation.

According to this sheet there are 27.634 Wikipedia/Wikidata co-editors. This should be anyone who edited any Wikipedia and Wikidata at least once in 30 days.
According to this grafana board there are 24.600 editors on Wikidata in the same timeframe. This number should be impossible to be lower than the number of co-editors because any Wikipedia/Wikidata co-editor should also be a Wikidata editor.

I don't know what is in this sheet, though I have requested access to it while writing this comment.
At a guess it is an export of https://grafana.wikimedia.org/d/000000560/legacy-wikidata-co-editors?orgId=1&from=now-2y&to=now&timezone=utc ? so I'll run under that assumption in my comment...

Anyway, I generally agree with @JAllemandou that this looks close enough to me for it to all make sense.

If you wanted the numbers to "line up perfectly" you could start generating the active users each month in a similar way to what was done in https://gerrit.wikimedia.org/g/analytics/refinery/source/+/6e5900d61477584b3d258cf6afcf3c57b9e33759/refinery-job/src/main/scala/org/wikimedia/analytics/refinery/job/wikidata/CoEditors.scala making use of the refined events, rather than just recent changes.
You might also consider wanting both metrics, as the RC based metrics give you more "real timey" data.

The numbers are generated in different ways, so it would be entirely possible for them to differ somewhat.
The active editors dashboard looks at recent changes table in sql on the wikidata site.
The co editors dashboard data was generated from the event data in WMF data lake which comes at the end of quite some processing.

Looking at the co-editors query being run, splitting it into parts...
Here is the bit that figures out a list of strings to count as editors of wikidata
(And we need to compare this with https://phabricator.wikimedia.org/diffusion/ADES/browse/master/src/wikidata/site_stats/sql/active_user_changes.sql)

SELECT
  DISTINCT event_user_text
FROM ${params.mwHistoryTable}
WHERE snapshot = '${params.year}-${"%02d".format(params.month)}'
  AND event_entity = 'revision'
  AND event_type = 'create'
  AND wiki_db = 'wikidatawiki'
  AND NOT revision_is_deleted_by_page_deletion
  AND NOT event_user_is_anonymous
  AND NOT ARRAY_CONTAINS(event_user_groups, 'bot')
  AND event_timestamp RLIKE '^${params.year}-${"%02d".format(params.month)}.*'

Differences:

• co editors excludes users in the bot group, whereas active users only excludes changes that have been flagged as a bot change
• co editors only looks for new revisions being created, whereas active editors will include a few more user actions than that. (e.g Typical values are block, delete, import, makebot, move, newusers, protect, renameuser, rights, upload)
• co editors condition on revision_is_deleted_by_page_deletion will result in some different numbers too, especially as it's also only looking at created revisions, vs RC that includes more.
• co editors looks at a single whole month, the active users stuff only looks at a fixed 30 days rc_timestamp >= DATE_FORMAT(DATE_SUB(NOW(), INTERVAL 30 day), '%Y%m%d%H%i%s')

if you wanted to investigate the differences further I'd recomend waiting until the end of the month, and running the query against recent changes to find all of the actor names, and then run the co-editors query against the snapshot that includes that month, and comapring to see.

Confirming the above - from stats.wikimedia we have the following when filtering for user and splitting by dimension:

Apr 2025
1 to 4 edits 11,868
5 to 24 edits 6,337
25 to 99 edits 3,332
100 or more edits 3,019

• 11,868 + 6,337 + 3,332 + 3,019 = 24,556 editors
• 6,337 + 3,332 + 3,019 = 12,688 active editors
• 3,019 very active editors

From T394770 I wrote that on Grafana we have:

• 2025-05-01 Editors: 24.6k
• 2025-05-01 Active editors: 12.9k
• 2025-05-01 Very active editors: 3.18k

I'd agree that we're good as far as the stats.wikimedia vs. Grafana is concerned. We just need to remember that Grafana is user editors and stats.wikimedia is actor editors :)

From here the issue is that we have some bot traffic leaking into the coeditor calculations, apparently. @Addshore, we switched the coeditors metrics over to a Hive/Airflow based process, with the query for that that's run by Airflow being GitLab:wmde/analytics/~/wd_coeditors_monthly.hql :) The WHERE clause that includes removing bots and the like starts here. I'll reference the various queries in question and get it down to a point where we're confident that bots and other automated traffic aren't being included 😊

Thanks all for the information!

I'd agree that we're good as far as the stats.wikimedia vs. Grafana is concerned. We just need to remember that Grafana is user editors and stats.wikimedia is actor editors :)

Indeed.

Per the comment above, it might be worth computing your own activity numbers directly alongside the co editors so that you have a for sure 1:1 comparison, (as I myself havn't looked at exactly what an active actor etc means within the scope of stats.wikimedia.org either)

Plan is to do this in T393161 :) Maybe would make sense to also do actors in this as well instead of just users. I'll add a note there 😊

Moved in In Progress as this is now my main focus :)

The method in which users were being derived from actors was correct - we were getting an appropriate number of WD editors early in the query that was then being expanded as there was a logical issue with the computation of the groups based on edit activity level flags. We're doing a join from all other wiki editors to Wikidata editors, and some people have different levels of activity across other wikis. This was causing a double count of some editors. New aggregate values are:

• March 2025 coeditors: 22,043
• April 2025 coeditors: 21,318

Check from the other services:

• Grafana - March: ~25,200; April: ~24,600
• stats.wikimedia - March: 25,229; April: 24,556

What ultimately needs to happen is we need to derive if a user is casual, active or very active on any other wiki and then use the highest activity level in the resulting join :) I'll update the queries by EOD and run the DAG again for March and April. This means we'll have inflated values in the dataset before this point, sadly.

Roughly what will be added is the following CTEs:

-- Calculate editor activity levels across all wikis in mwh_wiki_editor_activity_flags_monthly.

...

non_wd_editor_activity_counts_monthly AS (
    SELECT
        event_user_text,
        sum(CASE WHEN is_casual_editor THEN 1 ELSE 0 END) AS casual_editor_count,
        sum(CASE WHEN is_active_editor THEN 1 ELSE 0 END) AS active_editor_count,
        sum(CASE WHEN is_very_active_editor THEN 1 ELSE 0 END) AS very_active_editor_count

    FROM
        mwh_wiki_editor_activity_flags_monthly
        
    WHERE
        wiki != 'wikidatawiki'
        
    GROUP BY
        event_user_text
),

most_active_wiki_editor_activity_flags_monthly AS (
    SELECT
        event_user_text,
        
        (
            casual_editor_count > 0
            AND active_editor_count == 0
            AND very_active_editor_count == 0
        ) AS is_casual_editor,
        
        (
            active_editor_count > 0
            AND very_active_editor_count == 0
        ) AS is_active_editor,
        
        very_active_editor_count > 0 is_very_active_editor

    FROM
        non_wd_editor_activity_counts_monthly
)

With the above we thus derive the highest activity level from the user and then use that within the CASE WHEN counts. Note that it's split into two CTEs so the logic is a bit easier to understand.

Updated DAG ran over night and the sheet has since been updated :)

Thank you! Those numbers look more plausible. All good from my side.

Anyway to get these numbers publicly?.I'm guessing they are hidden away in this Google sheet?

We have the overall goal of getting published metrics at some point, but with our capacity we need to wait on this initiative coming from WMF. T361214: Data Platform - Public dashboard support is the task that comes to mind where various stakeholders have subscribed and SREs have given opinions. The tables for these metrics in the private data lake are the following though:

• wmde.wd_coeditors_distinct_monthly
• wmde.wd_coeditors_by_wiki_monthly

If there's a vested interest in the numbers being published, then we can also export them to the published datasets directories as well, but I'd wait on a further task for that as that would require approval from WMF's legal team :)