1508305 - Implement the "app_build_id" and "app_display_version" fields of the "ping_info" section

Status: RESOLVED FIXED

(Toolkit :: Telemetry, enhancement, P1)

Description

[Alessio Placitelli [:Dexter]]

This bug is about defining the meaning of the "app_build" field in the "ping_info" section of glean's pings:

- how should it look like?
- should developers provide this through the `Configuration`?
- should we attempt to generate a meaningful value by checking the app name?

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Couple of thoughts ... there is the user visible version (1.0.3) and also a build number from the CI system (1234). Both are very important to know.

Some apps (like fenix or reference browser) also have additional components with a version number. For example GeckoView or the Application Services library. We don't care too much about dependencies usually, but I think specially those two will be really interesting to be able to query in dashboards.

"Give me this report and group it by geckoview version"

Comment 2

[Alessio Placitelli [:Dexter]]

(In reply to Stefan Arentz [:st3fan] from comment #1)

Couple of thoughts ... there is the user visible version (1.0.3) and also a build number from the CI system (1234). Both are very important to know.

Thanks Stefan. You definitely have a point here, looks like this slipped through the cracks. The core ping is sending, through the submission URL, both the appVersion and the appBuildId. With the current schema, we'd just be sending app_build (matching with the appBuildId for the core ping).

I propose adding the following fields to the ping_info section of all the glean pings:

• app_build_id: the build number/string from the CI system (a string, e.g. "1234/A")
• app_display_version: the user visible version string (a string, e.g. "1.0.3")
• app_release_channel (optional): the name of the release channel the application is on, if the definition applies (e.g. "beta", "release", "nightly", ...). As far as I understood, some applications don't use release channels so this field wouldn't be present for them.

@Georg, Frank - What do you think? Should we consider sending this as part of the submission URL instead, as with the usual telemetry? Or it's not useful?

Some apps (like fenix or reference browser) also have additional components with a version number. For example GeckoView or the Application Services library. We don't care too much about dependencies usually, but I think specially those two will be really interesting to be able to query in dashboards.

"Give me this report and group it by geckoview version"

@Stefan, Do you know what kind of analyses would this support? I'm thinking that this should probably be in the metrics/baseline ping, but not in the ping_info section.

@Georg, Frank - thoughts?

Comment 3

[Georg Fritzsche [:gfritzsche]]

(In reply to Alessio Placitelli [:Dexter] from comment #2)

(In reply to Stefan Arentz [:st3fan] from comment #1)

Couple of thoughts ... there is the user visible version (1.0.3) and also a build number from the CI system (1234). Both are very important to know.

Thanks Stefan. You definitely have a point here, looks like this slipped through the cracks. The core ping is sending, through the submission URL, both the appVersion and the appBuildId. With the current schema, we'd just be sending app_build (matching with the appBuildId for the core ping).

I propose adding the following fields to the ping_info section of all the glean pings:

• app_build_id: the build number/string from the CI system (a string, e.g. "1234/A")
• app_display_version: the user visible version string (a string, e.g. "1.0.3")

+1 to those.

• app_release_channel (optional): the name of the release channel the application is on, if the definition applies (e.g. "beta", "release", "nightly", ...). As far as I understood, some applications don't use release channels so this field wouldn't be present for them.

This is a little harder to generalize. We might want to break that out into a different bug.

Some apps (like fenix or reference browser) also have additional components with a version number. For example GeckoView or the Application Services library. We don't care too much about dependencies usually, but I think specially those two will be really interesting to be able to query in dashboards.

"Give me this report and group it by geckoview version"

@Stefan, Do you know what kind of analyses would this support? I'm thinking that this should probably be in the metrics/baseline ping, but not in the ping_info section.

@Georg, Frank - thoughts?

+1, this is not something that should generally be in the ping_info section.

We could put this into the baseline or metrics ping, depending on where it is important.

Comment 4

[Megan McCorquodale]

@dexter I use all three of app_build_id, app_display_version and app_release_channel in my analyses, so I'd like to see all of these metrics (likely in the baseline ping?) - but where they should live I'll leave up to you.

Comment 5

[Alessio Placitelli [:Dexter]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #3)

• app_release_channel (optional): the name of the release channel the application is on, if the definition applies (e.g. "beta", "release", "nightly", ...). As far as I understood, some applications don't use release channels so this field wouldn't be present for them.

This is a little harder to generalize. We might want to break that out into a different bug.

I filed bug 1520741 for that.

(In reply to Megan McCorquodale from comment #4)

@dexter I use all three of app_build_id, app_display_version and app_release_channel in my analyses, so I'd like to see all of these metrics (likely in the baseline ping?) - but where they should live I'll leave up to you.

Cool, thanks Megan!

Comment 6

[Alessio Placitelli [:Dexter]]

Attachment: Schemas Update PR

Comment 7

[Alessio Placitelli [:Dexter]]

Attachment: Implementation PR

Comment 8

[Alessio Placitelli [:Dexter]]

Attachment: Data-Review request

data-review?chutten as liuche is on PTO.

This is the data-review request for adding the new appDisplayVersion field to the ping_info section of all the pings sent by glean.

The documentation is linked within the data-review request.

Comment 9

[Chris H-C :chutten]

Comment on attachment 9038193 [details]
Data-Review request

Preliminary note:

The app_build_id collection added in the attached patch was previously reviewed as part of the baseline ping. This review is for app_display_version.

DATA COLLECTION REVIEW RESPONSE:

    Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. This collection is documented [here](https://github.com/mozilla-mobile/android-components/blob/8042bf473da8f23c509f2aac46ac7d51d525fc52/components/service/glean/docs/pings.md).

    Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. All glean-embedding applications are required to furnish one.

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

This is part of the base set of information sent by glean-embedding applications so is up to them.

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

Category 1, Technical.

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

This is up to the embedding application.

    Does the instrumentation include the addition of any new identifiers?

Yes, the build-time identifier of the "App Display Version". It aims to identify the app's version.

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

Yes.

    Does there need to be a check-in in the future to determine whether to renew the data?

No.

---
Result: datareview+

Comment 10

[Alessio Placitelli [:Dexter]]

Everything was reviewed and merged.