The pivot that excited Mozilla (and Google)

Search as you type, right in the browser.

The pivot that excited Mozilla (and Google)

In a previous blog post, we wrote about our search journey, detailing some of the choices made early on. In April 2014 we released the first version of our search engine, not as a Search Engine Result Page (SERP), but as a backend for our search-as-you-type product, or as we call it internally: the dropdown. There were two main reasons which pushed us to go with the dropdown instead of a SERP:

  • Our search engine back then did not have enough coverage. It could only answer about 50% of the queries.
  • The quality of the search engine results was not good enough to fill a full page of results. Remember that we discussed about noise [1]? The more results you show the more noise you surface.

The typical packaging of a search engine (the SERP) was out of question given its state. Of course there were voices advocating to continue working until it became good enough, but deep down we knew that this was not the way. After all, walking the known path leads to a known destination, and in the case of search engines, that destination is irrelevancy. We had to find another path, our path.

In hindsight, we are convinced that had we gone ahead and released our search as a traditional search page, we would most likely not exist today. We chose to go for the dropdown, because we were, and still are, absolutely convinced it is a phenomenal product that brings great value to users and at the same time it is very strategic.

Let us briefly first unpack why it is a good product. Rather that displaying search results in a web page we placed them on the address bar dropdown as a browser add-on. To be precise, Firefox, because Google Chrome does not allow access to the address bar. They understand the strategic importance of being the first to get the query.

Instead of seeing the usual query suggestions as they type, users would now see a mix of:

  • The top 3 results for the query (on each key press).
  • Matching results from the browser history, bookmarks and open tabs.
  • Enriched (smart) results which can be consumed by just looking at them - no need to visit any page (e.g. query weather in munich). We wrote about rich results here.

Results take on average 160 ms (median) to render. Searching as you type saves about 2 seconds per answered query, at no extra cost to the user. The dropdown search results are available on each key press, accompanying the user, but never IN their way. Our goal with the dropdown was never to replace the default search engine, but to complement it.

There are powerful strategic reasons why we did so:

  • It introduces zero friction to the users. They do not have to choose between Cliqz or their complemetary search engine (well, most often Google), because they can have both, without any overhead.
  • We needed Human Web to bootstrap our search, and the fallback to Google as a “complementary” search engine would provide the much needed data.
  • The dropdown is a defensible product. Do not get us wrong. What we do in the dropdown is something that Google is more than capable of doing, technically. They might even do a better job, but they cannot afford it. There is simply not enough space there for Google to serve all the ads they need, and no company can make decisions that reduce their revenue, however great they may be for users.

This decision, as we shall see later, was less innocuous than anticipated and this little trick of providing search results as you type, straight in the browser, turned out to have important ramifications.

Firstly, we were cutting traffic to Google. The results served by Cliqz in the dropdown translated to queries that Google would never see.

Secondly, queries that are easy to answer turn out to be the most monetizable ones. Or to put it in a different way: the queries that are more likely to generate revenue, are less likely to land on Google.

To date, our dropdown users go to Google only for 37% [2] of the queries.


With a new kind of search come new challenges

Serving results in the dropdown changes the problem of search.

Latency: we have very little time to answer as results have to be served on each key press. Results from the backend take on average 160 ms (median) to render, with results pulled from history, bookmarks and open tabs taking around 50 ms. This is one of the reasons why the dropdown will not always show the same results as one would see in our SERP: beta.cliqz.com.

End of query: on a SERP, it is very clear when the query is final (hit enter). In the dropdown there is no “end of query” signal. In turn, expansions are hard. If we expand too aggressively, certain pages may become unreachable. If we expand too little, we will cause a lack of diversity - which means the results will be from very similar topics.

We have been honing our search to do well on these problems for the last 4 years, and over time, the search that powered the dropdown has gotten better and smarter. Now, we have enough muscle to offer an alternative SERP (available at beta.cliqz.com). This was not the case years ago. Like everything we do, it is built with an obsessive focus on utility, and adheres to the same values: Privacy and Independence.


Conclusion

Fundamentally, the dropdown solves a different use case than a SERP, and they make an excellent combination. The dropdown is the only search of its kind, and it is unbelievably great at quickly providing results to navigational queries, searching history, or finding bookmarks.

The strategic placement of our dropdown search, attracted the attention of Mozilla, with which we started collaborating to bring a private search neatly integrated in the browser. This would be deployed to Firefox users in Germany.

The search dropdown, however, also attracted the attention of those who fund Mozilla [3]. It is perfectly understandable that Google was not keen on losing highly monetizable queries, and is also understandable that Mozilla had a difficult time trying to break the golden cage they find themselves in. To their credit, they did try. Ultimately the Cliqz-Firefox integration was, unilaterally, cancelled. We still believe that for Mozilla it was a mistake and a disservice to all. If your main source of revenue comes from your “competitor” you are slowly pushing yourself to irrelevance.

Do not get us wrong, we have no doubts that Mozilla and mozillians are trying to compete and fight back Google, but with a hand tied to their back. A heavy weight as Mozilla, with something like Cliqz as an instrument, might have been able to set fire on Google’s backyard, a place that no one dares to go.

Cliqz might have been a get out of jail card, but it did not work out. For us, nothing changed, with or without partners, we continue fighting for what we believe is the right thing.

References

  1. The Cliqz Search Engine - [source] ↩︎

  2. This number is a higher estimate, in which absolutely zero friction is added on conventional workflow. Any reader of HN for instance likely sees the results as they type, but many people look at the keyboard when typing and then press enter. They do not even get to see Cliqz results. People with a strong muscle memory do not have time to interact with results either, for once you press enter you go to your default search engine. Could we capture those easily? Of course, and the 37% would go down, easily, but that is not our goal. And it was already high enough to raise some eyebrows. ↩︎

  3. Mozilla Financial Statements 2017, 2018 - [source] ↩︎