Page MenuHomePhabricator

use access logs for simple RC filters usage statistics
Closed, ResolvedPublic3 Estimated Story Points

Description

In T397090, we found that we could use access logs to get an idea of how people are using rc filters since the filter state is set as url parameters. Using the notebook from the spike (P78388) as inspiration, create a notebook that outputs aggregate statistics for filter usage.

Details

Other Assignee
jsn.sherman

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
jsn.sherman set the point value for this task to 3.
jsn.sherman changed the task status from Open to In Progress.Jun 25 2025, 2:07 PM
jsn.sherman moved this task from Ready to In Progress on the Moderator-Tools-Team (Kanban) board.

notebook for this tested with a very small timerange:
https://gitlab.wikimedia.org/jsn/notebooks/-/blob/main/webrequest-rc_filter_usage.py
I'll share output from that internally

I'm waiting on another heavy script to finish running before running the full version of this.

I'm now running this script on the full time range

Okay, I've updated the script based on a conversation with @JWheeler-WMF this morning and I'm now re running
It would be useful for @Scardenasmolinar & @Kgraessle to have another look at the script; I think it's more legible now.
https://gitlab.wikimedia.org/jsn/notebooks/-/blob/main/webrequest-rc_filter_usage.py

Thanks for your work on this, I think this looks good.

Noting that the currently the script includes the total pageview count for each hostname, with the idea that we can consolidate wikis with low counts; the question is: do we want to do this in the script or just as a post processing step with the csv data in google sheets?

jsn.sherman removed jsn.sherman as the assignee of this task.EditedAug 6 2025, 3:26 PM

Note that I added counts for namespace and tag filter usage and limited the reporting period to 30 days to keep performance happy.

Noting that the currently the script includes the total pageview count for each hostname, with the idea that we can consolidate wikis with low counts; the question is: do we want to do this in the script or just as a post processing step with the csv data in google sheets?

IMO, we should handle as much of this as possible in the script now that the requirements are better nailed down; dumping out the raw counts could still be useful for now while we iterate on this and get feedback.

Regarding those requirements, I had a followup conversation with @JWheeler-WMF about updating the script to answer the following questions:

on a per wiki basis, "what % of queries are default, AKA do not add any custom filters? (without knowing or caring which filters are in the default)

to answer, we'll need to map out the default filters for each wiki to make sure we understand what the "baseline" combination is for web requests; then we'd keep counters for default and non-default requests. I started out attempting to do this, but it's going to take careful work to avoid mistakes and was premature when it wasn't clear exactly what questions we were trying to answer. We don't need to output the counts of individual filters to answer this question.

on a per wiki basis, how many queries have run with this [custom] filter active?

So this one takes a little bit of untangling. When we encounter a "non-default" query as defined in the previous question, we can increment a counter for it similar to the way we do now. We would output counts for "non-default" filter parameter usage only for each wiki, and not output counts for the "default" filter parameters. A question I have is how we want to represent the removal of a default filter; eg. on enwiki hidebots=1 is there by default. If you clear "Human (not bot)" in the interface, then the parameter is not present. Perhaps we have additional counters/columns for things like "hidebots=1 removed"? That's only if we care about people messing with the default filters. We could potentially save some work by not caring. Do we care @JWheeler-WMF @Samwalton9-WMF @OTichonova?

Ok, I have the updated script in gitlab for review.

And here's the percentage output; this defines filter usage as:

  • The filter has been added when no default exists
  • The filter has been added or removed when a default exists (depending on the state of the default param)
