Due to memory issues I ran a script to backfill this metric one month at a time in my dev db.

Unique devices and Unique users by project family for EU is available in the following links
Feb 2026 - July 2026 snapshot
Wikimedia rollup for Commons

Reviewed constructive_activations
Requested @APizzata-WMF for a logic change to retained newcomers to align with monthly movement metrics

discussed on slack.
we can add a depends_on variable in the yaml. So it runs the job only once the latest snapshot (or an equivalent column) has landed in all the upstream tables that the job depends on. (the dependency tables must be in datasets.yaml)
so the dependency for weekly Reader metrics will be last week end day (ie Sunday) -> for readers the job can run as soon as Sunday is available, instead of a fixed Monday run.
for weekly active editors -> Sunday + interval 2 days. so instead  of sunday the dependency should look for wednesday snapshot.

Next Steps:

• Megan can make change to add editor interface. Clone this branch. Use base_contructive_editors.
• Use standard naming convention for editor interface
• Let’s keep broad to all editors and project families and then add filters later in Superset.
• Keep monthly basis
• Maya to merge if everything looks good
• DPE to help with backfill

yes, i was going to add that these aren't revision related tags, we rely on change_tag and change_tag_def for getting the platform for moderator actions.

hi @APizzata-WMF , since we have platform in the heartbeat metrics, i was wondering if mediawiki change_tag and change_tag_def was also in scope ?

thank you once again !
Alright, closing this task

@MNeisler , thank you so much for the additional analysis that helped us finalize a more accurate Baseline and Target. [too bad we dont have Wikilove on phab, or do we?]

Baseline and Target for this metric has been updated following the approval meeting today

@Hghani , could you pls review T432073 EU request.ipynb ? thanks!

@APizzata-WMF , thank you so much for this. super helpful. i did some quick calculations, and Im seeing a very small 0.26% increase when using the historical field for constructive edits on enwiki and 0.16% inc in constr edit rate. I think this change is within an acceptable range.
I believe that for constructive activation and retained newcomers impact of historical page_namespace as well as user_text historical will be even lower because we only look at the users that made their first edit within 24hrs, and then in the next 15 days. so you can go ahead and convert these metrics to weekly.

@MNeisler , as discussed today, could you pls do a check on the numbers if we exclude the outliers ie editors with <=1k edits per week, and <=10k edits per week.

• Support Actions Definition: An interaction between two or more contributors aimed at providing feedback to the recipient to support their growth or underscore their impact within the movement  (e.g., thanks given and received, neutral or positive conversation on talk page)
• This KR will focus on providing motivational ways to contribute (creating a way for editors to track and share their editing goals, weekly personalized editing impact reports, improved ways to recognize the good work of other editors, improved ways to generate worklists or "to-do" lists, and incentivizing notifications (e.g., “If you do 10 more edits, you can gain access to Wikipedia Library”)) 
• This will get editors to edit frequently, thus building a habit.
• So the lift in the metric will be primarily through increase in edits, rather than non-edit actions
• The metric will be available in 2 ways - 1) experiment metric within Growthbook, 2) Indicator metric on the Contributors dashboard

hey @OBenhmida , could you confirm if by 5% you mean the Reporting Target % Increase, and what would that be in terms of the Target engagement count ?

thanks Lydia and WMDE team for the discussions last week !

Target Audience:

• Desktop and mobile web edits
• Completed by all junior and experienced editors (very experienced editors excluded)
• Only registered/permanent users (no temp or IP users)
• Limited to edits on a Wikipedia project - Korean, Turkish, Chinese, French, Czech, Vietnamese

Target Audience:

• Desktop and mobile users
• Edits in all namespaces
• all editor experience types
• Registered/Permanent users (no temp or IP users)
• Wikipedia projects only - Korean, Turkish, Chinese, French, Czech, Vietnamese

Hi @nshahquinn-wmf , I see about ~1% increase in the base_account_registration table compared to the existing model thats calculating wikipedia account registrations. lets review it next week.

