Per offline discussion with @ABendall-WMF, Editing Team will complete this work by the end Editing-team (FY2026-27 Q1 sprint 3) (19 August 2026).

@ppelberg just a thought - would it be possible to persist the app_install_id value when user is handed off to mobile web editing and that value is retained throughout the rest of the edit steps in editattemptstep? That way I can just match our app init events to saveSuccess events by the same app_install_id even if editor_interface = visualeditor

Largely from @Tsevener: I'm not sure how we can track edits after the handoff to visual editor without this. We won't know abandon or success without tying the EditAttemptStep events in VE to an app installation ID. We need to ensure the app installation ID passes through the authentication flow, so some form of authentication flow work likely still needs to happen.

You would need to pass it through to us. It'd perhaps be most optimal for what we already did if you gave it as the value of the returntoapp parameter we added.

Note that this is going to produce a situation where we're putting this app_install_id into shareable URLs, so you're going to get some amount of users causing editing sessions with an install ID when they don't even have the app.

How are you thinking the value in the parameter would be formatted?

You would need to pass it through to us. It'd perhaps be most optimal for what we already did if you gave it as the value of the returntoapp parameter we added.

@DLynch @Seddon

This is perhaps how this could work, if that's your preference. @JTannerWMF has said it is okay if there is no redirect back to the app initially (user will have to manually switch back to the app). We can still release the app, ready to handle the redirect once the Editing team work is done.

1. Editing team comments out current automatic redirect code on their side.
2. Editing team adds code to consume an app_install_id passed in through returntoapp instead of a boolean. This app_install_id will need to survive through the web authentication flow. It will need to log to EditAttemptStep in VE events.
3. Apps are modified to send app_install_id value in returntoapp when user is kicked out to VE. They are also set up to receive a redirect url that looks like (wikipedia://lang.wikipedia.org/wiki/{title}?saved={true or false}&revision={revision ID}), knowing they won't see redirects initially due to editing team commenting things out in step 1.
4. Apps release the feature.
5. Editing team completes work in https://phabricator.wikimedia.org/T434258 and deploys. If VE sees a returntoapp value, it will display blue banner at the top after edit abandon or publish. Upon tap it redirects to (wikipedia://lang.wikipedia.org/wiki/{title}?saved={true or false}&revision={revision ID}), which the released app is already set up to handle.

So there are still steps 1 and 2 blocking us from an apps release, but hopefully that is less of a lift on the Editing side? Let me know what y'all think.

Sorry if I am being redundant but from an analyst standpoint we are relying on data in editattemptstep to measure edit start/success/fail rate - if we can send the app_install_id value in a URL how will that be preserved in the data? There is a column in editattemptstep for event."app_install_id" specifically - will we be able to preserve that value when user moves from app to VE?

That comment is the first time I'd seen T434258, so I wasn't aware there were major behavior changes needed. It sounds like the actual new flow is that there won't be any sort of automatic redirect, there'll just be a button after you save to give you the option to return to the app, and you'll be left in the browser if you skip that?

In T432853#12217215, @Seddon wrote:

How are you thinking the value in the parameter would be formatted?

Doesn't really matter to me. So long as you give us something that, as a string, is what you want put into the app_install_id column then we can just blindly pass it through.

In T432853#12217551, @SNowick_WMF wrote:

if we can send the app_install_id value in a URL how will that be preserved in the data? There is a column in editattemptstep for event."app_install_id" specifically - will we be able to preserve that value when user moves from app to VE?

Yes, we would put whatever you gave us into that column.

@DLynch thank you that answers my question.

@DLynch

That comment is the first time I'd seen T434258, so I wasn't aware there were major behavior changes needed. It sounds like the actual new flow is that there won't be any sort of automatic redirect, there'll just be a button after you save to give you the option to return to the app, and you'll be left in the browser if you skip that?

Yep pretty much. For the new flow, there will be a blue banner button at the top after you save OR abort the edit to give you the option to return to the app. And the user can ignore it and stay in the browser. Upon tap of the blue banner, it'll trigger the redirect.

But that'll take a while to complete so we're thinking in the meantime, we will just disable the automatic redirect for now (I can add that disabling to this task's description, or spin up a new task). Then the blue banner work (T434258) can be completed later.

Doesn't really matter to me. So long as you give us something that, as a string, is what you want put into the app_install_id column then we can just blindly pass it through.

Here's an example of what the app install ID would look like when we navigate:

https://en.wikipedia.org/wiki/John_Arne_Riise?useformat=mobile&veaction=edit&returntoapp=56704183-1EE3-4E4F-A542-2E81F48C8EF3&section=0

Let me know if that would work for you, thanks.

Meeting result: we're going to add a new parameter specifically for the app_install_id, to separate tracking it out from the return-to-app behavior. It's going to need to get passed through the auth flows as well.

Change #1329586 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/WikimediaEvents@master] EditAttemptStep: track app_install_id if provided via a URL parameter

https://gerrit.wikimedia.org/r/1329586

Change #1329582 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/MobileFrontend@master] Editor: allow appinstallid parameter to survive authentication

https://gerrit.wikimedia.org/r/1329582

Change #1329582 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Editor: allow appinstallid parameter to survive authentication

https://gerrit.wikimedia.org/r/1329582

Change #1329586 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] EditAttemptStep: track app_install_id if provided via a URL parameter

https://gerrit.wikimedia.org/r/1329586

We added a appinstallid=FOO URL parameter. If the WikimediaEvents logging for EditAttemptStep notices that being present, it will include it in the data it's submitting. It should be persisted through the auth process just like returntoapp was.

Hi @DLynch - looks good - when will I be able to verify/validate this in event.editattemptstep - do you have a validation task I can follow as well? Thanks!

There's not a separate validation task, we tend to just do QA in the implementation ticket.

You can watch to see if the event is being submitted including the app_install_id parameter as this week's train rolls out, so thursday at the latest. Once you've for-sure submitted a web event with the parameter included, events take a day or so to actually make it into the data where they can be queried. You'd want to look for an integration=page event with a non-empty app_install_id.

@DLynch Validated VisualEditor edit session instrumentation includes a non-empty app_install_id in the web integration=page Init event when an editing session originates from a Wikimedia app, allowing the app and web events to be joined into a single editing session, as seen per screenshots/video.

Test Result - TestFlight

Status: ✅ PASS
Environment: TestFlight
OS: macOS Tahoe 26.5.2
Browser: Chrome 151
Device: MBA
Emulated Device: BrowserStack: iPhone 17 Pro

Test Artifact(s):
TestFlight: 09.03

Test Steps

Test Case 1: Ensure app-originated editing sessions include app installation information

1. Open the Wikimedia app on a supported mobile device or emulator.
2. Start an editing journey in the app that transitions to the web VisualEditor.
3. Complete the action that opens the web editing experience.
4. Monitor the instrumentation events generated by the web editing experience.
5. Locate the integration=page Init event associated with the editing session.
6. Inspect the event parameters.
7. Verify that app_install_id is present and contains a non-empty value.
8. ✅ AC1: The web integration=page Init event for an app-originated editing session contains a non-empty app_install_id value.

App install ID	Integration=page

Verifying that I am seeing Android and iOS events where integration=page and init has originated on app first.