uri_hosthidebotshidecategorizationhidewikibasedamaginggoodfaithrevertrisklanguageagnosticuserexplevelhidebyothershidemyselfhidemajorhideminorhidepreviousrevisionshidelastrevisionhidepageeditshidenewpageshidewikistorieshideloghidenewuserlogwatchlistnamespacetagfilter
af.wikipedia.org30.90%30.86%30.74%0.00%0.00%0.00%3.52%0.00%1.06%0.00%10.86%9.96%0.00%0.03%0.00%0.00%10.92%0.00%0.06%2.64%6.32%
az.wikipedia.org14.14%14.18%14.12%0.00%0.00%0.80%3.60%0.01%0.81%0.00%6.56%8.17%0.01%0.04%0.04%0.00%6.64%0.00%0.40%1.03%1.56%
be.wikipedia.org27.87%28.05%28.01%0.00%0.00%0.00%0.92%0.00%0.64%0.00%5.20%4.65%0.00%0.00%0.00%0.00%4.65%0.00%0.00%2.81%3.45%
bn.wikipedia.org17.19%17.16%17.63%0.00%0.00%0.03%1.73%0.00%0.35%0.00%71.55%71.71%0.00%0.00%0.03%0.00%71.39%0.13%0.38%0.63%2.54%
cy.wikipedia.org63.33%64.77%64.15%0.00%0.00%0.00%6.30%0.00%4.03%0.00%11.16%5.37%0.00%0.00%0.00%0.00%5.37%0.00%0.00%1.65%14.15%
ha.wikipedia.org29.78%29.94%29.94%0.00%0.00%0.00%0.78%0.00%1.25%0.00%1.72%0.00%0.00%0.00%0.00%0.00%0.00%0.00%0.00%0.16%10.03%
id.wikipedia.org11.11%11.07%12.66%0.00%0.00%0.04%0.87%0.00%0.33%0.00%58.89%57.38%0.00%0.03%0.13%0.29%57.41%0.11%0.22%1.92%3.22%
is.wikipedia.org35.07%34.93%34.93%0.00%0.00%0.00%0.61%0.00%1.83%0.00%8.95%3.52%0.00%0.00%0.00%0.00%3.52%0.00%0.00%0.00%6.99%
kk.wikipedia.org22.34%46.14%46.14%0.00%0.00%0.00%0.73%0.00%0.45%0.00%16.92%16.19%0.00%0.00%0.06%0.00%16.24%0.06%0.00%0.00%7.67%
la.wikipedia.org48.39%32.00%32.28%0.00%0.00%0.00%8.89%0.00%5.95%0.00%10.64%8.12%0.00%0.00%0.00%0.00%8.54%0.42%0.00%0.98%4.76%
mk.wikipedia.org48.35%30.44%30.56%0.00%0.00%0.11%2.39%0.00%0.68%0.00%33.07%32.27%0.00%0.00%17.56%0.00%49.26%17.56%0.00%0.00%4.90%
ml.wikipedia.org27.77%42.55%28.44%0.00%0.00%0.56%1.02%0.00%0.23%0.00%45.60%45.94%0.00%0.00%0.00%0.00%45.49%0.00%0.00%1.02%2.93%
mr.wikipedia.org57.39%57.39%58.13%0.00%0.00%0.00%4.81%0.00%3.14%0.00%33.55%30.59%0.00%0.00%0.00%0.00%30.59%0.00%0.00%11.65%13.40%
nn.wikipedia.org61.12%61.01%61.09%0.00%0.00%0.00%0.41%0.00%0.48%0.00%0.22%0.00%0.00%0.00%0.00%0.00%0.00%0.00%1.44%0.00%2.33%
pa.wikipedia.org62.47%62.20%65.15%0.00%0.00%0.00%1.07%0.00%8.04%0.00%21.72%19.84%0.00%0.00%0.00%0.00%19.84%0.00%0.00%0.00%13.40%
simple.wikipedia.org91.57%91.50%90.95%0.03%0.03%0.01%19.93%0.00%9.82%0.00%10.39%0.01%0.00%0.17%0.01%0.00%2.18%0.19%0.00%2.04%0.36%
sw.wikipedia.org10.56%10.56%10.56%0.00%0.00%0.59%0.96%0.00%0.37%0.00%15.51%14.92%0.00%0.00%0.00%0.00%14.92%0.00%0.00%0.07%2.14%
te.wikipedia.org14.90%69.76%13.50%0.00%0.00%0.00%0.37%0.00%0.22%0.00%15.19%14.90%0.00%0.00%0.00%0.00%14.90%0.00%0.00%1.33%1.62%
tl.wikipedia.org33.01%33.01%32.89%0.00%0.00%0.00%0.90%0.00%1.15%0.00%31.93%31.29%0.00%0.38%0.00%0.00%31.54%0.00%1.22%0.58%5.63%
tr.wikipedia.org7.86%9.53%9.38%0.25%0.23%0.31%0.69%0.00%0.05%0.00%47.46%37.62%0.00%0.23%0.03%0.00%37.38%0.28%0.00%2.45%2.94%
Below are wikis we have not deployed revert risk language agnostic filter to
da.wikipedia.org21.25%21.40%21.30%0.00%0.00%0.00%0.71%0.00%0.46%0.02%34.32%33.55%0.00%0.23%0.02%0.00%33.64%0.00%0.00%6.73%2.99%
el.wikipedia.org10.88%11.29%10.88%0.00%0.00%0.00%5.98%0.00%0.19%0.00%51.07%50.93%0.00%0.05%0.02%0.00%50.97%0.04%5.10%0.44%0.93%
ko.wikipedia.org50.85%5.20%50.33%0.25%0.07%0.00%2.00%0.00%0.06%0.00%18.03%18.01%0.00%0.19%2.45%0.00%19.75%4.41%0.18%0.14%0.73%
pt.wikipedia.org22.14%88.94%88.89%0.21%0.16%0.00%0.35%0.00%0.16%0.00%29.93%76.54%0.00%0.02%0.00%0.00%9.82%0.04%0.11%86.99%67.16%
pl.wikipedia.org1.98%82.10%81.47%0.11%0.06%0.00%0.16%0.02%0.07%0.04%12.91%92.33%0.01%0.40%0.05%0.00%13.23%0.38%0.04%82.21%79.98%

The script looks great; the way you're taking advantage of pandas is a big improvement!

Question: what is the date range for data in the above table?

The script looks great; the way you're taking advantage of pandas is a big improvement!

Question: what is the date range for data in the above table?

This output started 8/27 and looked at the previous 35 days, so 2025-07-23 to 2025-08-27.

I let this sit for long enough that I decided to rerun the script before writing up the findings. While waiting on that to run, I thought I'd move the data to a paste, but found an interesting bug/limitation: I can't seem to get phabricator to render a remarkup table in a paste, even though the same table renders in a comment.
See: P83475

jsn.sherman updated Other Assignee, added: jsn.sherman.

just reusing this task for my reporting based on this code; currently rerunning

okay, so I distilled this down into the simplest terms I could without tossing out anything interesting.
This data was collected for the period from 2025-08-27 - 2025-10-01.
General awareness/usage of ORES-provided filtering is pretty low, however, the language agnostic revert risk filter was used more than 2x the next most popular ORES-provided filter during the above period.

filter parameter20-wiki mean usage (as percentage of requests)
hidewikibase42.4661600%
hidecategorization39.7302482%
hidebots34.7760486%
hidepreviousrevisions27.3064137%
hideminor24.1339098%
hidelog22.6141969%
tagfilter17.0681138%
namespace11.4658532%
hidemyself3.3265726%
hidenewuserlog2.8674247%
enhanced2.3915087%
hidewikistories1.5687481%
hidepageedits0.9917557%
hidenewpages0.9708737%
revertrisklanguageagnostic0.0739144%
damaging0.0363921%
watchlist0.3517260%
goodfaith0.0260128%
hidemajor0.0060860%
hidebyothers0.0009547%
hidelastrevision0.0008795%