Since the editor_month table is being used for calculating the Contributors core metric and strategy metrics the priority on this task has gone up, and it would be useful to use the central_id instead of username for accuracy.

Next Steps:

Provide weekly participation rate baseline pending finalization of data discovery work.
Review weekly historical trends over time to propose a target for the KR.

I shared the non-edit actions queries with Megan earlier this week (notebook) .
Looking at the data it seems like some of the non-edit actions will be included in the weekly edit rate since they are revisions. here's the new breakdown of edits and non-edits for the DE1.2 KR metric.

I have started working on WE 1.5.1a and posting my main updates in Asana. I will keep track of all the other things I am working on in this phab task (as much as I can! )

1. Further investigation:

hey @amastilovic , confirming, this is for the backfill use case we discussed yesterday, right?
Also you may want to change the Q3 tag to Q4 since its already March 31 :)

Update: we tried this today and the test failed. Discovered a bug where the same dbt model run works when run manually but not from within the Skein operator. DE is working on a fix

Hi @JAllemandou , the metrics have been developed in accordance to the new Contributor measurement strategy. you can see definitions in the following links-
Core and health metrics
Indicator metrics
pls feel free to reach out if you have any questions

@JAllemandou , yes, thats correct

Feb 27, 2026
Progress update

• Bi-weekly Movement Trends brief report
  • Ran the notebooks and paired with Omari to look at trends, and produce the narrative
• Monthly Movement metrics
  • Published January report and had conversations with WMDE team about wikidata
  • WMDE have requested for Wikidata contributors data for measuring impact from activities
• Coordinated with Contributors strategy

We continue to see inflation in user pageviews coming from Vietnam (superset) in Janaury 2026

I ran sqlfluff on the cluster today using the steps @JMonton-WMF provided 2 days ago and was successfully able to pass all the linter rules in the current version of the model.
I also updated the sqlfluff ignore file and submitted a merge request for the change

I was reporting the Contributors dashboard updates on Asana and skipped updating it here. The hypothesis was closed on Jan 30, 2026 so let me add updates from the last 2 weeks here.

• Both Snapshots have been updated on the site - https://foundation.wikimedia.org/wiki/Legal:EU_DSA_Userbase_Statistics
• We have provided the numbers via gitlab instead of updating the excel sheet, and will continue this going forward
• A few observations on the data
  • The latest snapshot is seeing huge drops in the following smaller projects -

wikinews
wikiversity
wikivoyage
mediawiki

• And big increases in wikifunctions
• also seeing bigger drops in some wikimedia projects (not in Commons)

We anticipate seeing some new trends in the Commons and Wikidata split which will need additional investigation so we're targeting to draft the monthly report by Monday Feb 23rd.

thanks @brennen , that worked!

@brennen can you pls check if my gitlab account Mayakpwiki is part of movement-insights group ? I am part of the team, and currently not able to access the private repo.

• code needs to be updated to use iceberg unique devices table since hive tables are not backfilled beyond august 2025
• will be publishing output to gitlab going forward
• I will re-run the Feb-July 2025 report as well since the data was backfilled

Edited description to add the data modeling guidelines. Since we are in the process of cleaning up the code I can try and implement some of the recommendations there.

Thank you @JMonton-WMF ! for all this info. this is a very nice and clear proposal. all of this makes sense to me. sharing a few thoughts -

• I like the proposed folder structure. happy to think through the naming convention.
  • <team>_<project>_<modelname>.sql would translate to something like movementinsights_contributors_retained_editors.sql or productanalystics_consumers_reader_retention_weekly.sql which could become unreasonably long or would need a lot of acronyms.
• My 2c on organizing models: while packages are complex, I feel they would facilitate re-orgs better than groups. if a team ceases to exist or changes, another team could inherit the projects of that group vs having to make copies of their existing projects and models and discarding the older version (this is how i understood group vs package concept, i may be wrong).
  • anyway the likelihood of this happening very often is low, so lets go with whats sustainable, and less complex.