Many moons ago, in Bug 1703318, we elected not to include the Glean client ID in background-update pings. The reasoning was that the default browsing profile (Legacy) telemetry client ID was included, so the Glean client ID was superfluous.

Now, we are sending events pings in addition to background-update pings, and events pings do have the Glean client ID and do not have the telemetry client ID. That's not helpful at all: it prevents joining the events data.

In addition, it means that the Glean sample_id is null, which slows down query development.

Finally, we should also include a reason in the submit invocation so that we can differentiate pings belatedly sent at startup from pings sent at the end of the background update task.

Including the Glean client ID allows to join the background update
metrics ping to Glean events pings, something we can't currently
do.

This allows to differentiate pings sent as part of the task and pings
queued and sent by Glean, potentially on a different schedule. This
might have helped debug some incoming data issues a while back.

Including the Legacy client ID allows us to more easily join events
pings to Legacy telemetry.

Comment on attachment 9307237 [details]
1794053-data-review-1.md

Redirecting this data review request to me

Comment on attachment 9307237 [details]
1794053-data-review-1.md

Data Review Form

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

   • Yes, through the Glean Dictionary

2. Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism) Provide details as to the control mechanism available.

   • Yes, through the normal telemetry opt-out.

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

   • Yes, this a permanent annotation. It will be monitored by install-update@mozilla.com.

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

   • This data is technical (category 1) but it is also highly sensitive. This does not require escalation since this is already escalated/approved in other requests.

5. Is the data collection request for default-on or default-off?

   • Default-on.

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

   • No

7. Is the data collection covered by the existing Firefox privacy notice?

   • Yes

8. Does the data collection use a third-party collection tool? If yes, escalate to legal.

   • No

Result

data-review+

:nalexander sorry for the delay, I wanted to double check with the others that this didn't need an escalation :)

https://hg.mozilla.org/mozilla-central/rev/68c335f14ee7

Comment on attachment 9307002 [details]
Bug 1794053 - Include Glean client ID and reason in background-update pings; include Legacy client ID in more pings. r?chutten

Beta/Release Uplift Approval Request

• User impact if declined: None.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This only adds some data to existing background update related pings. However, the data is necessary in order to analyze background messaging experiments, which we want to run in mid-January.
• String changes made/needed:
• Is Android affected?: No

Comment on attachment 9307002 [details]
Bug 1794053 - Include Glean client ID and reason in background-update pings; include Legacy client ID in more pings. r?chutten

Approved for 109.0b9.

https://hg.mozilla.org/releases/mozilla-beta/rev/dee826481d71