In order to look at the size of edits and whether they were reverted, saveSuccess events need to have the new revision ID in the revision_id field. Since an attempt's events before saveSuccess should have the parent revision ID in that field, a quick way to check this is to make sure that all saveSuccess events have a larger revision ID than all previous events in the session.
with saves as ( select event.editing_session_id as attempt_id, event.revision_id as revision_id, event.platform as platform, event.editor_interface as editor from event.editattemptstep where event.action = "saveSuccess" and year = 2019 and month = 6 and -- Remove Flow and other non-standard edits event.integration = "page" ), pre_saves as ( select event.editing_session_id as attempt_id, max(event.revision_id) as max_revision_id from event.editattemptstep where event.action != "saveSuccess" and year = 2019 and month = 6 and -- Remove Flow and other non-standard edits event.integration = "page" group by event.editing_session_id ) select platform, editor, concat(round(( sum(cast(saves.revision_id > pre_saves.max_revision_id as int)) * 100 / count(*) ), 1), "%") as save_has_greater_revision_id from saves left join pre_saves on saves.attempt_id = pre_saves.attempt_id group by platform, editor
And it looks like like we don't always log the new revision ID on desktop wikitext and never log it on other platforms.
| platform | editor | saveSuccess has larger revision ID |
|---|---|---|
| desktop | visualeditor | 0.0% |
| desktop | wikitext | 96.4% |
| desktop | wikitext-2017 | 0.0% |
| phone | visualeditor | 0.0% |
| phone | wikitext | 0.0% |
The phone editors are the ones that are important for the A/B test, although while we're looking at it it would be nice to fix this on desktop too so that in the future we can correlate details about the edit attempt (e.g. time taken, number of save attempts) with details of the published edit (e.g. length, whether reverted).