Page MenuHomePhabricator

Temp account event data validation
Closed, ResolvedPublic

Description

Temp account event validation once Temp accounts iOS work is in Beta.

Check both wikis with temp accounts, and wikis without temp accounts (next release will include 5-20 large wikis)

Event Timeline

Beta release: Validating we are seeing is_temp values for all data from the test wikis where I am able to see data. Seeing both T and F values for users

Note we don't have data for 'cswikiversity', 'fawiktionary', 'jawikibooks', and 'itwikiquote' to verify since I am not seeing any events for those wikis in datasets that track events by wiki_db

Prod release: ( '7.7.5.5231') Validating we are seeing 100%is_temp values for all data from the test wikis where I am able to see data. Seeing both T and F values for users

Note we again don't have data for 'cswikiversity', 'fawiktionary', 'jawikibooks', and 'itwikiquote' to verify since I am not seeing any events for those wikis in datasets that track events by wiki_db

SNowick_WMF added a subscriber: HNordeenWMF.

Reopening this to check is_temp values in ios_login_action @HNordeenWMF

It looks like we are able to populate is_temp= true for most events in ios_login_action including createaccount_start but I'm not seeing any true values for createaccount_success. Not seeing any for login_success but this may follow the temp account logic where login is not required.

This could certainly be because of the limited wikis release (we only see 41 new accounts from test wikis since release until 2025-05-31) but I want to be sure that IF a temp account is successfully created that is_temp= true this will get registered in our data.

total_eventsn_is_temp_eventsn_not_temp_eventsis_temp_percentageaction
8916089160.0login_success
7236072360.0createaccount_success
876938983794.4login_start
19501492190092.5createaccount_start
1103638109970.3impression

Reopening this to check is_temp values in ios_login_action @HNordeenWMF

It looks like we are able to populate is_temp= true for most events in ios_login_action including createaccount_start but I'm not seeing any true values for createaccount_success. Not seeing any for login_success but this may follow the temp account logic where login is not required.

This could certainly be because of the limited wikis release (we only see 41 new accounts from test wikis since release until 2025-05-31) but I want to be sure that IF a temp account is successfully created that is_temp= true this will get registered in our data.

total_eventsn_is_temp_eventsn_not_temp_eventsis_temp_percentageaction
8916089160.0login_success
7236072360.0createaccount_success
876938983794.4login_start
19501492190092.5createaccount_start
1103638109970.3impression

The reason that createaccount_success is 0 is due to the changes implemented in T393628: Temporary accounts: Use anonymous user performer when creating a named account -- early on in the account creation request, we replace the temporary account session with a new anonymous user session.

Thank you @kostajh , this is our own internal account create event data, in order for us to get a count of Temp Accounts created do we need to re-wire this data tracking or is this essentially an uncountable event since it's anonymized/becomes the action of an untracked user? Is there another source that tracks the count of new Temp Accounts created that we can use to get an idea of scale of creation from Apps users?

Thank you @kostajh , this is our own internal account create event data, in order for us to get a count of Temp Accounts created do we need to re-wire this data tracking or is this essentially an uncountable event since it's anonymized/becomes the action of an untracked user? Is there another source that tracks the count of new Temp Accounts created that we can use to get an idea of scale of creation from Apps users?

Ah, I see. I was thinking about the serversideaccountcreation schema, not the iOS schema.

I am not sure why createaccount_success is zero in your instrumentation.

Resolved - we do not have data for Temp accounts past what is reported here.