Change Details

In {T245420} we added information about the UI state and how exit happened. These are valuable for giving us a more accurate "success" metric, information about abandonment, and clues about data loss caused by design issues. Unfortunately, our logging schema was too complex and breaks some new guidelines, as well as breaking the server software meant to ingest statistics. Specifically, the "selections" array in [[ https://meta.wikimedia.org/w/index.php?title=Schema:TwoColConflictExit&oldid=19928888 | this version ]] of the exit schema cannot use "oneOf" unions, cannot be an array, and so on. We need to rewrite the column edit and selection data to either pack it into a string, or build an arbitrary string:string map. Examples of valid potential formats: * `selections: "y<n|n_n|y<n"` * `selections: { "line1": "y<n", "line2": "n_n", "line3": "y<n" } Neither is great for direct querying, but we've already got a post-processing step in our data pipeline, so we might as well go with the a compact and foolproof string format. Whatever we do here needs to also work for talk pages.

In {T245420} we added information about the UI state and how exit happened. These are valuable for giving us a more accurate "success" metric, information about abandonment, and clues about data loss caused by design issues. Unfortunately, our logging schema was too complex and breaks some new guidelines, as well as breaking the server software meant to ingest statistics. Specifically, the "selections" array in [[ https://meta.wikimedia.org/w/index.php?title=Schema:TwoColConflictExit&oldid=19928888 | this version ]] of the exit schema cannot use "oneOf" unions, cannot be an array, and so on. We need to rewrite the column edit and selection data to either pack it into a string, or build an arbitrary string:string map. Examples of valid potential formats: * `selections: "y<n|n_n|y<n"` * `selections: { "line1": "y<n", "line2": "n_n", "line3": "y<n" }` Neither is great for direct querying, but we've already got a post-processing step in our data pipeline, so we might as well go with the a compact and foolproof string format. Whatever we do here needs to also work for talk pages.

In {T245420} we added information about the UI state and how exit happened. These are valuable for giving us a more accurate "success" metric, information about abandonment, and clues about data loss caused by design issues. Unfortunately, our logging schema was too complex and breaks some new guidelines, as well as breaking the server software meant to ingest statistics. Specifically, the "selections" array in [[ https://meta.wikimedia.org/w/index.php?title=Schema:TwoColConflictExit&oldid=19928888 | this version ]] of the exit schema cannot use "oneOf" unions, cannot be an array, and so on. We need to rewrite the column edit and selection data to either pack it into a string, or build an arbitrary string:string map. Examples of valid potential formats: * `selections: "y<n|n_n|y<n"` * `selections: { "line1": "y<n", "line2": "n_n", "line3": "y<n" }` Neither is great for direct querying, but we've already got a post-processing step in our data pipeline, so we might as well go with the a compact and foolproof string format. Whatever we do here needs to also work for talk pages.