[Telemetry] Download events

[vesta0]

Description & Product Manager / Data Scientist User Story

As a product manager, I need to know how often something is downloaded using the browser, so I can appropriately prioritize enhancing the download experience in relation to other features.

What questions will you answer with this data?

-What percentage of total and weekly active users download a file using the browser? (e.g. 7% of total users and 5% of weekly active users download a file)

-How often do users download a file? (e.g. 3 % of users download a file every day, 2% of users download 3 files a week.)

Note: we track the interactions with download notifications but I don't believe we track the actual download events.

Acceptance Criteria

• ENG files a DS JIRA request outlining their methodology.
• DS sign off on instrumentation methodology addressing product questions.
• Event pings can be queried via re:dash
• Event pings can be queried via amplitude
• We are sending telemetry events for the actions listed in the requirements
• We have documented the telemetry
• We have asked a data steward to review the telemetry

┆Issue is synchronized with this Jira Task

[sblatz]

@vesta0

"Note: we track the interactions with download notifications but I don't believe we track the actual download events."

Are these meaningfully different? notifications will always appear for users when a download begins, finishes, or fails.

[sblatz]

Ah! One case where they're different:

Long press image -> contextual menu -> save image. Triggers a download but does NOT trigger a "download notification" until it's saved.

[sblatz]

So we should add events firing for downloads.

[liuche]

Eng needs to file the DS Jira bug for this.

[eliserichards]

This has been approved by Marissa during our all hands Telemetry Jam, so we don't need to file a ticket for this.

[Mugurell]

Talked offline with Kate who confirmed with DS and Boek:

• The newly added metrics should log events, not counters anymore
• An expiration date 6 months is preferred.
  Maybe if there is already related telemetry for that part of the screen / feature we can reuse the existing expiration date so that all related telemetry probes will be renewed at the same time.

[AndiAJ]

Hi, I've just checked this matter on the latest Nightly 201216 using a Google Pixel 3a (Android 11) and it seems that the download_added event type ping is generated.

@Mugurell please review

[Mugurell]

Thank you @AndiAJ.
The changes should now be available to test in the current Nightly.

[lobontiumira]

Verified as fixed on the latest Nightly build from 12/18 with Google Pixel (Android 10):

 {
          "category": "downloads_misc",
          "name": "download_added",
          "timestamp": 3279
        }

Logcat
Glean dashboard