We, NICE, like several other organisations provide a search facility similar to an enterprise search; that being we index several external resources and provide the tool to search them. By default this means the standard site search feature of Google Analytics becomes less useful for insight generation because the search points away from your website rather than within it.
For example, a standard site search indexing internal pages, %search exits is those people who for whatever reason aren’t happy with the results presented and immediately leave without clicking on a result. For an enterprise search, users who also click on a result are an exit, so it becomes very hard to analyse search data to see whether the search is meeting user’s needs. (E.g. was the exit a click on a result or a real exit). Search depth is another feature that now becomes meaningless as this will be near 0.
To gather insights we need to gather data. To start with we have used event tracking to start to track user actions to gather the raw data. We have used a combination of listening for tags pushed to the datalayer or clever use of mark-up (specific div, p, li classes etc.) around links or text and of course Google Tag Manager.
- Firstly lets record the search term. We are able to create a search query variable using the url and query component
- Secondly let track results clicked, both the action of clicking a link, but also the URL and the search keyword (i.e. the variable just created). The trigger for this tag is a “search- result” datalayer match on the href. We could though have used a class match too
- Third up zero results. When a search query has zero results, our web page says so.
This isn’t a link though, so we need trigger the tag based on text in a certain class when the page is loaded. To do this we use the DOM ready trigger.
In terms of event tracking; Category is “Zero results”, and action is “search query”
- Forth is spelling corrections
Similar to zero results our page shows to the user the word they originally typed and the word we are now searching. Again our trigger is DOM ready for part of the line of text on the page “showing results for X, display results for Y” where X is the amended word and Y is the original.
In terms of event tracking; Category is “Spelling Auto-correction” Action is “search query” (new query) Label is the line of text (which includes the original search query)
Most enterprise searches also contain additional filter, sort and pagination options. Again track these as category’s but remember to add the search query as an action.
The first stat you need is number of searches. This we get from standard site search as we still track q queries.
Second is number of results clicked, this we get from event reports (look for “search results”). Use both of these figures to create the % of completions and thus % of non-completions (formally search exits).
Search completions = Total events (search results) / Total Searches
Third is zero results, simply just look at event reports and find “zero results”. This will give you information to act on. Either you start to index content for those words (if demand dictates) or put in an alternative which could be a paragraph saying we know you are looking for x, what about y. It is about meeting expectations.
Forth is spelling auto-corrections, again simply look at event reports and find “spelling auto-correction”. Spelling corrections again is good to act on as you can build up a bank or corrections to automatically apply. Again let’s think meeting expectations.
Create 2 segments one with event includes “search results” and one with event excludes “Search results”.
Using site search reports go to “search terms”, now using the segments mentioned, you can start to see what keywords lead to clicks and which don’t.
Again we can create segments on other features tracked; filter used or not, pagination used or not. As per above apply this to the Search term report.
Having these insights will let you understand the usage of search features, but more importantly you can start to understand pain points. What search terms led to a filter being used, what search terms led to pagination, what search results do users want but take time to locate?
Knowing these will then create solid hypotheses to test or trigger improvements on your algorithm.
Don’t stop there either. Apply these segments as well to the vast array of acquisition and audience reports. Understand who “uses” these features, where they came from. This will help target you solution to the right market.
It’s about exposure and reports people can act on. So build up some custom reports based on the above. Build a dashboard both date based and real time. Get the latter on a wall.
If you can use the API and get this onto a web page. This can be then easily sent to the people that need to act on it. It also helps as you can remove all the GA terminology you can’t get rid of on standard GA reports or dashboards.
Remember never create a report that is a nice to know. Create a report or dashboard that people can act on by providing insights.