1848674 - Record retailer flag in shoppingSurfaceOnboardingDisplayed event

Status: NEW

(Firefox :: Messaging System, enhancement, P5)

Description

[Ania]

User story

As a product manager, I would like to be able to understand the shopping opt-in rate at a retailer level, so that I can improve the relevancy of the opt-in messaging.

Acceptance criteria

1. shoppingSurfaceOnboardingDisplayed event has a flag that allows to distinguish between opt-ins from different retailers.

Adding this to the backlog and marking as blocked, while we untangle whether this is acceptable within our existing privacy policy or whether we need to think through an alternative way to improve and experiment with opt-in messaging.

Comment 1

[Shane Hughes [:aminomancer]]

Ania - should shoppingSurfaceOnboardingDisplayed be a separate ping? The onboarding message itself has its own telemetry event & interaction pings, including impressions. We have 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?

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.

Also CCing Ed and Dan.

Comment 2

[Alessio Placitelli [:Dexter]]

(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.

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 (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 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.

Comment 3

[Ania]

Alessio, thank you so much for chipping in.
Going to clear the need info from me, since Alessio touched on the most important point - shoppingSurfaceOnboardingDisplayed needs to be a Glean event to facilitate funnel analysis later.

Regarding how to record the event in the Ping Center, having a separate message_id for different retailers makes sense to me (and if it's the simplest way to add the distinction between retailers, let's go for it).

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

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.

Fortunately, this is already happening. All the messaging system telemetry is being automatically sent to both PingCentre and Glean.

@Alessio, you also brought up in one of the comments to the tech plan that it may be required to send any telemetry of this nature of OHTTP, which it sounds like we want to resolve (probably by me pinging the right folks) before implementing here. I'll be keeping on that doc and driving as necessary.

Comment 5

[Alessio Placitelli [:Dexter]]

(In reply to Dan Mosedale (:dmosedale, :dmose) from comment #4)

@Alessio, you also brought up in one of the comments to the tech plan that it may be required to send any telemetry of this nature of OHTTP, which it sounds like we want to resolve (probably by me pinging the right folks) before implementing here. I'll be keeping on that doc and driving as necessary.

Perry will be implementing the event we need without the retailer id, because regular telemetry cannot send it. If the retailer id is needed, additional data needs to be submitted via OHTTP. Our team is not responsible for that, and the stakeholders needing that data should talk to Ted Cambel

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

After discussion with the PMs, this is not required for MVP. When this bug does get picked up, the next step will be reaching out to Ted Campbell, as per comment 5.

Comment 7

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

adjusting P4 bugs to P5, as the P4 priority is reserved for the Web Platform Test bot