Best practices - 3.4 Specific features
Background
This article outlines the best practice to follow when implementing specific features such as auto-completion or extra searches.
Auto-completion
Funnelback standard auto-completion is designed to be fast and to help guide a user to make a sensible query. It is not designed to be an instant search and lacks a lot of the control that is available when a standard query is run.
Use of search-powered auto-completion (where a Freemarker template is configured to return a standard query as the auto-completion JSON) is not recommended as a full search is being run for every keystroke a user types. This can have a significant impact on performance and a very slow auto-completion won’t be effective as a user will typically type faster than a search-powered auto-completion can return.
Faceted navigation
Convert any legacy facets to use the faceted navigation introduced in Funnelback 15.12.
Using non-legacy facets provides access to many additional facet types (e.g. tabs, radio facets, checkbox faceting) and provides a lot more control over how the facets work. Non-legacy facets also have a much cleaner data model (so JSON/XML integration with faceted navigation is much more feasible).
Extra searches
Extra searches provide the ability to execute extra queries in addition to the main query, either in the same collection or a completely different collection entirely. Firing additional queries has some side effects on analytics, performance and configuration that are listed below.
Analytics
Configure Funnelback to ignore all queries from a particular extra search by setting the -log=off query processor option the extra search configuration file:
e.g. extra_search.<extra search name>.cfg
collection=<target collection>
query_processor_options=-log=offExisting query processor options are still respected.
Performance
The number of extra searches should be kept as low as possible, as each extra search is equivalent to a complete query being run. More than two extra searches is usually not advisable.
Features which are not used within extra searches such as quick links, or best bets can be turned off or refined in order to improve performance.
Knowledge graph
Provide Funnelback knowledge graph specific metadata in the source data
If possible ensure that custom fields are configured to define the Funnelback knowledge graph specific metadata. e.g. have a CMS return entity type and name metadata directly to Funnelback avoiding any requirement for extracting the metadata.
Clone the node names and labels
If the source content cannot be modified to produce custom metadata fields a good option is to clone existing metadata fields that hold relevant values.
Use the KGMetadata filter to extract and clone existing metadata to the node name and label fields required by knowledge graph, or provide the fields directly in the data source.
Having the values separated means that the metadata fields can used for knowledge graph without affecting the Funnelback ranking or ability to display the metadata.
For example, if the title field is remapped from the t metadata class to the FUNkgNodeNames field it loses the ranking boost that Funnelback will apply by default.
The node names and labels also often require transformation so that they work correctly in the knowledge graph. E.g. you might need to combine first and last name into a single field for the node names. If they are added separately the entities won’t be correctly detected in the knowledge graph.