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)
Toolkit
Places
Tracking
()
RESOLVED
FIXED
People
(Reporter: Mardak, Assigned: Mardak)
References
Details
(Whiteboard: [tracking])
Attachments
(1 file)
26.17 KB,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•11 years ago
|
||
(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.
Comment 2•11 years ago
|
||
Updated•11 years ago
|
Summary: Add interest detection for visited pages with aggregate storage → [tracking] Add interest detection for visited pages with aggregate storage
Assignee | ||
Comment 3•10 years ago
|
||
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.
Blocks: fxdesktopbacklog
No longer depends on: 891560
Comment 4•10 years ago
|
||
(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.
Updated•10 years ago
|
Whiteboard: [tracking]
Assignee | ||
Comment 5•10 years ago
|
||
(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.
Updated•10 years ago
|
No longer blocks: fxdesktopbacklog
You need to log in
before you can comment on or make changes to this bug.
Description
•