-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Telemetry for Bookmarks #974
Comments
Yes. That's a great issue by the way (never thought I would write that) – maybe add something about sync, or is this a separate issue? Looking forward to learn more about the features. Thanks! |
The part about "detect anomalies or issues" is interesting.
This is interesting to look at. I assume this would require:
|
I'm relying on Amplitude here
I'm relying on Amplitude here |
I am reviewing this from a data science perspective, asking whether this proposal is going to make it easy for me and other DSes to do our jobs and meet expectations once it's implemented. I'm not a data steward. The probes seem well defined to me - I would change "Clicked edit label after bookmark was created" to "Clicked edit label", so that when the telemetry is being implemented there is no ambiguity about whether a click on the edit label is only recorded if it's immediately after the bookmark was created. Most of the questions seem well defined too. The only problem I noticed is that "How do people arrive" is going to be hard to work out. I don't think Firefox Desktop or Glean have a telemetry pattern for following users paths through the products. Whether we want such a pattern, what % of users we need this data from, and how it fits with our lean data principles is worth discussing at some point; that could be a big discussion. One systematic way to work out "how do people arrive" would be to do something like sending navigation events for every visited part of the app - a DS can then sort these by timestamp to determine the user's path through the app. Any non-instrumented parts would introduce invisible gaps in the path. If we want to go down that path then we should put some thought into this system rather than immediately pursuing with the approach with which I am most familiar! The ad-hoc, one-off solution would be to do something specific to the bookmark list: exhaustively work out all the paths to the bookmark list then send an event on loading the bookmark list specifying which path was used. Separately, I'm not sure that regularly auto-refreshing dashboards are appropriate here - to me this smells more like a one-off report (to be re-run whenever the subject is revisited), or telemetry that gets used in an experiment. But I haven't seen the roadmap for bookmarks. |
Thanks @felixlawrence
I would be relying on Amplitude for this, however comment #974 (comment) makes this obsolete (removing it from the description now) |
r+ then! |
I think the above list of probes drastically undercounts the available UX features to interact with for bookmarks. Should I add to the list of probes as I feel is appropriate? |
@colintheshots please add them |
There is telemetry for most of the bookmark management options except for when deleting a folder. @colintheshots Could you look into this? |
@colintheshots we can add telemetry for deleting a folder post-mvp if you haven't done it already. |
@vesta0 Yes, we can add it post-MVP. This is still labeled a release blocker though. |
I didn't want to break it apart if it was already in progress but based on feedback from @colintheshots and @bsurd I think we can close this issue and track the remaining work here: #3174 |
As a product owner, I want to track the usage of bookmarks in Fenix so that I can understand how our users leverage the feature, and detect anomalies or issues in user flow and usage.
Hypothesis
We believe this feature is useful to users, and successful when
What questions will you answer with this data?
Probes
Dependencies (Added by PM and Eng)
Acceptance Criteria (Added by PM)
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: