I'm generally skeptical.  The one aspect of this I'm excited by is changing kLowQualityMatchAgeLimitInDays to something in the range of 7 to 14.  Intuitively that makes sense to me.

Raising that from 3 to 10-14, and dropping the visit limit from 4 to 2-3, are the changes I think would get the most bang for the buck.

It's possible a higher value than 10-14, like 32 (intentionally longer than "one month") would make sense, but I suspect that would have much less payoff.  Dropping the visit limit (which is the same as dropping the value below 2, since every URL in the index would have at least one visit) could be a mixture of good and bad changes, but in conjunction with a longer age limit, it might be more bad than good.

(Note that if raising these _does_ expose bad effects, it likely means the HQP's scoring model is weak for low-quality URLs, and a theoretically-better fix would be to improve the scoring there; but that's hard to do.)

I think best way is to allow all of this settings to be controlled by experiment. This way we could test any combination of this params.
I could add experimental knobs, and you could do the histograms analyze.
I am interested as to the how you going to measure profit?

a-v-y@, in a case like this, I'd mainly look at metrics such as how much the user has to type (i.e., are the new suggestions pushing out other suggestions the user wants?) and whether the user is uses the suggestions (i.e., usage of URL suggestions from whatever URL providers are affected does not drop).

Please feel free to add the experiment knobs.  Given Peter's and my comments, I think the only knob we'd want for now is one for kLowQualityMatchAgeLimitInDays.

Note that we're still in the process of launching a change to HistoryQuick's ranking algorithm, so whatever experiment we should try with this will be after we decide to launch / not launch the other change.

Ok, will try to do. What other changes to ranking are coming? Can I read about it in more details?

Here's what I wrote a (private) bug:
"The omnibox suggests previously-visited pages.  This ranking was primarily tuned to smartly surface pages that the user visits often or has visiting already using the omnibox.  Anecdotally, it's clear that the omnibox doesn't suggest pages that the user visited recently, maybe only once or twice, when the use types in a word or two from the title or the URL.  These suggestions are often retrieved and then outscored by search query suggestions.  This change makes previously-visited pages suggested more aggressively."
And it especially boosts pages where the user types in something that's makes the page distinctive, i.e., a string that matches only this page or a small handful of pages (say, three or say) from the user's history.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still valid.