Page MenuHomePhabricator

Add rev_id tracking from Commons revisions, add tracking for user blocks and suspensions
Closed, ResolvedPublic

Description

Per @Charlotte

  1. Edits made to Commons generate a rev_id that is currently not tracked in 'MobileAppWikiEdits` events, we need to add that rev_id to the event record when users make revisions on Commons.
  1. The app is set to autoblock or suspend users if their revert rate goes above a pre-determined percent. This is not tracked and we need to be able to see when blocks and suspends are implemented. This should be recorded in MobileAppWikiEdits as an event where action ='blocked' or 'suspend' (and maybe utilize the abuseFilterName field if appropriate?)

We will also want to track expiration dates for suspensions and have a way to see the users who have a block or suspension on their user record, using the same process and labels used for non-mobile blocks that are tracked in logging. (See 'block' on https://www.mediawiki.org/wiki/Manual:Log_actions)

Adding @nettrom_WMF who has offered to help when we have questions about block logging, I will ping him if we need his input.

Done:

  • Add rev_id to the event record when users make revisions on Commons.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Just a couple of comments regarding both points:

Edits made to Commons generate a rev_id that is currently not tracked in 'MobileAppWikiEdits` events

This has been fixed in the current Alpha, and will make it into our next update.

The app is set to autoblock or suspend users if their revert rate goes above a pre-determined percent. This is not tracked and we need to be able to see when blocks and suspends are implemented. This should be recorded in MobileAppWikiEdits as an event where action ='blocked' or 'suspend' (and maybe utilize the abuseFilterName field if appropriate?)

The notion of "when" the user becomes blocked is kind of tricky. Our threshold for "blocked" is based on the rate of reverts versus edits. However, it's only when the user goes back to Suggested Edits (which refreshes their contributions) that the app decides whether they're now blocked. (i.e. The user could have gotten 100 reverts, but only log back into the app 10 days later, and that's when it would become blocked. Or the user could never return to the app, and the app would never know that the user is now blocked.)

In other words, there's no server-level event that occurs when the n-th revert is made, which would cause the user to become blocked on our end.

Thanks - adding some replies:

Edits made to Commons generate a rev_id that is currently not tracked in 'MobileAppWikiEdits` events

This has been fixed in the current Alpha, and will make it into our next update.

Thanks, will mark this as done. Do analytics changes get tested in QA?

The notion of "when" the user becomes blocked is kind of tricky. Our threshold for "blocked" is based on the rate of reverts versus edits. However, it's only when the user goes back to Suggested Edits (which refreshes their contributions) that the app decides whether they're now blocked. (i.e. The user could have gotten 100 reverts, but only log back into the app 10 days later, and that's when it would become blocked. Or the user could never return to the app, and the app would never know that the user is now blocked.)

In other words, there's no server-level event that occurs when the n-th revert is made, which would cause the user to become blocked on our end.

Does the user get a notification that they have been blocked or suspended? How do we communicate the block? If there is a message to user could we track that?

Does the user get a notification that they have been blocked or suspended? How do we communicate the block? If there is a message to user could we track that?

Nope, the user only finds out that they're blocked by going back to Suggested Edits and seeing the "blocked" screen. (and be unable to proceed from there)
We could potentially send an event when the user first gets to that screen, but that wouldn't match to exactly when the user reached the blocked status. And there's no guarantee that the user will go back to that screen.

LGoto triaged this task as Medium priority.Mar 2 2020, 5:50 PM
LGoto moved this task from Next 2 weeks to Doing on the Product-Analytics (Kanban) board.

Rather than add tracking for blocks we will consider adding back in tutorial or editor guidance, tbd.