2049938 - Define and send fxa "personalization" ping containing existing probes

Status: RESOLVED FIXED

(Firefox :: Firefox Accounts, enhancement)

Description

[Mark Hammond [:markh] [:mhammond]]

We want to send a new ping, which in the initial instance will contain only existing probes which already have their own data reviews - high-level requirements, lower level requirements,

Comment 1

[Mark Hammond [:markh] [:mhammond]]

Attachment: Bug 2049938 - define and send new fxa personalization ping. r?mconley

Comment 2

[Jan-Erik Rediger [:janerik]]

From our discussion in chat:

Considering that it seems necessary to decouple it from the usual telemetry state, it's a bit more work to implement this.
The proposed way to just stick to enabling the ping when the account state is determined won't work, as some of the metrics that should go into this ping are recorded long before that state is known.

This alternative would work:
Add GleanPings.fxAccountsClientInfo.setEnabled(true); right as Glean is initialized here: https://searchfox.org/firefox-main/source/browser/components/StartupTelemetry.sys.mjs#139
That means the ping is always enabled. Or add some way there to be able to toggle it.
That's the only way to reliably get other metrics to be added to that ping: it needs to be enabled very early.
That may conflict with what we can actually do under our own data guidelines and what we tell the users. This might need to be double-checked again with data stewards.
This might need an explicit way to opt-out from this data collection.

You can then not rely on ping_schedule: [baseline] as this would always send the ping.
You need to manually submit the ping (GleanPings.fxAccountsClientInfo.submit()) at appropriate times.
Do you really need to have it on a schedule similar to the baseline ping? That might not even make sense, considering some of the data you want is lifetime: ping (e.g. client_association.uid or browser.is_user_default), that means if the value is set the next ping will have that value and then it will be cleared.
Given you don't control all the metrics and when the value is set you will get a lot of pings that won't even have those values.
There is no other default way to stick to the baseline schedule. I wouldn't recommend sticking to it.
Which means you will now need to implement your own trigger (time-based, action-based, etc.)

Comment 3

[Mark Hammond [:markh] [:mhammond]]

Thanks for the followup. A couple of questions:

Do you really need to have it on a schedule similar to the baseline ping?

I don't think so. The intent of this data is that it be used in emails so we can customize the emails depending on the data - eg, we might want to send emails to people to haven't set it as their default with a message customized for that case.

So anything that's "somewhat regular" seems like it would be fine.

That might not even make sense, considering some of the data you want is lifetime: ping (e.g. client_association.uid or browser.is_user_default), that means if the value is set the next ping will have that value and then it will be cleared.

But as above, it's safe to assume the intent is that the ping will have the data we care about :) What do you suggest here? How can we be sure this new ping has the data we have configured it to have?

Comment 4

[Jan-Erik Rediger [:janerik]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #3)

But as above, it's safe to assume the intent is that the ping will have the data we care about :) What do you suggest here? How can we be sure this new ping has the data we have configured it to have?

There's two options:

1. You verify when each of the metrics you want in there are set and you make sure to only send the ping after that data is set. There's no automatic way to do it, this means reading and understanding how that data is collected.
2. You record the data you need into new metrics (possibly just duplications of the ones you wanted) that only go into your ping. You add instrumentation to collect that data at appropriate times. You pick a lifetime that's appropriate for your use case.

In any case this new data collection will require data review. That will also require do be done in a public bug.

Comment 5

[Jan-Erik Rediger [:janerik]]

Oh other things Travis has reminded me off and so that we don't forget:

1. Because this ping does contain an ID, it needs to hook into shredder to have its data deleted upon an opt-out (how that opt-out is done is still not decided, right?)
2. I assume access to the dataset that comes out of this will need to be restricted? Please don't forget this as this makes progress.

Comment 6

[MarniePW [:marnie]]

Comment on attachment 9600694 [details]
Bug 2049938 - define and send new fxa personalization ping. r?mconley

Final data review needed from a Data Steward, please.

Comment 7

[Chris H-C :chutten]

The Sensitive Data Collection Review process appears to still be in-progress. Or, at least, no final determination has been made on the e-mail thread with subject "Data review for "fxa personalization" ping" (last update from Aug 4).

Marnie, has the process completed without a post to the thread?

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/995eddcd7d07
https://hg.mozilla.org/integration/autoland/rev/ca3932a4a463
define and send new fxa personalization ping. r=mconley,data-stewards

Comment 9

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/ca3932a4a463