This adds a bunch of scalars to record navigational suggestions telemetry as
discussed with data science and described in the spec. These scalars are
different from the other Suggest ones because we want to record how nav
suggestions interact with the heuristic result. Unlike the existing scalars, the
keys of these new scalars are the types of heuristics that were shown when a nav
suggestion was or wasn't shown. One of the scalars is updated every time a nav
suggestion is *not* shown, and of course for most users that will be the vast
majority of the time or all the time, so I put all these scalars behind a Nimbus
variable. We'll set the variable to true in the control and treatment branches
of the nav suggestions experiment.
This patch also makes sure nav suggestions are recorded properly in Glean, as
`navigational`. I noticed that dynamic Wikipedia results are currently recorded
as `suggest_non_sponsor`, so I also added a new `dynamic_wikipedia` Glean type
for them. They're also recorded as `urlbar.picked.quicksuggest` in the legacy
telemetry, so I also changed it so they're recorded as
`urlbar.picked.dynamic_wikipedia`.
Currently for dynamic Wikipedia, the non-sponsored scalars are also incremented,
and I discussed with data science whether they and the sponsored scalars should
be incremented for all the new Suggest suggestion types we now have. We agreed
that they should be reserved for the usual partner sponsored and expanded
Wikipedia suggestions, and they should not be used for these new Suggest types,
so this patch also makes that change, and it does not update the non-sponsored
scalars for nav suggestions either.
The other major change this makes is to add a new `subtype` property to quick
suggest result payloads. I think we need a clear, simple way to distinguish
between all these various Suggest suggestion types that doesn't depend on
examining different payload properties depending on the type.
Differential Revision: https://phabricator.services.mozilla.com/D171525
This patch modifies existing Glean urlbar abandonment, engagement, and
impression events by including a weather suggestion.
This patch also adds a new telemetry scalar url.picked.weather to the legacy
telemetry system.
Differential Revision: https://phabricator.services.mozilla.com/D169225
Add an histogram to measure time to recalculate a chunk, and a scalar to measure
the number of pages that must be recalculated.
Differential Revision: https://phabricator.services.mozilla.com/D169203
This adds telemetry to UrlbarView that records the following things related to
the zero-prefix view (i.e., the topsites view):
* Exposures: How many times the ZP view was shown
* Engagements: How many times a result was picked in the ZP view
* Abandonments: How many times the user abandoned the ZP view
* Dwell time: How long the user was shown the ZP view
I considered adding telemetry specifically for topsites instead of the ZP view
as a whole, but since we have plans to start showing other types of results in
the ZP view, I don't think it's a good idea to rely on one specific type of
result as a proxy for the view itself. What DS and Product want to know about is
the view itself: how many times it was shown, for how long, etc.
This also adds one related scalar related to weather suggestions that counts the
number of times it's shown. This is the same scalar I added in D164778 using a
different, more complex approach.
Depends on D164615
Differential Revision: https://phabricator.services.mozilla.com/D165253
Please see the bug for info. This revision changes the URL of the adaptive
history doc to the new published doc. Ultimately this doc should live in-tree
but until then this is a nice, simple improvement.
Differential Revision: https://phabricator.services.mozilla.com/D150516
This does several things:
* Add new scalars for blocked suggestions
* Record the impression custom telemetry ping when a suggestion is blocked
* Remove the code that gets the index of the quick suggest result when the
engagement telemetry is recorded. We can replace all that with simply
`result.rowIndex`, but we need to store the result we last added in a property
to do that, so I replaced `_addedResultInLastQuery` with
`_resultFromLastQuery`
* Modify the urlbar engagement telemetry event code by adding the following
`selType` values: "quicksuggest", "block". We can use the `selType` in the
quick suggest engagement telemetry code to determine whether the block button
or the main part of the row was clicked.
Depends on D143246
Differential Revision: https://phabricator.services.mozilla.com/D143254
This adds two new scalars for engagements and abandonments in the urlbar:
```
urlbar.engagement
urlbar.abandonment
```
We already have engagement event telemetry but it's preffed off by default, and
for the upcoming best match experiment, data science would prefer scalars so we
can easily measure total engagement volume. (See bug 1752953 comment 22.)
Recording simple scalars for engagements and abandonments in addition to the
optional event telemetry seems totally reasonable.
The existing `urlbar.picked.*` scalars are sort of proxies for engagement, but a
single scalar would make analysis easier, and there is no similar existing
scalar for abandonments.
This revision hooks into the `TelemetryEvent` class, but it records the scalars
regardless of `browser.urlbar.eventTelemetry.enabled` because there's no reason
to not always enable it.
Differential Revision: https://phabricator.services.mozilla.com/D140287
Now that we're likely not targeting a 94 dot release anymore, I'd like to go
ahead and rename the `suggest.quicksuggest` pref to
`suggest.quicksuggest.nonsponsored` as we considered doing before. There won't
be a better time to do it.
Depends on D128665
Differential Revision: https://phabricator.services.mozilla.com/D130565
This adds telemetry for the new data-collection pref:
* Adds a `data_collect_toggled` object to the `contextservices.quicksuggest`
telemetry event
* Adds the new pref to telemetry environment
Depends on D128661
Differential Revision: https://phabricator.services.mozilla.com/D128665
This adds a new categorical histogram called `FX_URLBAR_MERINO_RESPONSE`. There
are four categories per the discussion in the bug:
0: success
1: timeout
2: network_error
3: http_error
Only one value is recorded per fetch, so for example if Merino times out but
then later finishes successfully, we only record the timeout.
Depends on D129772
Differential Revision: https://phabricator.services.mozilla.com/D130530
This does a couple of things:
* Instead of using the `not_now` telemetry event object for the cases where the
dialog is closed by the Escape key or some other atypical way, reserve
`not_now` -- renamed `not_now_link` -- specifically for clicks on the "Not
now" link and add two new objects: `dismissed_escape_key` and
`dismissed_other`. That should give us a little better understanding of how
the dialog is being dismissed. The new `not_now_link` name is to avoid
conflation with the previous meaning of `not_now`.
* Add a new `browser.urlbar.quicksuggest.onboardingDialogChoice` pref that
stores exactly the same values as the telemetry event. e.g., if the dialog is
accepted, then we'll record a telemetry event whose object is `accept` and
we'll also store `accept` in the pref.
I figure if we decide to show the onboarding again for people who have already
seen it, (1) we'll use this pref to decide the flow for any given user, and (2)
we'll need to add another pref for the user's response to the "v2" dialog, or
maybe we could morph this one into an array of responses or something more
complex like that.
Differential Revision: https://phabricator.services.mozilla.com/D127354
The Jira ticket (link in the bug) calls for two separate checkboxes for Firefox
Suggest results: a main checkbox plus a sponsored-suggestions checkbox. The
sponsored-suggestions checkbox is subordinate to the main checkbox, i.e., the
main checkbox has to be checked to turn on sponsored suggestions. This will
allow users to toggle sponsored suggestions separately from non-sponsored
suggestions. It's a change from the current situation where we have only one
pref and checkbox that control both sponsored and non-sponsored suggestions.
So part 1 of fixing this bug is to add a new pref for sponsored suggestions.
This revision keeps the current `suggest.quicksuggest` pref as the main pref and
adds a new `suggest.quicksuggest.sponsored` pref. I confirmed with Natalie that
we want to enable both prefs when the user opts in through the onboarding
dialog.
We currently record a telemetry event when `suggest.quicksuggest` is toggled. We
also want a similar event for the new pref, so this adds one.
The pref situation for Firefox Suggest is confusing but in summary:
* `browser.urlbar.quicksuggest.enabled`: The global toggle for the entire
Firefox Suggest rollout involving sponsored and non-sponsored suggestions, the
related telemetry and preferences UI, etc. This pref can be overridden by the
`quickSuggestEnabled` Nimbus variable. If false, neither sponsored nor
non-sponsored suggestions will be shown. If true, then we look at the
individual `suggest.quicksuggest` and `suggest.quicksuggest.sponsored` prefs.
* `browser.urlbar.suggest.quicksuggest`: Whether any Firefox Suggest results are
shown. This must be true to show both non-sponsored and sponsored results.
* `browser.urlbar.suggest.quicksuggest.sponsored`: Whether sponsored Firefox
Suggest results are shown. Both this pref and `suggest.quicksuggest` must be
true to show sponsored results.
Differential Revision: https://phabricator.services.mozilla.com/D124300
This uses `TelemetryStopwatch` to record the time between the `fetch` start and
its resolve. The new histogram is `FX_URLBAR_MERINO_LATENCY_MS`.
Depends on D124132
Differential Revision: https://phabricator.services.mozilla.com/D123993
This patch also addresses bug 1645293. It essentially reverts parts 1 and 3 of bug 1616700 for users with searching disabled. Since we had to introduce branching behaviour, there are some new constructs like a shouldHandOffToSearchMode multi-pref in UrlbarPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D118606
This patch also addresses bug 1645293. It essentially reverts parts 1 and 3 of bug 1616700 for users with searching disabled. Since we had to introduce branching behaviour, there are some new constructs like a shouldHandOffToSearchMode multi-pref in UrlbarPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D118606
