Change Details

The current [2.0.0](https://gerrit.wikimedia.org/g/schemas/event/secondary/+/master/jsonschema/analytics/mediawiki/searchpreview/2.0.0.yaml) schema captures a session id from `searchSatisfaction.js`. That one, however, is not available on mobile. Based on https://docs.google.com/spreadsheets/d/1drMnPt8mJa8rQRNCCpgkOo_0eQmdDlHDQnLIbjg8syU/edit#gid=0 & other discussions, we intended to use this session id for: 1. cross-referencing with the [searchsatisfaction schema](https://gerrit.wikimedia.org/r/plugins/gitiles/schemas/event/secondary/+/master/jsonschema/analytics/legacy/searchsatisfaction/current.yaml) to infer whether the user behind this session is registered or anon 2. cross-referencing with the [searchsatisfaction schema](https://gerrit.wikimedia.org/r/plugins/gitiles/schemas/event/secondary/+/master/jsonschema/analytics/legacy/searchsatisfaction/current.yaml) to infer whether the user behind this session is a bot 3. counting the number of sessions with searchpreviews 4. comparing the numbers of sessions with searchprevies vs. those where it isn't used Since we will not be able to cross-reference with the searchsatisfaction schema, we can instead capture that information ourselves: 1. add a new field `is_anon` to the searchpreviews schema where the return value of `mw.user.isAnon()` gets captured 2. I think we can ignore `bot` - this would be annoying to implement (not available from the client side IIRC), and this is the kind of feature that a can't imagine a bot interacting with 3. implement logic similar to the one in searchSatisfaction.js to generate new session ids; it will not be possible to cross-reference with the searchsatisfaction schema, but we can get to the same metrics if we use the same implementation. Note: also remove the documentation that says this value matches searchsatisfaction's `event.searchSessionId` 4. add a new type (`new_session`) to the `action` enum in the searchpreviews schema to track the total number of sessions, so that we're able to cross-reference them with the amount of sessions the we track other actions for (or no actions) 1-3 are pretty straightforward. For 4, we're going to need to add some more instrumentation. This `new_session` action should be called in the following circumstances: - prior to emitting any other event when we detect that the session_id has changed since the last event was logged (i.e. 10minute session time has passed) - when SearchVue is loaded on Special:Search & with results that support SearchVue when there is no active session yet This essentially captures all session id where a user actively engages with search, even if they don't interact with SearchVue. Diffing session_ids for action=new_session against session_ids for all other actions will satisfy #4. @cchen - can you confirm that all of the above works for you? - As part of QA for this task, ensure that all events are being properly tracked in mobile and re-check for desktop.

The current [2.0.0](https://gerrit.wikimedia.org/g/schemas/event/secondary/+/master/jsonschema/analytics/mediawiki/searchpreview/2.0.0.yaml) schema captures a session id from `searchSatisfaction.js`. That one, however, is not available on mobile. Based on https://docs.google.com/spreadsheets/d/1drMnPt8mJa8rQRNCCpgkOo_0eQmdDlHDQnLIbjg8syU/edit#gid=0 & other discussions, we intended to use this session id for: 1. cross-referencing with the [searchsatisfaction schema](https://gerrit.wikimedia.org/r/plugins/gitiles/schemas/event/secondary/+/master/jsonschema/analytics/legacy/searchsatisfaction/current.yaml) to infer whether the user behind this session is registered or anon 2. cross-referencing with the [searchsatisfaction schema](https://gerrit.wikimedia.org/r/plugins/gitiles/schemas/event/secondary/+/master/jsonschema/analytics/legacy/searchsatisfaction/current.yaml) to infer whether the user behind this session is a bot 3. counting the number of sessions with searchpreviews 4. comparing the numbers of sessions with searchprevies vs. those where it isn't used Since we will not be able to cross-reference with the searchsatisfaction schema, we can instead capture that information ourselves: 1. add a new field `is_anon` to the searchpreviews schema where the return value of `mw.user.isAnon()` gets captured 2. I think we can ignore `bot` - this would be annoying to implement (not available from the client side IIRC), and this is the kind of feature that a can't imagine a bot interacting with 3. implement logic similar to the one in searchSatisfaction.js to generate new session ids; it will not be possible to cross-reference with the searchsatisfaction schema, but we can get to the same metrics if we use the same implementation. Note: also remove the documentation that says this value matches searchsatisfaction's `event.searchSessionId` 4. add a new type (`new-session`) to the `action` enum in the searchpreviews schema to track the total number of sessions, so that we're able to cross-reference them with the amount of sessions the we track other actions for (or no actions) 1-3 are pretty straightforward. For 4, we're going to need to add some more instrumentation. This `new_session` action should be called in the following circumstances: - prior to emitting any other event when we detect that the session_id has changed since the last event was logged (i.e. 10minute session time has passed) - when SearchVue is loaded on Special:Search & with results that support SearchVue when there is no active session yet This essentially captures all session id where a user actively engages with search, even if they don't interact with SearchVue. Diffing session_ids for action=new_session against session_ids for all other actions will satisfy #4. @cchen - can you confirm that all of the above works for you? - As part of QA for this task, ensure that all events are being properly tracked in mobile and re-check for desktop.

The current [2.0.0](https://gerrit.wikimedia.org/g/schemas/event/secondary/+/master/jsonschema/analytics/mediawiki/searchpreview/2.0.0.yaml) schema captures a session id from `searchSatisfaction.js`. That one, however, is not available on mobile. Based on https://docs.google.com/spreadsheets/d/1drMnPt8mJa8rQRNCCpgkOo_0eQmdDlHDQnLIbjg8syU/edit#gid=0 & other discussions, we intended to use this session id for: 1. cross-referencing with the [searchsatisfaction schema](https://gerrit.wikimedia.org/r/plugins/gitiles/schemas/event/secondary/+/master/jsonschema/analytics/legacy/searchsatisfaction/current.yaml) to infer whether the user behind this session is registered or anon 2. cross-referencing with the [searchsatisfaction schema](https://gerrit.wikimedia.org/r/plugins/gitiles/schemas/event/secondary/+/master/jsonschema/analytics/legacy/searchsatisfaction/current.yaml) to infer whether the user behind this session is a bot 3. counting the number of sessions with searchpreviews 4. comparing the numbers of sessions with searchprevies vs. those where it isn't used Since we will not be able to cross-reference with the searchsatisfaction schema, we can instead capture that information ourselves: 1. add a new field `is_anon` to the searchpreviews schema where the return value of `mw.user.isAnon()` gets captured 2. I think we can ignore `bot` - this would be annoying to implement (not available from the client side IIRC), and this is the kind of feature that a can't imagine a bot interacting with 3. implement logic similar to the one in searchSatisfaction.js to generate new session ids; it will not be possible to cross-reference with the searchsatisfaction schema, but we can get to the same metrics if we use the same implementation. Note: also remove the documentation that says this value matches searchsatisfaction's `event.searchSessionId` 4. add a new type (`new_-session`) to the `action` enum in the searchpreviews schema to track the total number of sessions, so that we're able to cross-reference them with the amount of sessions the we track other actions for (or no actions) 1-3 are pretty straightforward. For 4, we're going to need to add some more instrumentation. This `new_session` action should be called in the following circumstances: - prior to emitting any other event when we detect that the session_id has changed since the last event was logged (i.e. 10minute session time has passed) - when SearchVue is loaded on Special:Search & with results that support SearchVue when there is no active session yet This essentially captures all session id where a user actively engages with search, even if they don't interact with SearchVue. Diffing session_ids for action=new_session against session_ids for all other actions will satisfy #4. @cchen - can you confirm that all of the above works for you? - As part of QA for this task, ensure that all events are being properly tracked in mobile and re-check for desktop.