Search sessions and history

If you have upgraded from Funnelback 15.22 or earlier you will need to upgrade any existing sessions and history code within your search result templates to use the current sessions and history widgets. The old AngularJS widget is not compatible with Funnelback 16 and will not work correctly.
The current tracking mechanism stores session history in the database. This mechanism will soon be deprecated, and all session storage will be shifted to browser local storage. To keep functionality intact, it is recommended that you upgrade the session history template to the latest version. Instructions for upgrading your template can be found in here.

Search sessions and history widget

The search sessions and history feature in Funnelback requires cookies to be enabled in the user’s browser. And therefore feature is only supported for Funnelback endpoints over HTTPS protocol. Funnelback has the ability to track a user’s search terms and recently visited items as well as providing the user with the ability to create a shortlist of search result items.

Result shortlisting

Result shortlisting provides a user with the ability to flag certain result items to be added to a shortlist (or result cart) by pinning the item. The pin changes to a cross once the item has been shortlisted. This allows a user to remove the item from the shortlist by clicking on the cross.

result shortlisting 01

The shopping cart icon in the panel containing the search box shows how many items have been shortlisted. All the shortlisted items can also be viewed by clicking on the shopping cart icon.

result shortlisting 02

Search history

When search sessions are enabled a user’s search history is tracked as searches are submitted. A summary of the search history is displayed above the search results.

search history 01

Additional information is displayed if you hover over an item. If the item has a filter applied (as indicated by the funnel icon) then the applied filters will display on hover, otherwise a tooltip indicating the time is displayed.

search history 02

Clicking the more link opens the full history screen.

search history 03

Visited items history

Funnelback also keeps track of all the search results that a user visits. Once a result has been visited an additional field is displayed within the result summary indicating the time that the visit occurred.

visited items history 01

Clicking on the Last visited link also opens up the history screen which provides a full list of recently visited URLs.

visited items history 02

Tracking mechanism

The user session is established through HTTP cookies. History and result selection are saved in a database. There is one database for a given Funnelback installation, but the data is saved on a per-collection basis, meaning that each results page will have separate search and click history, and separate results selection for a given user.

When sessions are enabled, users are automatically assigned a unique ID which is transmitted with every search query.

This feature relies on the URL of search results being valid URLs, and identical to their URL in the index. If the URL is rewritten in any way (using a hook script for example) you will need to ensure that the search results URLs passed to the session API calls are the indexed URLs, not the rewritten ones.

Enabling and configuring search sessions

Sessions are enabled with the ui.modern.session parameter. Once enabled, Funnelback will immediately start recording searches and clicks, and allow users to select results.

Enabling this parameter will also record unique user IDs in the query and click logs.

Configuration options

Various parameters can be used to configure the session features. Please consult their individual documentation for more details:

Cookies and identifiers

Enabling sessions will provide each user with a unique ID stored in a cookie.

Performance impacts

To record search history Funnelback needs to contact the session database for every query and this impacts the query response time. The time spent contacting and querying the database will depend on the server configuration, the type of database used and the size of the database. For example, on a standard Linux server with the built-in database engine and a fresh database the overhead is around 20ms per query.

For this reason it’s preferable to not enable the session features until you decide to make use of them in your search results page.

User interface and API