Closed Bug 839132 Opened 11 years ago Closed 9 years ago

[tracking] Add interest detection for visited pages with aggregate storage

Categories

(Toolkit :: Places, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: Mardak, Assigned: Mardak)

References

Details

(Whiteboard: [tracking])

Attachments

(1 file)

We'll start by adding the page visit observer to send a message for getInterestsForDocument to process the page then increase the visit count for the associated interests.

The eventual API that we wouldn't make available for the initial landing would look something like:

[{
  interest: string
  score: [0-100] int normalized to scores of other in request
  diversity: [0-100] int percentage of top sites that match this interest
  immediate: bool based on first time bucket + threshold
  recent: bool based on second time bucket + threshold
  past: bool based on last time bucket + threshold
}, ... ]

Where unnormalized score is a time weighted/decayed sum of each daily visit count. E.g., a sample aggregate storage:

games, feb 7 (0 days ago), 3 visits
games, feb 6 (1 day ago), 10 visits
games, feb 2 (5 days ago), 5 visits

And assuming the weighting starts at 100% for today and -2% for each day, we'll store 50 days of visits, and the score for the above sample is 3*100% + 10*98% + 5*90% = 17.3.

Also assuming a bucket size of 2 days and threshold of 5, the above would correspond to:
immediate = true (13 visits >= 5 in last 2 days: day 0, day -1)
recent = false (0 visits < 5 in next 2 days: day -2, day -3)
past = true (5 visits >= 5 in rest of history: day -4 and older)

To compute diversity, we'll use the interest <-> domain table with a slight tweak that it only contains "top hosts" in the moz_hosts table by frecency, but we'll skip that for the first landing.


We'll use about:profile that has access to the JSmodule to display rawish data to avoid needing to implement the web API in the initial landing.
(In reply to Edward Lee :Mardak from comment #0)
> We'll use about:profile that has access to the JSmodule to display rawish
> data to avoid needing to implement the web API in the initial landing.
mak had a good suggestion that we can keep in-development/temporary UI pieces in a restartless add-on, so we can iterate quickly and avoid unnecessary reviews/localization.

We would probably expose functions from a JS module that we would use for in-Firefox UI but not actually call any of those functions from Firefox. We would write Firefox unit tests for those APIs and only call them from the add-on.
Depends on: 864918
Depends on: 864925
Depends on: 891560
Depends on: 891564
Depends on: 895106
Summary: Add interest detection for visited pages with aggregate storage → [tracking] Add interest detection for visited pages with aggregate storage
Depends on: 914242
Placing into backlog to be prioritized. Note the current set of attached patches implement the backend page classification engine that will need to be updated if they are to be reviewed. The patches do not include UI changes.
No longer depends on: 891560
(In reply to Edward Lee :Mardak from comment #3)
> Placing into backlog to be prioritized. Note the current set of attached
> patches implement the backend page classification engine that will need to
> be updated if they are to be reviewed.

So, if I got this right, once we start working on this in the backlog, we should request updated patches before starting the review process.
If so, do you mind if I remove the current requests, since my requests queue doesn't reflect reality? No problem if they come back when the project starts integration, clearly.
Whiteboard: [tracking]
(In reply to Marco Bonardo [:mak] from comment #4)
> do you mind if I remove the current requests, since my requests queue doesn't reflect reality?
I've converted the r?mak to f? to track potential patches that need to be updated/reviewed.
No longer blocks: fxdesktopbacklog
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: