Closed Bug 1278301 Opened 4 years ago Closed 3 years ago

Exclude desktop-only history from Top Sites

Categories

(Firefox for Android :: Awesomescreen, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
Firefox 50
Tracking Status
fennec 49+ ---
firefox50 --- fixed

People

(Reporter: Margaret, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

I've been hearing feedback that some people are still seeing pages in their top sites that they have only visited on desktop.

I'd have to agree - 3 of my top sites tiles are gmail pages, and 2 are twitter (I use the native app on my phone).

We should evaluate the effectiveness of the current algorithm, and possibly tweak it to further exclude desktop history.

Barbara, can you help set a direction here?
Flags: needinfo?(bbermes)
Some quick thoughts on this:

- Following along the same lines of the current approach, we might tweak the weighting of visits such that local visits are prioritized even further. I did some quick charts for Bug 1265525 to help visualize various frecency values - e.g. https://bug1265525.bmoattachments.org/attachment.cgi?id=8745795 (blue line is remote).
- From the charts, it feels like what we're doing is OK, but perhaps they're not exploring situations which actually occur for people - I'd be interested in better understanding visit distribution on mobile. Perhaps it's the case that for a lot of people it's just too skewed toward a long-tail pattern of browsing, in which case current approach is very much non-ideal.
- We should explore actively excluding some or all "just remote" history, or history that is primarily remote (e.g. 1 local visit vs 20 remote); that seems like a somewhat controversial topic, and also not without potential technical pitfalls.

I feel that we need more telemetry around top sites which we display to help us drive this better. I'll think about what that might be.
Thanks Grisha, that's a good start to optimize this. 

As or telemetry, could we have these sites tagged with where they came from (Desktop/mobile) and see how many people click or delete them from the top sites panel. That'd help, no?
Flags: needinfo?(bbermes)
tracking-fennec: ? → +
Overriding this ruling to say we should deal with this as part of shipping bug 1265525.

Let's talk with product/UX to figure out what data we need to make a decision here, and what that decision should be.
Assignee: nobody → gkruglov
tracking-fennec: + → 48+
We are going to keep this on 49, not uplift to 48.

In the funnel meeting on Monday we discussed changing the algorithm to exclude desktop-only sites from your top sites. We'll need to be careful to make sure this doesn't affect searching in the awesomebar (this should only affect the top sites panel).

Anthony, did you and Grisha talk about this?
tracking-fennec: 48+ → 49+
Flags: needinfo?(alam)
Summary: Refine top sites local visit prioritization algorithm → Exclude desktop-only history from Top Sites
Very simple change, dramatic results!
Comment on attachment 8766114 [details]
Backed out changeset 5e2a5623088f (bug 1278301) because this feature is pending further investigation

https://reviewboard.mozilla.org/r/61138/#review58084
Attachment #8766114 - Flags: review?(s.kaspari) → review+
https://hg.mozilla.org/integration/fx-team/rev/5e2a5623088f114559c36a769dbea5cab6dc1e6a
Bug 1278301 - Exclude history items from Top Sites which were not visited locally r=sebastian
Looking back at Barbara's comment 2. I actually think we should try to address that first. 

Have we measured if people are actually engaging with these tiles? 

I agree, these aren't personally exciting for myself and my own use cases. But things like Activity Stream actually take advantage of these inter-device connections. Seeing multiple "Gmail.com" and "twitter.com" tiles is not ideal, but I'm also not convinced that excluding all of the desktop-only history is the right path forward right now.

Barbara, how do you feel about this? Would it make more sense to hold off until we get some data? Or, I would suggest collapsing/grouping in a way that's similar to Activity Stream. That is, make sure we only have 1 "gmail" tile and 1 "twitter" tile as opposed to 2 or 3.
Flags: needinfo?(alam) → needinfo?(bbermes)
We *must* get data.

We could put it behind a switchboard flag to gather data before making this fully available to people.

As for the grouping idea, seems reasonable, but which one would take precedence?
a) Destop: twitter.com/bbinto/status/1239403030303
b) Mobile: twitter.com/bbinto/

>> but I'm also not convinced that excluding all of the desktop-only history is the right path forward right now.
Why is that concerning to you, it's a clear signal that the user seems to just visit that page on desktop, in this case, to be on the safe side, I'd rather not show it than show it.

This all brings up a good question; are we trying to replicate Activity stream? If so, then we should use the same logic, however if not (which I assume is the case), we could test a few variations via switchboard to really understand what the user prefers. Right now, we are just "guessing".

