1300104 - Kick off the work on the "page load broken down by action" probe

Status: RESOLVED FIXED

(Toolkit :: Telemetry, defect, P1)

Description

[Alessio Placitelli [:Dexter]]

Bug 1295932 discusses the implementation of the probe which is meant to measure the number of times per "session fragment" a page is loaded as a result of any action, broken out by action.

Since this is touching different components, we should:

- break down the work in different bugs;
- prioritize the work;
- ask for suggestion about the design to each component owner/peer, if needed.

Comment 1

[Georg Fritzsche [:gfritzsche]]

We also should check for overlap with the planned search metrics:
https://docs.google.com/spreadsheets/d/1gDQbcKkMC1qj75DRsN5t5IkRs5oWMUxRYUnXflybJWw/

Comment 2

[Alessio Placitelli [:Dexter]]

Bug 1295932 is too broad and contains to much work to land it on a single go, so we should probably proceed by implementing it incrementally.

To make that happen, the list from bug 1295932 comment 1 should be split and prioritized. We could split the work by components (e.g. awesomebar, bookmarks, etc.) or by aspect (e.g. performing a search from FF ui, using the awesomebar, etc.).

Brednan, Rebecca, would that work for you? Do you have any input on how to split the work and the prioritization?

Comment 3

[brendan c]

Agreed Alessio it's a lot for one bug.

I have some preferences regarding prioritization (which is basically that breadth first is better than depth first -- having not-very-detailed but comprehensive data soon would be better than having fine-grained data about just one UI surface (i.e. awesomebar)), but I think we're also open to taking cues from you since we don't know what the hardest bits of the implementation will be, so we're probably comfortable taking low-hanging fruit when possible rather than sticking to a strict priority list. So if you have any initial thoughts about what might be the easiest thing to get out the door quickly.

To provide some more detail of what my preference would be WRT a "breadth first" prioritization (and for now using the nomenclature i mentioned in Bug 1295932 (which we can change of course)), i think i'd want us to get as quickly as possible to a comprehensive enumeration of pageloads triggered by way of interaction with each possible UI surface, i.e. sprint towards filling engagement.navigation with the top level items in that list, something like --

awesomebar.not_specified
searchbar.not_specified
in_content.not_specified
menubar.not_specified
bookmark_bar.not_specified
back_fwd_btns.not_specified
about_newtab.not_specified
activity_stream.not_specified (q: how do we deal with addons that trigger pageloads in general?)
external_application.not_specified
session_restored.not_specified
other_page_load

--and then expanding these out, i.e. awesomebar.not_specified to
awesomebar.search
awesomebar.history
awesomebar.bookmark
awesomebar.other_tab
awesomebar.dropdown_click
awesomebar.not_specified

Of course, this may not match up with the actual experience of writing the probes, so mixing a breadth first strategy with some opportunistic greedyness makes sense-- if you're in the code for awesomebar pageloads and it's easy to break out for example searches and dropdown clicks, we could add those immediately and then circle back later to get the other details.

And I guess it's also worth mentioning that Javaun is particularly interested and engaged, so all else being equal, we'd want to prioritize search-related metrics. (but we don't need to throw all of our effort there if it's hard).

Does this type of approach make sense?

Comment 4

[Alessio Placitelli [:Dexter]]

(In reply to brendan c from comment #3)
> And I guess it's also worth mentioning that Javaun is particularly
> interested and engaged, so all else being equal, we'd want to prioritize
> search-related metrics. (but we don't need to throw all of our effort there
> if it's hard).
> 
> Does this type of approach make sense?

Thanks Brendan, that's great input, and it makes much sense! It also makes sense to prioritize search-related metrics, as code-wise we should have a clearer path to catch the interesting actions we need to track. We could use that as a means to pin down the probe format and module design. Implementing the "not_specified" part for each component should come as part of that bug or right after.

I've filed bug 1303333 to track the work on the search-metrics.

Comment 5

[[e-mail]]

I agree with Brendan's comments above, as well as prioritizing search-related metrics first.

Comment 6

[Alessio Placitelli [:Dexter]]

Closing this as fixed, the conversation allowed me to spawn the bugs to take on the work.