@MNeisler can we resolve this task?

@kostajh

This task was blocked on the deployment of temp accounts. While we verified that the new user_is_temp field now exists in EditAttemptStep, we wanted to wait for temp accounts to be deployed to confirm that data was logging for the new field as expected.

Now that it's deployed to testwiki, we can proceed with some initial checks. I'll triage this with @ppelberg and resolve once complete.

I reviewed events in EditAttemptStep and VisualEditorFeatureUse to confirm that the user_is_temp field is logging as expected now that temp accounts has been deployed to pilot wikis. See summary of checks and results below:

Further investigation needed:

• The majority of all identified temp accounts in EditAttemptStep have a unique user id assigned as expected except for a portion of app edits (integration IN ('app-ios', 'app-android')) where user id = 0 for about 50% of temp account edit events logged.

@DLynch @SNowick_WMF - Any ideas to why some app edits by temporary users are being tagged as user_id = 0? I am wondering if this is expected or related to a difference in app instrumentation.

Passed QA Checks: ✅

• Edit attempts by temporary users are logged at all expected pilot wikis and test wikis.
• The user_is_temp field is correctly logged as either TRUE or FALSE depending on account status.
• Edit attempts by temporary users are logged across all expected integrations (page, discussiontools, app-ios, and app-android).
• Temporary user edit attempts are logged on both mobile and desktop platforms and across all editing interfaces.
• We are correctly populating the user_is_temp field across all edit actions (init, ready, loaded, SaveIntent, SaveSuccess, etc)
• We are populating user_edit_count for temporary users unlike non-temp/unregistered users where the user edit count is always logged as 0. The majority of temp accounts have logged fewer than 100 edits.

Thanks for raising this issue @MNeisler, looking into this now. It does look like the user_id = 0 was happening before we were sending user_is_temp data so this may be unrelated to temp accounts and had been happening without our knowledge previously.

Looking at data from 2024-12 only I am seeing 7.6% of events have NULL values for user_is_temp which I would bet are coming from users who have not yet upgraded their app version to versions where sending user_is_temp code is implemented. We often have stragglers and I expect this percent to decline over time but will keep an eye on this as well.

I pulled data from 2024-09 and see that ~54% of iOS/Android events had user_id = 0 values (and no user_is_temp data). Note: since we use the app_install_id identifier that we send to EditAttemptStep (see https://phabricator.wikimedia.org/T353911) , I haven't worked with the user_id value data so didn't catch this.

I will make a new ticket for iOS/Android engineers to look into this, it looks to me like from your end the QA Task is ok to resolve.