1296013 - Search [telemetry]: Log usage of one-click search buttons in Search field

Status: NEW

(Firefox :: Search, task, P3)

Description

[Javaun Moradi [:javaun]]

This bug is for evaluation and scoping only. We are not ready to begin work as of 8/17/2016.

As part of an effort to better understand how users interact with the browser, we seek to better instrument the means of navigation and discovery. 

We have a spreadsheet full of bugs to add more Telemetry probes to browser nagivation surfaces, based on the events that can occur in each. 

This is one of a few sample bugs ready for discussion and estimation. Our goal is to assess whether more engineering breakdown is needed, or to estimate a level of work to add this probe. By extrapolating a few estimated bugs, the goal is to be able to estimate the work to do all Telemetry probes

====================
Requirements

Instrument the Search Bar to measure the event when a user performs a search using a one-click search (a one-off button). When this event happens, the metrics ping must record:

- Current Default search engine: of the user's machine
- Input mechanism: (keyboard, mouse) with which user actuated the query
- Query length: the user typed, 
- Total seconds to completion: time from when user started typing to when they actuate the search
- Engine chosen: Name of the engine chosen
- Numeric position:  of the One-Click Engine Icon in the panel engine position, - - Number of search suggest results: displayed to the user when they decided to click the one-click button. (Note: these suggestions come from Default Search Engine, not the one-click engine. 

NOTE: In all of these metrics above, we're only collecting quantitative metadata about how the navigation surface is used. We are not asking to record any information about what sites a user visits or what keywords they enter into a Search/Awesomebar field.

Comment 1

[Javaun Moradi [:javaun]]

One thing I should add here. We have a larger spreadsheet -- over 50 rows -- of things we want to instrument. This bug is just to estimate one-off searches in the Search field. We'd also want to instrument the one-off buttons in the about:newtab search field, the about:home search field, and (even though they're currently pref'ed off), the one-off buttons in the Awesome Bar. I'm assuming that's a different probe, hence a different bug. But maybe not.

Anyway, I think we can just estimate this here and talk about whether there's enough context above to be actionable. That's our main objective. If these look correct, we can share the rest of the spreadsheet (still in draft form) and talk about where we can combine some efforts, etc.

Comment 2

[:Gijs (he/him)]

I'm assuming the priority/component changes were accidental, as this still seems to be pretty clearly a search-related bug.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Javaun Moradi [:javaun] from comment #1)
> One thing I should add here. We have a larger spreadsheet -- over 50 rows --
> of things we want to instrument. This bug is just to estimate one-off
> searches in the Search field. We'd also want to instrument the one-off
> buttons in the about:newtab search field, the about:home search field, and
> (even though they're currently pref'ed off), the one-off buttons in the
> Awesome Bar. I'm assuming that's a different probe, hence a different bug.
> But maybe not.

I believe Drew went to great lengths to reuse the same components from both the search bar and the URL bar when implementing one-off buttons in the URL bar. Drew can you confirm, and do you see any issues with the list of requirements in comment 0?

Comment 4

[Drew Willcoxon :adw]

There are two one-off implementations: (1) for chrome, used by the search bar and urlbar, and (2) for content, used by about:home/newtab.  But, the search bar and urlbar have different code paths for actually loading URIs, so I think in total there may be four places to instrument: (1) the one-off code that's shared between the search bar and urlbar, (2) the search bar, (3) the urlbar, and (4) about:home/newtab (which use the same implementation).

We already do have some telemetry for all of these UIs in BrowserUITelemetry, but not all the things in comment 0.

Everything in comment 0 sounds straightforward to implement except possibly:

> - Total seconds to completion: time from when user started typing to when
> they actuate the search

We'd need to clearly define what we're gathering with this one I think.

Should we use UITelemetry for this?  I think I heard that that's going away, or maybe it was only BrowserUITelemetry.  Is there some other telemetry platform that's available?

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information