New issue
Advanced search Search tips

Issue 860610 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Very-short-term penalty for local search history entries

Project Member Reported by pkasting@chromium.org, Jul 6

Issue description

Autocompleting search queries in local history has always been more controversial than autocompleting URLs.  In particular, the primary complaint about inline autocompletion is along the lines of "I tried to search for X Y Z, then I tried to just search for X Y, but it autocompleted to X Y Z".  I have repeatedly suggested that we disable inline autocompletion of multi-word search queries from local history, but IIRC Mark has said the data says that's a net loss.

So I have another idea.  Assuming t is the time since the query was last seen, change the ranking curve on these queries from something that falls off from a peak at t=0 to something that ramps quickly up to a peak at t=some_small_value and then falls off.  The idea is that if a user _just_ typed this query, they probably don't want it again -- but if they typed it, say, ten minutes ago (?), maybe they do.

Obviously, the peak value for t would have to be experimented with.
 
I thought the complaint about these was of the "I typed this *one* time, why are you forevermore suggesting it to me" variety. Is the case where the undesired suggestion is < 10 minutes old actually that common, you think?

Did we ever experiment with a more aggressive decay over time? Or being more sensitive to the # of usages so that a single use of "foo bar baz" won't be autocompleted?
I haven't heard the "I typed this once, why is it here forever" complaint about multi-word local search queries (seems like that comes up more for URLs); AFAIK the issue of short-time-horizon stuff is the primary one.  That one's hit me a couple of times and is the one I recall perpetually hearing from users (and was the one that led to this bug).

We haven't done a ton of experimentation with the ranking curve on local search queries.  I think we've tried a couple things, but I don't remember what.
Owner: jdonnelly@chromium.org
Status: Assigned (was: Untriaged)
Ok, thanks for the clarification. I've added this to our future projects list.
Sorry, dumb question. Why not just require that a query be used more than once before suggesting it?
We have something kinda like that in there right now (see https://cs.chromium.org/chromium/src/components/omnibox/browser/search_provider.cc?rcl=afe32ece3a686161401f2c552e859ef3bb338274&l=1217 ).  It refuses to inline-autocomplete multi-word queries until the user types more than one word.  I think that's both too conservative and too aggressive.  It's conservative because if you search for something, and then you come back a week later and you're really trying to remember it and you just can't think of it, we won't ever suggest it unless you can think of the first couple of words.  It's too aggressive because when you're trying to shorten what you just typed from three words to two, we suggest this thing.

Basically, over time I've grown to increasingly dislike behavioral cliffs in the omnibox, where we just have hard cutoffs at some point.  While frequency of typing is an important signal, and should factor into the relevance, I think it's generally true -- for single- or multi-word queries -- that there's some short period after searching where you're very unlikely to do the _exact_ same search again, because you're likely trying to refine it instead.  This really is probably less "time-based" than "session-based", but the omnibox today doesn't have much of a concept of "sessions".

Sign in to add a comment