Automattic / Automattic/pocket-casts-android
Reduce frequency of discover_list_impression tracking
- Dominant language
- Kotlin
- Stars
- 2.8k
- Forks
- 308
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 187
Description
`discover_list_episode_play` event gets fired multiple times when it shouldn't be.
## Example 1
This is what happens on tapping the play button on a single episode feature in the discover feed, without any scrolling interaction:
```
11:08:34.741 🔵 Tracked: discover_list_episode_play
11:08:34.853 🔵 Tracked: discover_list_impression
11:08:34.860 🔵 Tracked: discover_list_impression
11:08:34.885 🔵 Tracked: discover_list_impression
11:08:34.899 🔵 Tracked: discover_list_impression
11:08:34.906 🔵 Tracked: discover_list_impression
11:08:34.911 🔵 Tracked: discover_list_impression
11:08:34.967 🔵 Tracked: playback_play, Properties: {"source":"discover",...}
```
## Example 2
After opening up one of the featured podcasts from the discover screen, tapping the subscribe button fires off the following events even though the discover screen isn't visible either before or immediately after tapping the button:
```
11:13:33.413 🔵 Tracked: podcast_screen_toggle_summary
11:13:33.418 🔵 Tracked: podcast_screen_subscribe_tapped
11:13:33.580 🔵 Tracked: discover_list_impression
11:13:33.586 🔵 Tracked: discover_list_impression
11:13:33.592 🔵 Tracked: discover_list_impression
11:13:33.599 🔵 Tracked: discover_list_impression
```
Noticed in https://github.com/Automattic/pocket-casts-android/pull/345#discussion_r984697055
Note that
- This is how we were handling the event for Firebase.
- Only the unique impressions is the main value shown to the user. (p1664575119091089-slack-C02ATC80MUM)
Contributor guide
Research direction
Reproduce the two event sequences in the issue, then inspect the discover_list_impression tracking path and the discussion in pull request #345. Done means tapping play or subscribe does not emit repeated discover_list_impression events when the discover screen is not visibly changing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- analytics, mobile
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100