On this page
- Analytics - A 5-Minute Video
- Analytics - Modeling Your Users’ Search Behavior
- Analytics - Implementation Overview
- Examples - What can we learn from Analytics?
- Related Documents, Tutorials, Code
Analytics - A 5-Minute Video
Analytics - Modeling Your Users’ Search Behavior
Algolia’s Analytics engine offers search-related metrics that track your users’ actual search activity. By using specialized search metrics - like popular searches, no result rates, or click and search-to-conversion rates - you can ensure that your Algolia implementation is optimized to meet your business’ needs.
We see two functional benefits:
- Improve the relevance of your search
- Generate business insights into:
- Your products and services
- Your inventory - less waste, better product availability
Additionally, search analytics can lead to discovering unexpected or hidden inefficiencies in both your Algolia implementation and your business.
The Search Bar as Feedback
Essentially, the search bar is being used as a feedback form or an impromptu user survey. Looking at it from this perspective, the search bar provides daily loads of useful feedback that offer invaluable search and business insights. Capturing this feedback in a meaningful and timely manner, and in an easy to read format, is critical to the success of our Analytics feature.
Two Kinds of Analytics: Search and Click
We provide two different kinds of analytics: one that looks closely at your users’ search behavior (search analytics), and another that measures what they do after a search (click analytics):
- Search Analytics facilitates modeling by breaking down user searches into numerous categories of data, like popular searches, number of “no results”, and filter usage. The goal of search analytics is to ensure that your search experience be data-driven.
- Click Analytics takes that data further, providing insight into what significant actions a user takes after performing a search: you can analyze click rates as well as define a single significant event - a conversion point - to see which searches lead most often to that event. Any catchable web event can be chosen as a conversion point: you choose the one you wish to track, and we start building a dataset around that event.
Analytics scales according to your plan
The subscription plan for Search Analytics differs from that of Click Analytics.
Algolia collects Search Analytics for every customer, offering a detailed view of their end-users’ search activities. All customers can view this data on the Algolia Dashboard. However, to fetch it programmatically, using the Algolia Analytics API, you’ll need to be on a Business or Enterprise plan.
Click Analytics are only available to Business and Enterprise customers. They can be viewed in the Dashboard or fetched programmatically via the Analytics API.
Analytics - Implementation Overview
What you can do with Analytics depends on your plan.
Quick Implementation Summary
What you need to do:
- For Search Analytics, nothing. This is already being done during every search.
- For Click Analytics, you need to add a new parameter to every search (
clickAnalytics=true), which will setup the query as a starting point for click and conversion events.
- To capture click events, you need to use the API to send the click event.
- To capture the conversion, you need to use the API to send the conversion event.
Implementing Search Analytics
This is done automatically. There is nothing you need to do for Algolia to build your search analytic data. Collecting this data has no impact on the speed of search.
Implementing Click Analytics
There are 3 steps to take to collect click and conversion events:
- Sending click events to Algolia
- Sending a conversion event to Algolia
For all information about endpoints and Rest API methods, go here.
Additionally, we have a tutorial that explains how to use the Rest API.
- The idea is to send the click event just before going to the clicked result. This can be coded synchronously, before you process the user’s click event (that is, before you take the user to the clicked result), or in a non-blocking manner. Either way, it’s the same method.
- If your UI enables the user to go directly to a conversion point, make sure that you are capturing all relevant events that precede the conversion. For example, if you’ve set up one-click buy as a conversion, you need to process both the click and conversion events before proceeding with the actual sale.
- If a user gets to a conversion point without having first used your search bar - for example, via Google, or an external hyperlink - this is not a conversion. Let’s say adding an item to a shopping cart is your defined conversion, it should be marked as a conversion only if it has followed the Algolia search. It is always important to keep in mind that we are tracking site search-to-conversion, so only search-derived conversions matter.
For click analytics to be reliable, you need to be consistent. Every click and conversion must be tracked properly. This means that every relevant event must be captured, otherwise the data won’t be complete or accurate.
The goal is to choose a single kind of conversion event and make sure this event is always captured. You also want to make sure that no other kind of event is captured. Algolia only tracks one kind of conversion per search. It can be “putting an item in the shopping cart” or “liking an item”; if you try to capture both events on a given search, you will never know which one was done or whether both were done. This is because Algolia only says Conversion = Yes or No per search, it does not save any more detail, and it doesn’t accumulate conversion events (so “liking” and “adding to shopping cart” does not make conversion = 2 but only conversion = Yes). In general, when you want to see if a search has converted, you need to be clear in your mind what that conversion is.
Some important considerations when coding Analytics
- Because you will be recording country-based information, you need to make sure you send us the relevant IP. Therefore, when doing backend search, make sure to forward the IP of the end user. Otherwise Algolia will see the queries coming from only one location - the location of your backend server.
- Given the “as-you-type” nature of Algolia search, if your user types 5 characters, this will generate 5 queries and therefore 5 Query IDs. In that case, you must use the last query ID. See query aggregation for more on this point.
Our search engine is designed to accept queries at each keystroke. In order to have relevant analytics data, however, we aggregate the series of keystrokes to keep only the latest (final) query made by the end user.
In the dashboard, the queries are the search queries made to the engine directly and the searches are the aggregated search queries used by the analytics. For example, if the users type “key”, it will perform 3 search queries (“k”, “ke, and “key”), but we’ll only use “key” as a search in the analytics.
That’s what we mean by “prefix” aggregation.
We use other query aggregation techniques, such as edit distance, timestamp, and, most importantly, user ID. The user ID is by default the IP. It is thus important that requests contain the actual end user IP. For back end implementation that means relying on the X-Forwarded-For header. Without this, the aggregations and thus most of the metrics won’t be properly computed. Alternatively, a custom token can be provided using the X-Algolia-UserToken header.
Accessing Analytics data
All Analytic data is accessible ready-made, in graphical format via our Analytics Dashboard. Our Analytics Dashboard walks you through all of our metrics. Everything is clickable, you can drill down on some metrics, and we provide hints and an easy UI to help you navigate through this data.
Additionally, you have full access to the data behind the dashboard with our Analytics Rest API.
As for how the analytics data gets captured: search analytics are recorded automatically with every search (if turned on), and click analytics require that you add small code snippets to well-chosen areas of your code. Our overview and tutorial should give you a good idea how to do this.
Examples - What can we learn from Analytics?
To give a preview of how these metrics can help, let’s compare 3 queries that use different words to convey the same intent (to find an eco-friendly refrigerator):
- “refrigerator efficient” => Lots of results, click rate 50%
- “eco refrigerator” => Less results, click rate 10%
- “refrigerator saves energy” => No results
What Can We Learn?
Lesson #1 => Add synonyms between “eco refrigerator” and “refrigerator efficient”, or rename your products in your catalog to handle both terms equally
Lesson #2 => Same for “saves energy”
Lesson #3 => Your marketing and merchandising departments should use these keywords more often
Lesson #4 => Maybe you should create a filter/category for “eco-friendly”?
Lesson #5 => What do we learn from the different click rates? Maybe users prefer the word efficient over eco, so you can use the word “efficient” more often in your product descriptions, and/or promote products that describe themselves as “efficient”.
Now, if we make some of those changes, and therefore we get more or less the same results, what can we learn with conversion rates?
- “refrigerator efficient” => Conversion 10%
- “eco refrigerator” => Conversion 5%
- “refrigerator saves energy” => Conversion 5%
Lesson #6 => We can see that we were right to equalize the terms and to emphasize “efficient” over the others: given the higher conversion rate on the “efficient” query, it seems to be the preferred term.
Lesson #7 => Another lesson we could have learned, had “no results” appeared more often, or if you had low click rates, is that if none of your refrigerators are eco-friendly, and yet this is a popular search, you might want to consider adding these to your product line. Or If you have the items but not enough of them, you might want to improve your inventory. Search and Click analytics can therefore help you spot and follow buying trends.
Related Documents, Tutorials, Code
Code, Methods, Tutorials
We have several front-end tutorials:
Did you find this page helpful?
We're always looking for advice to help improve our documentation!
Please let us know what's working (or what's not!).
We're constantly iterating thanks to the feedback we receive.