Bugzilla

(In reply to Shane Hughes [:aminomancer] from comment #1)
> Ania - should `shoppingSurfaceOnboardingDisplayed` be a separate ping? 

Hey Ania and Shane! Ot's Alessio here, data collection tools team.

`shoppingSurfaceOnboardingDisplayed` should likely be its own event, as outlined in [this spreadsheet](https://docs.google.com/spreadsheets/d/1IVDm72fXuUsXV_h9fpNJ4y8VfAl2r334Hm7c1Shm1Gc/edit#gid=0).

Super-side-note (sorry to be nitpicky!), as we're trying to make sure everybody talks consistently about things :-) A "ping" is defined as [this](https://mozilla.github.io/glean/book/appendix/glossary.html#ping) (regardless of what collects it). `shoppingSurfaceOnboardingDisplayed`  is meant to be an event.

> The onboarding message itself has its own telemetry event & interaction pings, including impressions. We have [OMC-472](https://mozilla-hub.atlassian.net/browse/OMC-472) to investigate whether we will need additional special shopping sidebar telemetry. But in this case we have an onboarding impression ping. Right now, those pings will look the same regardless of what site the user was on. But it would be relatively easy to change the pings so that the `message_id` is different depending on what site you're on. So instead of `FAKESPOT_OPTIN_DEFAULT` it could be like `FAKESPOT_OPTIN_DEFAULT_AMAZON`.
> Would having the message_id differ depending on the site be sufficient for this? Or should we create a new ping (the `shoppingSurfaceOnboardingDisplayed` event does not already exist) with its own custom property (like `retailer: "amazon"`) for this purpose? Either way it should be easy to segment data along this dimension. These generic message pings can already be segmented by message_id. So is there some additional reason we might want a new custom event ping?

If we already have them, cool, but we should also likely have both at least initially. That's _especially true_ if we won't be able to use the new migrated data from messaging-system and we'll be stuck using the PingCentre-submitted one.

> Relatedly, if we add a new custom event ping, we may also need to know what other information it should contain, what collection it should be in, whether to use Glean or PingCentre.

`shoppingSurfaceOnboardingDisplayed`  is supposed to just be an event. We can start by simply recording such event with no additional extra information.

(In reply to Shane Hughes [:aminomancer] from comment #1)
> Ania - should `shoppingSurfaceOnboardingDisplayed` be a separate ping? 

Hey Ania and Shane! Ot's Alessio here, data collection tools team.

`shoppingSurfaceOnboardingDisplayed` should likely be its own event, as outlined in [this spreadsheet](https://docs.google.com/spreadsheets/d/1IVDm72fXuUsXV_h9fpNJ4y8VfAl2r334Hm7c1Shm1Gc/edit#gid=0).

Super-side-note (sorry to be nitpicky!), as we're trying to make sure everybody talks consistently about things :-) A "ping" is defined as [this](https://mozilla.github.io/glean/book/appendix/glossary.html#ping) (regardless of what collects it). `shoppingSurfaceOnboardingDisplayed`  is meant to be an event.

> The onboarding message itself has its own telemetry event & interaction pings, including impressions. We have [OMC-472](https://mozilla-hub.atlassian.net/browse/OMC-472) to investigate whether we will need additional special shopping sidebar telemetry. But in this case we have an onboarding impression ping. Right now, those pings will look the same regardless of what site the user was on. But it would be relatively easy to change the pings so that the `message_id` is different depending on what site you're on. So instead of `FAKESPOT_OPTIN_DEFAULT` it could be like `FAKESPOT_OPTIN_DEFAULT_AMAZON`.
> Would having the message_id differ depending on the site be sufficient for this? Or should we create a new ping (the `shoppingSurfaceOnboardingDisplayed` event does not already exist) with its own custom property (like `retailer: "amazon"`) for this purpose? Either way it should be easy to segment data along this dimension. These generic message pings can already be segmented by message_id. So is there some additional reason we might want a new custom event ping?

If we already have them, cool, but we should also likely have both at least initially. That's _especially true_ if we won't be able to use the new migrated data from messaging-system and we'll be stuck using the PingCentre-submitted one.

> Relatedly, if we add a new custom event ping, we may also need to know what other information it should contain, what collection it should be in, whether to use Glean or PingCentre.

`shoppingSurfaceOnboardingDisplayed`  is supposed to just be an event. We can start by simply recording such event with no additional extra information.

Note that, if anything needs to be recorded with custom means in the messaging system (via PingCentre), then the same thing **MUST** be recorded and validated the same way in Glean in that system, as we're about to phase out and remove the PingCentre implementation this half.