So to summarize, my proposal as a start
- Add probes
- Add switchboard flag for e.g. 50% of users with no desktop-only history 
- Compare cohort with control, if we don't see much uptake in engagement (% increase of loading URLs from top sites, we can discuss further), we can adjust, reconsider things.

Btw, has Nick's team ever thought of creating an Activity Stream add-on for mobile?
Flags: needinfo?(bbermes) → needinfo?(alam)
https://hg.mozilla.org/mozilla-central/rev/5e2a5623088f
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 50
(In reply to Barbara Bermes [:barbara] from comment #10)
> We *must* get data.
> 
> We could put it behind a switchboard flag to gather data before making this
> fully available to people.
> 
> As for the grouping idea, seems reasonable, but which one would take
> precedence?
> a) Destop: twitter.com/bbinto/status/1239403030303
> b) Mobile: twitter.com/bbinto/
> 
> >> but I'm also not convinced that excluding all of the desktop-only history is the right path forward right now.
> Why is that concerning to you, it's a clear signal that the user seems to
> just visit that page on desktop, in this case, to be on the safe side, I'd
> rather not show it than show it.
> 
> This all brings up a good question; are we trying to replicate Activity
> stream? If so, then we should use the same logic, however if not (which I
> assume is the case), we could test a few variations via switchboard to
> really understand what the user prefers. Right now, we are just "guessing".
> 
> So to summarize, my proposal as a start
> - Add probes
> - Add switchboard flag for e.g. 50% of users with no desktop-only history 
> - Compare cohort with control, if we don't see much uptake in engagement (%
> increase of loading URLs from top sites, we can discuss further), we can
> adjust, reconsider things.
> 
> Btw, has Nick's team ever thought of creating an Activity Stream add-on for
> mobile?

Grisha doesn't have the bandwidth to do this. We either need to ship it as it currently landed, or not ship it at all. 

You should file a separate bug to track experimenting with this, and work with new engineering resources to do that when they become available.
(In reply to Barbara Bermes [:barbara] from comment #10)
> We *must* get data.
> 
> We could put it behind a switchboard flag to gather data before making this
> fully available to people.

Agree.

> As for the grouping idea, seems reasonable, but which one would take
> precedence?
> a) Destop: twitter.com/bbinto/status/1239403030303
> b) Mobile: twitter.com/bbinto/

It will be B. But let's handle this issue separately.

> So to summarize, my proposal as a start
> - Add probes
> - Add switchboard flag for e.g. 50% of users with no desktop-only history 
> - Compare cohort with control, if we don't see much uptake in engagement (%
> increase of loading URLs from top sites, we can discuss further), we can
> adjust, reconsider things.

Yes, let's do this instead of letting this bug ride the trains.
Flags: needinfo?(gkruglov)
Flags: needinfo?(bbermes)
Flags: needinfo?(alam)
ok, Grisha, please back out, not ship it, and we will talk to the Taipei team get the required things in.
Flags: needinfo?(bbermes)
Comment on attachment 8766114 [details]
Backed out changeset 5e2a5623088f (bug 1278301) because this feature is pending further investigation

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/61138/diff/1-2/
Attachment #8766114 - Attachment description: Bug 1278301 - Exclude history items from Top Sites which were not visited locally → Backed out changeset 5e2a5623088f (bug 1278301) because this feature is pending further investigation
Attachment #8766114 - Flags: review+ → review?(ahunt)
Flags: needinfo?(gkruglov)
We generally mark bugs as REOPENED if patches are backed out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 8766114 [details]
Backed out changeset 5e2a5623088f (bug 1278301) because this feature is pending further investigation

https://reviewboard.mozilla.org/r/61138/#review61044
Attachment #8766114 - Flags: review?(ahunt) → review+
https://hg.mozilla.org/integration/fx-team/rev/b50931952fbb76037bff76715e1f17f7fd80e34c
Backed out changeset 5e2a5623088f (bug 1278301) because this feature is pending further investigation r=ahunt
Priority: -- → P1
Assignee: gkruglov → nobody
Priority: P1 → P3
maybe activity stream will cover the top sites so it's not worth to modify at this moment?
Flags: needinfo?(s.kaspari)
(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #19)
> maybe activity stream will cover the top sites so it's not worth to modify
> at this moment?

Yeah, agreed. There's some experimentation happening on desktop side and it's likely that we are going to do that on mobile too. Depending on the data / experiments we want to optimize our top sites - this could be excluding desktop sites but we do not know until we measure and compare.
Status: REOPENED → RESOLVED
Closed: 4 years ago3 years ago
Flags: needinfo?(s.kaspari)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.