1046859 - Add telemetry flag for search suggestion opt-in

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Richard Newman [:rnewman]]

These are things we'd like to know. We can approximately figure this out from FHR by looking to see users who've issued suggested searches, but that doesn't tell us if their locale simply doesn't have a suggest-enabled default engine.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: optin-telemetry v0.1

I went with an Event.ACTION, but I could be swayed to something else. I considered creating Event.OPT_IN on the off chance there could be more opt-ins we would want to track as a group.

If we wanted that approach we could use:
Event.OPT_IN, Method.BUTTON, "suggestions_yes" | "suggestions_no"

Given that I went with:
Event.ACTION, Method.BUTTON, "suggestions_yes" | "suggestions_no"

I went with "suggestions_*" because it is the R.id of the buttons and for ACTIONs we pass the R.id of the button or menu. I am wondering if I should use "search_suggestions_*" to make it more contextual.

Thoughts?

Comment 2

[Richard Newman [:rnewman]]

mfinkle: why not a 'real' telemetry flag for offered/accepted, a la Bug 1013024?

This is what we did there:


  "FENNEC_DISTRIBUTION_REFERRER_INVALID": {
    "expires_in_version": "never",
    "kind": "flag",
    "description": "Whether the referrer intent specified an invalid distribution name",
    "cpp_guard": "ANDROID"
  },


set via

            Telemetry.HistogramAdd(HISTOGRAM_CODE_CATEGORY, CODE_CATEGORY_FETCH_INVALID_CONTENT_TYPE);

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Richard Newman [:rnewman] from comment #2)
> mfinkle: why not a 'real' telemetry flag for offered/accepted, a la Bug
> 1013024?

Because this is more strictly UI related. It's tracking what people do in the UI.

Comment 4

[Chenxia Liu [:liuche]]

Comment on attachment 8465743 [details] [diff] [review]
optin-telemetry v0.1

Review of attachment 8465743 [details] [diff] [review]:
-----------------------------------------------------------------

I would be more specific than just ACTION but I also think that OPT_IN might be too specific. What about something like USER_OPTION (USER_SELECTION? USER_CHOICE?) which would be more generic than just a specific opt-in, and signifies some sort explicit choice instead of just an "action"?

If you don't want to make another method, I'd just stick with ACTION.

Comment 5

[:Margaret Leibovic]

I should also add a probe to my patch for bug 1007523 to track whether or not users change this in the settings UI.

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/9e38b1048c07

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

Wow. Took me 1.5 years to land this patch :(

In particular, we need this probe to track effectiveness of the onboarding in our funnel analysis.

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9e38b1048c07

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 8465743 [details] [diff] [review]
optin-telemetry v0.1

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Hurts general telemetry, but also the current A/B onboarding test since we want to see if more people are using suggestions.
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: Low. Simple probe addition
[String/UUID change made/needed]: None

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8465743 [details] [diff] [review]
optin-telemetry v0.1

Better late than never. Approved for uplift to aurora and beta

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/eb8dbc898f06

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/eb8dbc898f06

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1c5a31a3e01c