After exploration, I have found that the user table in mariadb captured temp account creation. Temp account can be identified using regular expression filter user_name regexp '^[~]2'.

Hi @Tchanders , Is this the way to identify temp account creation? Are there other schemas that also capture temporary account names and related events?

In T371402#10065918, @jwang wrote:

After exploration, I have found that the user table in mariadb captured temp account creation. Temp account can be identified using regular expression filter user_name regexp '^[~]2'.

Hi @Tchanders , Is this the way to identify temp account creation?

If you have access to the DB, you can use the user_is_temp column on the user table.

Are there other schemas that also capture temporary account names and related events?

I'm not sure if I understand this, could you please add some more detail on what you are looking for?

Thanks @kostajh for the info.
Are there other schemas which also have user_is_temp column, or similar column indicating temp account? For context, I'm exploring the schemas to determine how we can extract data for the request metrics by joining them. It would be helpful to know which schemas already include the 'temp account' column.

In T371402#10067387, @jwang wrote:

Thanks @kostajh for the info.
Are there other schemas which also have user_is_temp column, or similar column indicating temp account? For context, I'm exploring the schemas to determine how we can extract data for the request metrics by joining them. It would be helpful to know which schemas already include the 'temp account' column.

Looking at codesearch, I see a few other schemas, here is also the list of extensions that use the property:

• Extension:CampaignEvents (1 files)
  • src/Invitation/PotentialInviteesFinder.php (2 matches)
• Extension:DiscussionTools (1 files)
  • includes/Notifications/EventDispatcher.php (1 matches)
• Extension:WikiEditor (1 files)
  • includes/Hooks.php (2 matches)
• Extension:WikimediaEvents (1 files)
  • modules/ext.wikimediaEvents/editAttemptStep.js (2 matches)
• operations/puppet (2 files)
  • modules/profile/templates/wmcs/db/wikireplicas/maintain-views.yaml (1 matches)
  • modules/role/files/mariadb/filtered_tables.txt (1 matches)
• schemas/event/secondary (12 files)
  • jsonschema/analytics/legacy/editattemptstep/1.4.0.yaml (2 matches)
  • jsonschema/analytics/legacy/editattemptstep/1.4.1.yaml (2 matches)
  • jsonschema/analytics/legacy/editattemptstep/1.5.0.yaml (2 matches)
  • jsonschema/analytics/legacy/editattemptstep/2.0.0.yaml (2 matches)
  • jsonschema/analytics/legacy/editattemptstep/2.0.1.yaml (2 matches)
  • jsonschema/analytics/legacy/editattemptstep/2.0.2.yaml (2 matches)
  • jsonschema/analytics/legacy/editattemptstep/2.0.3.yaml (2 matches)
  • jsonschema/analytics/legacy/editattemptstep/current.yaml (2 matches)
  • jsonschema/analytics/legacy/visualeditorfeatureuse/1.1.0.yaml (1 matches)
  • jsonschema/analytics/legacy/visualeditorfeatureuse/current.yaml (1 matches)
  • jsonschema/analytics/mediawiki/talk_page_edit/1.2.0.yaml (2 matches)
  • jsonschema/analytics/mediawiki/talk_page_edit/current.yaml (2 matches)

Hi @kostajh, thank you for doing the code search. Can you also give more info on how "IP reveals" are tracked? Any documents about it?

In T371402#10085665, @jwang wrote:

Hi @kostajh, thank you for doing the code search. Can you also give more info on how "IP reveals" are tracked? Any documents about it?

We log IP reveals to Special:Log, e.g. https://en.wikipedia.org/wiki/Special:Log?type=ipinfo&user=&page=&wpdate=&tagfilter=&wpfilters[]=newusers&wpFormIdentifier=logeventslist. Those logs are visible to users with CheckUser level access.

It's likely that we'll implement an auto-reveal mode (T358853#9704846, cc @Niharika) and we may also then log IPs that are revealed when this mode is enabled to an EventLogging schema.

@Niharika another thing to consider: we'll be shifting the logged-out, anonymous IP editing experience to a logged-in, temporary account. Accounts generally have slower page load times because they will bypass some edge caches we have in place for anonymous traffic. Given the impact of web performance on conversion rates, we might want to keep track of page load times and editor interactions for temporary accounts. (In this case, I think the conversion rate we might be concerned with is subsequent edits after the first edit, but we might also see a decrease in pages browsed after initial edit for temporary accounts, compared with anonymous IP editors.)

Example:

• Visiting https://test.wikipedia.org/wiki/Barack_Obama while logged-out vs logged-in as a temporary account, the GET request for the HTML is ~500 ms for a logged-out user vs ~800ms for a temporary account user.

Number of rate limit trips for temporary account creations per IP (default is 6 temp account creations per IP address per day)

@kostajh , to measure it, we need a schema which captures the IP address of the temp account. Do you know which schema that is?

In T371402#10115627, @jwang wrote:

Number of rate limit trips for temporary account creations per IP (default is 6 temp account creations per IP address per day)

@kostajh , to measure it, we need a schema which captures the IP address of the temp account. Do you know which schema that is?

We don't capture rate limit trips in an event logging schema, as far as I know. This metric is probably best done via T357763: [Epic] Create a temporary accounts initiative Grafana dashboard.

Status update

Completed
All metrics we planned have been deployed except for 'Revert rate of temp account edits'.

• Edits Rollbacks
• Number of temp accounts being blocked versus IP addresses
• New regular account creations
• Checkuser admins

Next steps:

• Revert rate of temp account edits

Update Revert rate graph in temp account deployment dashboard after the source schema is ready. (tracked in sub ticket T377516)

The source schema edit_hourly does not have a field to indicate temporary account users. This graph will be updated to reflect the revert rate of edits made by temporary accounts once the schema is updated by the data engineering team.
Dependency:T377767, T377768