The other day a friend emailed me asking if I’d ever seen behavior where Google’s autocomplete suggestions would change based on a prior query.
I’ve seen search results change based on prior queries but I couldn’t recall the autocomplete suggestions changing in the way he detailed. So I decided to poke around and see what was going on. Here’s what I found.
Query Dependent Autocomplete Example
Here’s the example I was sent. The individual was cleaning up an old computer and didn’t quite know the purpose of a specific program named ‘WineBottler’.
Quickly understanding that he didn’t need this program anymore he began to search for ‘uninstall winebottler’ but found that Google’s autocomplete had beat him to it.
There it was already listed as an autocomplete suggestion. This is very different from doing the uninstall query on a fresh session.
I was intrigued. So I started to try other programs in hopes of replicating the query dependent functionality displayed. I tried ‘SnagIt’ and ‘Photoshop’ but each time I did I got the same generic autocomplete suggestions.
Query Class Volume
Coincidentally I was also chatting with Barbara Starr about an old research paper (pdf) that Bill Slawski had brought to my attention. The subject of the paper was in identifying what I call query classes, or a template of sorts, which is expressed as a root term plus a modifier. Easy examples might be ‘[song] lyrics’ or ‘[restaurant] menu’.
So what does this have to do with autocomplete suggestions? Well, my instinct told me that there might be a query class of ‘uninstall [program]’. I clicked over to Ubersuggest to see if I just hadn’t hit on the popular ones but the service was down. Instead I landed on SERPs Suggest which was handy since it also brought in query volume for those autocomplete suggestions.
I searched for ‘uninstall’ and scrolled to where the results were making the most sense to me.
Quite obviously there is a query class around ‘uninstall [program]’. Now it was time to see if those with high volume (aka intent) would trigger the query class based autocomplete suggestions.
Query Class Based Autocomplete Suggestions
The scourge of the pop-under world, MacKeeper, jumped out at me so I gave that one a try.
Sure enough the first autocomplete suggestion is uninstall mackeeper. It’s also interesting to note the prior query is kept in reference in the URL. This isn’t new. It’s been like that for quite some time but it makes this type of scenario far easier to explain.
At random I tried another one from my target list.
Yup. Same thing.
Classes or Attributes?
It got me thinking though whether it was about query classes or just attributes of an entity. So I poked around a bit more and was able to find examples in the health field. (Sorry to be a debbie downer.) Here’s a search for lymphoma.
Followed by a search for treatment.
This differs from a clean search for ‘treat’.
Treatment is an attribute of the entity Lymphoma. Then again ‘treatment of [ailment]’ is also a fairly well-defined query class. So perhaps I’m splitting hairs in trying to pry apart classes from attributes.
It Doesn’t Always Work
I figured I could find more of these quickly and selected a field that I thought had many query classes: music. Search for a band, then search for something like ‘tour dates’ or ‘tickets’ and see if I could get the query dependent autocomplete suggestions to fire.
I tried Kasabian.
And then tour dates.
Nothing about Kasabian at all. Just generic tour dates autocomplete suggestions. I tried this for many other artists including the ubiquitous Taylor Swift and got the same results, or lack thereof.
I had a few theories of why music might be exempted but it would all just be conjecture. But it did put a bit of a dent into my next leap in logic, which would have been to conversational search.
Not Conversational Search
One of the bigger components of Hummingbird was the ability to perform conversational search that, often, wouldn’t require the user to reference the specific noun again. The classic example being ‘How tall is the Eiffel Tower?’ ‘Who built it?’
Now in the scheme of things conversational search is, in part, built upon identifying query classes and how people string them together in a query session. So it wouldn’t be a shock if this started showing up in Google’s autocomplete suggestions. Yet that’s not what appears to be happening.
Because you can do a voice search using Google Now for ‘Kasabian’ and then follow up with ‘tickets for them’ and get a very different and relevant set of results. They figure out the pronoun reference and substitute appropriately to generate the right query: ‘Kasabian Tickets’.
What Does Google Say?
Of course it pays to see what Google says about their Autocomplete
I find it interesting that they call them predictions and not suggestions. It’s far more scientific. More Googly. But I’m not changing my references throughout this piece!
But here we can see a probable mash-up of “search activity of users” (aka query classes) and “relevant searches you’ve done in the past” (aka query history). Previously, the query history portion was more about ensuring that my autocomplete for ‘smx’ might start with ‘smx east’.
While the autocomplete for someone unaffiliated with search wouldn’t get that suggestion.
So I’m left to think that this new session based autocomplete personalization is relatively new but may have been going on for quite some time without many people noticing.
There’s a lot more research that could be done here so please let me know if and when you’ve noticed this feature as well as any other examples you might have of this behavior.
For Google the reason for doing this is easy. It’s just one more way that they can reduce the time to long click.
Google is personalizing autocomplete suggestions based on a prior query when it matches a defined query class or entity attribute.