Skip to content
This repository has been archived by the owner on Jan 12, 2023. It is now read-only.

For #4967 - Record search / ads providers appearing in search results #4968

Merged
merged 1 commit into from
Jul 26, 2021
Merged

For #4967 - Record search / ads providers appearing in search results #4968

merged 1 commit into from
Jul 26, 2021

Conversation

Mugurell
Copy link
Contributor

@Mugurell Mugurell commented Jul 2, 2021

This brings the ads/search telemetry up to par with Fenix.

@Mugurell
Copy link
Contributor Author

Mugurell commented Jul 2, 2021

Request for data collection review form

All questions are mandatory. You must receive review from a data steward peer on your responses to these questions before shipping new data collection.

  1. What questions will you answer with this data?
  • These probes will be used to better model high-level trends in revenue prediction. They will also be used going forward as a standard metric (the way search volume is now) to understand the revenue impact of new prospective features.
  1. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?
  • This measure helps Mozilla better understand revenue trends and (potentially) aids future forecasting. It also helps us have confidence on the revenue impact of features. This does not mean Mozilla would withold a feature that reduces search revenue, it merely helps us quantify it. On the contrary: right now it is difficult to really understand the revenue impact of new features, and in the absence of evidence it is very difficult to justify some needed changes.
  1. What alternative methods did you consider to answer these questions? Why were they not sufficient?
  • No current alternative methods.
  1. Can current instrumentation answer these questions?
  • Currently there are no events to track this.
  1. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.
Measurement Description Data Collection Category Tracking Bug #
A specific Search Engine Results Page was displayed category 2 - interaction data #4967
Ads are shown on a specific Search Engine Results Page category 2 - interaction data #4967
User clicked on an ad from a specific Search Engine Results Page category 2 - interaction data #4967
  1. How long will this data be collected?
  • Until 2022-07-01
  1. What populations will you measure?
  • All release, beta, and nightly users with telemetry enabled.
  1. Please provide a general description of how you will analyze this data.
  • Glean
  1. Where do you intend to share the results of your analysis?
  • Only on Glean and with mobile teams.

@Mugurell
Copy link
Contributor Author

Mugurell commented Jul 2, 2021

Setting do-not-land to update the metrics documentation with the telemetry renewal review first.

@Mugurell Mugurell added the do not land PRs that requires coordination before landing label Jul 2, 2021
@@ -79,7 +80,9 @@ class GleanMetricsService(context: Context) : MetricsService {
private fun collectPrefMetrics(
components: Components,
settings: Settings
) = CoroutineScope(IO).async {
) = CoroutineScope(Main).async {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise I'd get a java.lang.IllegalThreadStateException: Must have a Handler the same as was seen in mozilla-mobile/fenix#17045

@travis79
Copy link
Member

1. **List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox [data c](https://wiki.mozilla.org/Firefox/Data_Collection)[ollection ](https://wiki.mozilla.org/Firefox/Data_Collection)[categories](https://wiki.mozilla.org/Firefox/Data_Collection) found on the Mozilla wiki.**


* All data is Category 2, maybe Category 3 if we consider ads as `categories of webpages visited over time`.

@Mugurell

A couple of quick requests, neither of which block me being able to perform the review at this time:

Can you please edit your comment to list out the metrics being added here? The review form asks for this in tabular form but just a simple list that includes the "measurement description", the "data collection category" should be sufficent (and any links to other issues or bugs). From a stewarding standpoint, I happened to know how to find this in the metrics.yaml file but it is preferred that the newly added metrics are listed explicitly in the review request.

Also, I would say that this is not Category 3 data since they are only the counts being recorded and not the specific ad or url. I think this should be Category 2, User Interaction data.

And finally:

Data Review

  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 metrics.yaml file and the Glean Dictionary

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

Yes, through the Send Usage Data preference in the app settings.

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

N/A, collection set to expire 2022-07-01

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

Category 2, User Interaction or lower

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

Default-on

  1. Does the instrumentation include the addition of any new identifiers?

No

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

Yes

  1. Does the data collection use a third-party collection tool?

No

Result

data-review+

@Mugurell Mugurell added 🕵️‍♀️ needs review PRs that need to be reviewed and removed do not land PRs that requires coordination before landing labels Jul 16, 2021
) = CoroutineScope(IO).async {
) = CoroutineScope(Main).async {
// Doing this on Main because this might be the first time BrowserStore is accessed and initialized
// and this needs to be done on the Main thread.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, the comment is a bit misleading, the Store can be used on any thread, but the new install() calls can't.

The whole pattern here is confusing to me, we launch a separate coroutine with the same dispatcher (and an unbound scope) and then await it immediately. Why? 🤔

I wonder if we could move the install() calls into initialize() here, before launching the coroutine, making this more explicit here? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. Will look into this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked to be a great solution! Thank you!

@@ -47,6 +48,7 @@ open class FocusApplication : LocaleAwareApplication(), CoroutineScope {

TelemetryWrapper.init(this)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be nice to only initialize all these only if isTelemetryEnabled() and then observe changes and if the users enable telemetry do the initialization or immediately stop the functionality?
Currently the first two will do their own isTelemetryEnabled() check and abort the initialization but the FactsProcessor won't.

@Mugurell
Copy link
Contributor Author

Understood from Amedyne that this will have to also be uplifted to 91. (after testing)

@Mugurell Mugurell added pr:needs-ac-bump PR that needs a AC bump and removed 🕵️‍♀️ needs review PRs that need to be reviewed labels Jul 23, 2021
@jonalmeida
Copy link
Contributor

org.mozilla.focus.activity.ThreeDotMainMenuTest > browserMenuItemsTest[test(AVD) - 9] FAILED
androidx.test.espresso.NoMatchingViewException: No views in hierarchy found matching: with id: org.mozilla.focus.debug:id/settings

Task :app:connectedFocusDebugAndroidTest FAILED

UI test failure; restarting in case it's intermittent.

@jonalmeida jonalmeida closed this Jul 24, 2021
@jonalmeida jonalmeida reopened this Jul 24, 2021
This brings the ads/search telemetry up to par with Fenix.
@Mugurell
Copy link
Contributor Author

Rebased on the current main.

@Mugurell Mugurell added the 🛬 needs landing PRs that are ready to land label Jul 26, 2021
@mergify mergify bot merged commit 3ce7235 into mozilla-mobile:main Jul 26, 2021
@Mugurell Mugurell deleted the 4967Telemetry branch July 27, 2021 07:15
@jonalmeida
Copy link
Contributor

@Mergifyio backport releases_v91.0

@mergify
Copy link
Contributor

mergify bot commented Aug 16, 2021

Command backport releases_v91.0: success

Backports have been created

@jonalmeida
Copy link
Contributor

@Mergifyio backport releases_v91.0

Oops, this was supposed to be 92.

@jonalmeida
Copy link
Contributor

@Mergifyio backport releases_v92.0

@mergify
Copy link
Contributor

mergify bot commented Aug 16, 2021

Command backport releases_v91.0: success

Backports have been created

@mergify
Copy link
Contributor

mergify bot commented Aug 16, 2021

Command backport releases_v92.0: success

Backports have been created

@Mugurell Mugurell restored the 4967Telemetry branch June 14, 2022 17:22
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🛬 needs landing PRs that are ready to land pr:needs-ac-bump PR that needs a AC bump
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants