Best Practices

The Google Search Appliance has features that enable system administrators to enhance the search experience for end users. This chapter describes how system administrators can follow best practices to improve end-users searches.

Back to top

Search Experience Best Practices

A Google Search Appliance can begin serving relevant results as soon as it has an index. By serving relevant results, the search appliance ensures a positive search experience for your users. However, you, as a search appliance administrator, can use the best practices and search appliance features described in this document to personalize or enhance the search experience for users.

Checklist of Best Practices

Use the following table as a best practices checklist. For each best practice, the table identifies the search appliance feature or resource to use, with a reference to the relevant section in this document.

 

Best Practice	Feature or Resource to Use	Reference
Export and analyze data about user clicks	Advanced search reporting	Gathering Information about the Search Experience
Enable end users to create email alerts for topics of interest	Alerts	Providing Alerts for End Users
Prevent click-jacking web attacks	Click-Jacking defense	Enabling/Disabling Click-Jacking Defense
Divide the search index into meaningful partitions	Collections	Segmenting Data in the Search Index
Show thumbnail images of documents in search results	Document preview module	Providing Document Previews
Help user explore search results by using specific metadata attributes	Dynamic navigation	Using Dynamic Navigation to Help Users Explore Results
Allow users to choose results by topic	Dynamic result clusters	Using Dynamic Result Clusters to Narrow Searches
Return search results from Google Apps	Content Sources > Google Apps	Integrating with Google Apps
Enable searching for experts in your organization	Expert search	Providing Expert Search for Users
Restrict search results by domain name, language, file type, or meta tag	Filters	Using Filters to Restrict Search Results
Take advantage of search appliance expertise	Google for Work and Google Groups	Exchanging Information on Google Groups
Update to the most recent software version	Google for Work Support site	Updating Your Search Appliance
Eliminate duplicate search results and provide the most relevant set of diverse results	Host crowding	Experimenting with Host Crowding Options
Present recommended links above search results	KeyMatches	Using KeyMatches to Guide Users to URLs
Enable query expansion and spelling suggestions for a set of languages	Language bundles	Changing Languages for Query Expansion and Spelling Suggestions
Add structured, real-time application data to search results	OneBox modules	Using OneBox Modules to Integrate Structured Results
Create a user interface that focuses on your users	Page Layout Helper or XSLT Stylesheet Editor	Customizing the User Interface
Return user profiles along with ranked search results	People search (deprecated)	Using People Search
Provide your own synonyms for use in query expansion	Query expansion	Using Query Expansion to Widen Searches
Enable search queries to auto-complete and query suggestions to appear as a user types in the search box.	Query suggestions	Providing Query Suggestions
Present alternative search terms above search results	Related queries	Using Related Queries to Suggest Alternative Searches
Prevent specific URLs from appearing in search results	Remove URLs	Removing URLs from Search Results
Influence the order of documents in search results	Result biasing	Using Result Biasing to Influence Result Ranking
Identify problematic query topics for related queries, KeyMatches, and query expansion synonyms	Search report	Analyzing Searches that Do Not Return Results
Obtain user responses about the search experience	Surveys	Conducting a User Satisfaction Survey
Translate search results into the user’s language in real time	Translation	Enabling Translation of Search Results
Enable users to add search results for certain keywords in a specific front end	User results	Providing User Results
Allow users to give you feedback	User interface	Adding a Feedback Mechanism for Users
Optimize the response time of results	Various features	Optimizing the Speed of Results
Remove obsolete or non-essential content from the search index	Whitelist URLs or Blacklist URLs	Keeping the Search Index Clean
Enable your users to search by entering a word pattern rather than the exact spelling of a term.	Wildcard search	Enabling Wildcard Search

Back to top

Personalizing the Search Experience

The Google Search Appliance enables you to personalize the search experience. Rather than providing one centralized search experience for everyone, you can provide different search experiences for different groups of users. Each personalized search experience is based on the interests, roles, departments, locations, or languages of the user group.

For example, suppose your Google Search Appliance provides search for internal users from different organizations. Users often search for “acme widgets,” but they are not all searching for the same results. More typically, when searching for acme widgets:

With a centralized search experience, some users may find what they are looking for at the top of the results listings while other users might have to view several results before finding what they are looking for. With a personalized search experience:

Users do not need to take any action to have a personalized search experience. The search appliance automatically presents a personalized search experience based on changes that you, as the system administrator, have implemented using search appliance features, including front ends (see The Relationship Between the Search Experience and Front Ends), KeyMatches (see Using KeyMatches to Guide Users to URLs), and source biasing (see Using Source Biasing).

The first step to personalizing the search experience is gathering information about the search experience (see Gathering Information about the Search Experience) as it is currently deployed on the Google Search Appliance. After gathering this information, you can analyze it and decide:

In this document, descriptions of features that you can use to personalize the search experience are marked with the following personalization icon.

Back to top

The Relationship Between the Search Experience and Front Ends

Several of the Google Search Appliance features described in this document are implemented in specific front ends. A front end is a framework that manages the search experience for specific types of end users. Features implemented in front ends include:

The search appliance has a default front end that uses default settings for the elements that influence search quality. You can use the default front end without changing any settings.

If you plan on changing anything in a front end, it is recommended that you create at least one front end to customize. For information about this task, refer to Creating a Front End.

Creating Multiple Front Ends

For one Google Search Appliance, you can create multiple front ends, each with its own customized settings. For example:

For more information about front ends, refer to Managing the Search Experience.

Back to top

Gathering Information about the Search Experience

Before you can effectively personalize the search experience, you need to have knowledge about your end users, such as their roles, functional groups, locations, what they are searching for, and whether they are finding it or not. The Google Search Appliance enables you to gather information about user clicks. From this information, you can gain knowledge about end users and their interactions with search results. Information about user clicks can tell you:

By analyzing user clicks, you can identify ways to personalize and improve the search experience. For example, suppose information about user clicks shows that a users in range of IP addresses are all searching for information about project Malta. None of the users are finding a satisfactory URL at the top of the search results. Some of the users are finding a satisfactory URL on page 3 of the results. However, many users are abandoning the search after viewing page 2 of the results.

The range of IP addresses tells you that the users who are searching for the results are all Engineers in the U.S. who are working on project Malta. You might create a front end for this group of users. For information about this task, refer to Creating a Front End.

For this front end, you might promote project Malta URLs to the top of the search results using KeyMatches (see Using KeyMatches to Guide Users to URLs). Another alternative for promoting these URLs is to use source biasing (see Using Source Biasing) to move the result up in the listings.

Some time after you deploy the front end for Engineers in the U.S., you can gather more information about user clicks to find out if the personalization that you deployed in the front end is successfully improving the search experience. You can also use this information to make other changes to improve and personalize the search experience.

Viewing Detailed Data about User Clicks

The Google Search Appliance feature that enables you to gather information about user clicks is advanced search reporting (ASR). When advanced search reporting is enabled in the Admin Console (see Enabling Advanced Search Reporting for a Front End), you can export an advanced search report (see Exporting an Advanced Search Report). Each entry in an advanced search report represents a single user click or other action, such as page load, in the search appliance user interface.

When you enable advanced search reporting, the search appliance uses its automatic self-learning scorer (see Using the Automatic Self-Learning Scorer), which fine tunes relevance and scoring for results.

Values in Advanced Search Reports

An entry is composed of comma-separated values. The following table describes each value in an advanced search report.

 

Value	Description	Example
Click time	Time of the click in 100ths of a second since midnight on January 1, 1970.	125001323979
IP address	IP address of the user who clicked.	172.18.75.121
Session ID	Holding place for session ID, always blank.
Click type	Type of action, which can be a user click or other action. For more information, refer to Click Types in Advanced Search Reports	c
Click start	The results page of the user click, where 0=1st page of results.	0
Click rank	The rank of the result on the page of the user click, where 1=the 1st result, 2=2nd result, and so on. A smaller number click rank indicates higher user click satisfaction.	1
Click data	Usually blank.
Query	Search query that returned results.	Google+Search+Appliance
URL	URL of the user click.	http://www.google.com/

The following example shows a complete entry in an advanced search report:

This example shows that on July 31, 2008 at 6PM (1217555170), a user (172.18.75.121) clicked on a result (c) on the first page of results (0). The result was the first result (1) that appeared on the page. The search term that the user entered was Google Search Appliance and the URL of the result was http://www.google.com/.

Click Types in Advanced Search Reports

The following table describes built-in click types that can appear in an advanced search report.

 

Click Type	Description
advanced	Advanced search link on the search page
advanced_swr	Advanced search for anchor text
c	Search result
cache	Cached document on results page
cluster	Cluster label on results page
db	Database content on results page
desk.groups	Groups link at the top of the search page
desk.images	Images link at the top of the search page
desk.local	Local link at the top of the search page
desk.news	News link at the top of the search page
desk.web	Web link at the top of the search page
help	Search Tips link on the search page
keymatch	Keymatch on results page
load	Load results page
logo	Hyperlinked logo
nav.next	Navigation, next page
nav.page	Navigation, specific page
nav.prev	Navigation, previous page
onebox	OneBox on results page (see Adding Click Types to OneBox Modules)
sitesearch	More results from... link on results page
sort	Sort link on results page
spell	Spelling suggestion
synonym	Related query on results page
OTHER	Any link on the results page that does not have a defined ctype

Optionally, you can also:

Adding Custom Click Types

You can also add your own custom types to an XSLT stylesheet. Any ctype values that you add remain within your system only and are not tracked by Google. Ensure that any ctype values that you add do not duplicate the built in ctype values.

If you want to track user clicks on elements other than links (such as buttons), refer to the clicklog.js file on the Google Search Appliance. (clicklog_compiled.js is an optimized version of this file that reduces the download size and browser latency.)

Adding Click Types to OneBox Modules

If you have OneBox modules where you want to track user clicks, add the onebox ctype to onebox-default.xsl. To edit onebox-default.xsl, use the Content Sources > OneBox Modules page in the Admin Console or an editor of your choice.

Interpreting Detailed Data About User Clicks

The examples in this section show you how to interpret detailed data about user clicks in an advanced search report. The examples omit some values from the each entry in the advanced search report, as indicated by the ellipses (...).

The following example shows a user searching on the term enterprise and finding a result on page 2 of the listings:

The following example shows a user searching on the term corfu clicking on the tenth result on the first page of listings:

Using Advanced Search Reporting to Personalize the Search Experience

The following steps outline an effective method for using advanced search reporting to personalize the search experience:

Because an advanced search report is a comma-separated values file, you can import it into a spreadsheet where you can sort the values. For example, you might sort an advanced search report by URL to find all user clicks that pertain to a specific URL.

Getting Baseline Measurements

Before you begin personalizing the search experience, identify the initial state of the search experience by taking baseline measurements. You can get baseline measurements by:

As you personalize the search experience, continue to generate advanced search reports that you can compare with baseline measurements.

Calculating the Percentage of Satisfied Queries

Using the information in the report, you can calculate the percentage of satisfied queries. A satisfied query is a search that ends with a user clicking on a result, as indicated in the report by a click type of c. When counting the total number of satisfied clicks only count the first click type of c after the first load.

The formula for calculating percentage of queries that are satisfied is:

For example, if the total number of satisfied clicks is 54 out of 90 total queries, the percentage of satisfied queries would be 60%.

Calculating the Average Click Rank

To calculate the average click rank, you must first identify the absolute click rank for an individual entry. Using the click rank alone will not give accurate results because a click rank number does not indicate the results page of the click. For example, when a user clicks on the first result on the first page, the click rank is 1. However, when a user clicks on the first result on the tenth page of results, the click rank is also 1. By using the following formula, you can account for the page of the user click.

The formula for identifying a click rank for an individual entry is:

where click start is the page of the click

The formula for calculating average click rank is:

For example, if the total of all the click ranks was 255 for 75 clicks, the average click rank would be 3.4.

Analyzing User Clicks

To analyze user clicks, determine how users are searching based on click type and how the search ends.

For example, you can identify top queries by sorting an advanced search report by query. After sorting queries, you might check the click types on the top queries. For satisfied queries with low click rank and unsatisfied queries, you might improve search by creating a KeyMatch, applying source biasing, or developing a OneBox module.

You also might want to identify IP address ranges for most queries. This might indicate that members of a specific group of users, such as the sales department, are all searching for the same information.You might consider personalizing their search experience by creating a collection (see Segmenting Data in the Search Index) and front end (see Creating a Front End) especially for this group.

Personalizing the Search Experience Using Front Ends

Using your analyses of user clicks, you can identify ways to personalize the search experience using front ends. For an overview of ways to personalize the search experience, refer to Checklist of Best Practices.

Throughout this and other chapters of Creating the Search Experience, descriptions of features that you can use to personalize the search experience are marked with a personalization icon.

Measuring the Effectiveness of Personalization

After you personalize the search experience, generate another advanced search report and compare with it the baseline measurements (see Getting Baseline Measurements). This comparison enables you to measure the impact that personalization has had on the search experience.

For example, suppose that after you personalize the search experience, the percentage of satisfied user clicks is 80%. This shows a measurable improvement from the baseline of 60%. Because of personalizations, users are more frequently finding relevant information.

Generating an Advanced Search Report

Use the Google Search Appliance Admin Console to generate an advanced search report by:

Enabling Advanced Search Reporting for a Front End

You can enable or disable advanced search reporting for any front end. To enable advanced search reporting, use the Search > Search Features > Front Ends > Output Format page in the Admin Console. For complete information about using the Output Format page, refer to Admin Console Help > Search > Search Features > Front Ends > Output Format - Page Layout Helper in the Admin Console.

Exporting an Advanced Search Report

After you enable advanced search reporting for a front end, you can export an advanced search report. To export an advanced search report, use the Reports > Search Logs page in the Admin Console. For complete information about using the Search Log page, click Admin Console Help > Reports > Search Logs in the Admin Console.

You can also use the Reports > Search Reports page to view the following advanced search report data:

Using the Automatic Self-Learning Scorer

If you enable advanced search reporting, the search appliance uses its automatic self-learning scorer. This feature automatically analyzes user behavior and the specific links that users click on for specific queries to fine tune relevance and scoring. The search appliance uses advanced statistical regression to determine the statistical significance of user behavior, and adjusts for trust bias (that is, users clicking on the first result solely because it's first). Thus, over time, results become more and more precise without the need of administrator intervention.

The learning-module runs daily, and learns over a 90 day window. It has the capability to forget old user behavior, and learn from new ASR data. It is not possible to remove ASR data without waiting for the 90 day window to pass.

You may allow/disallow the scorer to use the information learned by the learning module. However, even if the scorer is not allowed to use the data gathered by the learning module, no information is lost. As long as ASR is activated, the learning module continues to learn. If the scorer is allowed to use that information at a later point, it immediately begins using everything learned over past days.

To deactivate the automatic self-learning scorer, navigate to the following URL: http://<yourMachine>:8000/EnterpriseController#a=deActivateAdvancedScoring

To activate the automatic self- learning scorer, navigate to the following URL: http://<yourMachine>:8000/EnterpriseController#a=activateAdvancedScoring

The automatic self-learning scorer is activated by default when you enable advanced search reporting.

Back to top

Using KeyMatches to Guide Users to URLs

A document might not be in the search index or might not appear among the highest search results. However, it might be valuable to users as a search result. You can promote such documents in the results by using KeyMatches. A KeyMatch guides users to recommended links, and appear when a user enters a specific search term.

Because a KeyMatch is specific to a front end, you can aim it at specific types of end users, as shown in the following example. Suppose you administer a search appliance for an e-commerce business, mediacompany.com. This business sells DVDs online in various countries. The business maintains an e-commerce website with a home page, www.mediacompany.com, This home page contains links to pages for end users in different regions, including North America, South America, Europe and the Middle East, Asia, Australia, and Africa.

You know that when end users search for “new movies,” they are most interested in navigating to http://mediacompany.com/DVD/recentreleases. You might provide this link on top of the search results as a KeyMatch, as shown in the following figure.

KeyMatches are not set up by default. You create a KeyMatch for a specific front end by associating a search term to a specific URL and specifying a title for the match. In the previous example:

You can submit any number of URLs per word, phrase, or exact match. By default, however, only a maximum of three KeyMatches are returned for a search. You can increase the maximum number of KeyMatches returned up to 50 by using the numgm query parameter, which is described in the Search Protocol Reference.

The search appliance returns KeyMatch results based on the order in which the rules are created. For example, the following figure shows a front end with four KeyMatch rules defined:

If an end user searches for “stock bond,” the search appliance returns the following KeyMatch results, in the order shown:

If an end user searches for “bond stock,” the search appliance returns the following KeyMatch results, in the order shown:

Working with KeyMatches

To work with KeyMatches, use the KeyMatch tab on the Search > Search Features > Front Ends > Output Format page in the Admin Console. For any front end, you can:

Any KeyMatch file that you import must be in UTF-8 encoding. For complete information about using the KeyMatch tab, click Admin Console Help > Search > Search Features > Front Ends > KeyMatch in the Admin Console.

Identifying KeyMatches

To identify potential KeyMatches:

You might also get input for KeyMatches from people in your own organization who have domain expertise. For example, suppose you want to improve searches that pertain to sales issues. You might ask people in your sales offices to identify keywords that need KeyMatches.

Changing the Appearance of KeyMatches

You can change the appearance of KeyMatches in the user interface for a front end. Components that you can change include:

For example, you might make the following changes:

The following figure illustrates these changes.

To make changes to the appearance of KeyMatches, edit the Result Page Component section of the XSLT stylesheet. For information about editing the XSLT stylesheet, refer to Customizing the User Interface in the XSLT Stylesheet.

Back to top

Using Related Queries to Suggest Alternative Searches

You can help users refine their searches by offering related queries. A related query is a suggestion for an alternative word or phase for the user's original search term. The related query appears at the top of search results.

Because a related query is specific to a front end, it can be aimed at a specific types of end user, as shown in the following example. In an organization, projects and products are often developed under an internal name, but launched under a different name. For example, suppose mediacompany.com develops a new MP3 player under the code name “Malta,” but releases it as “Valise.”

Some internal users may not be familiar with the name “Malta.” When they search for “Valise,” they miss all the documents indexed under “Malta.” You can create a related query for “Malta” that is returned when users search for “Valise,” as shown in the following example:

You could also try: Malta

When the user clicks “Malta,” the search appliance runs the search again and returns additional results.

An alternative search term might be useful for users of several front ends. In this instance, you might consider using query expansion (see Using Query Expansion to Widen Searches) to add it as a local synonym.

Related queries are not set up by default. You can create a related query by associating a search term with a related query. In the previous example:

Search terms and related queries can be words or phrases.

Related queries are unidirectional only. When the end user's query matches the search term, the related query appears. However, when the end user's query matches the related query, the related query does not appear. Continuing the previous example, if a user searches for “Malta,” the search term “Valise” does not appear.

When you add related queries to a new front end, they can appear immediately. If you add them to an existing front end, it can take 30 minutes or more for them to appear.

Working with Related Queries

To work with related queries, use the Related Queries tab on the Search > Search Features > Front Ends page in the Admin Console. For any front end, you can:

Add related queries individually

For complete information about using the Related Queries tab, click Admin Console Help > Search > Search Features > Front Ends in the Admin Console.

Identifying Related Queries

To identify potential related queries, get a list of the query terms that do not return results by creating a report of unsuccessful search queries. For information about this task, refer to Analyzing Searches that Do Not Return Results.

You can ask domain experts in your organization for input. For example, suppose you want to improve searches that pertain to personnel issues. You might ask people in your Human Resources office to identify keywords to use.

Changing the Appearance of Related Queries

You can change the appearance of related queries in the user interface for a front end. Components that you can change include:

For example, you might make the following changes:

The following figure illustrates these changes.

Search again using this term?: Malta

To make changes to the appearance of related queries, edit the Result Page Component section of the XSLT stylesheet. For information about editing the XSLT stylesheet, refer to Customizing the User Interface in the XSLT Stylesheet.

Back to top

Using Dynamic Result Clusters to Narrow Searches

Sometimes, users search with terms that return an overly broad set of results. You can help end users narrow searches by enabling dynamic result clusters. Dynamic result clusters show different topics for a specific search term. These topics enable users to focus on areas of interest while ignoring irrelevant information.

For example, suppose your website offers memberships to users. When an end user searches for “membership,” a dynamic result cluster appears with the a list of topics found in the results. The following example illustrates this dynamic results cluster.

narrow your search

membership options
membership help
membership pricing
membership privileges
membership specials

When a user clicks on any of the topics, the search appliance returns a new, narrower set of results.

Dynamic result clusters are formed from each set of results. Dynamic result clusters work best when the results contain sufficient documents to allow the search appliance to categorize them into topics.

By default, dynamic result clusters are disabled. For any front end, you can:

Dynamic result clusters work with secure queries. Before displaying dynamic result clusters for secure queries, the search appliance ensures that the user has permission to view secure results by triggering authorization checks. These authorization checks might have a negative impact on system performance.

Enabling or Disabling Dynamic Result Clusters

The Google Search Appliance supports two methods of enabling and disabling dynamic result clusters:

You cannot use the Page Layout Helper to enable or disable dynamic result clusters if you have customized the XSLT stylesheet. If you have done this, you must enable or disable dynamic result clusters directly in the XSLT stylesheet.

If you want to use a customized XSLT stylesheet from an earlier release, refer to the update instructions for the current search appliance software release.

Using the Page Layout Helper

To enable or disable dynamic result clusters using the Page Layout Helper:

Using the XSLT Stylesheet Editor

This section describes enabling dynamic result clusters using the XSLT Stylesheet Editor. If you prefer, you can edit the XSLT stylesheet in another editor.

To enable dynamic result clusters in an XSLT stylesheet:

<!-- *** dynamic result cluster options *** -->

<xsl:variable name="show_res_clusters">0</xsl:variable>

<xsl:variable name="res_cluster_position">right</xsl:variable>

Back to top

Using Dynamic Navigation to Help Users Explore Results

In many cases, content already has considerable metadata associated with it. As a search appliance administrator, you can use metadata to help users refine their search results by using Dynamic Navigation. When a user clicks on an attribute value, the search results are filtered to contain results from the original search query that also have that specific attribute value. The options are refreshed with the attribute values that are applicable to the new result set. Users can select multiple attributes and can easily back out of their selections to navigate the result set and quickly locate the results they are looking for.

With dynamic navigation, you can use the following types of attributes:

For example, suppose multiple HTML documents in mediacompany.com's corpus include the following metadata value pairs:

<META NAME="author" CONTENT="Nikhil Jain">

<META NAME="author" CONTENT="Radha Chandika">

<META NAME="author" CONTENT="Rajat Mukherjee">

By using the Search > Search Features > Dynamic Navigation page, you can add the author attribute so that it appears as a “Author” option on the search results page. All the values associated with the author attribute appear under the option, as shown in the following figure.

Dynamic navigation displays the counts for all matching results, as well as the number of values not displayed for an attribute, with a More link. Dynamic Navigation also provides search with auto-completion for attributes that have more values to display. This is indicated by a search icon (small magnifying glass) in the attribute name bar. To activate search with auto-completion, the user clicks the attribute name bar. As the user types in the search box, she can select any value in the auto-completion drop-down menu to filter the results.

You can use dynamic navigation by performing the following tasks:

A configuration defines the metadata attributes that are used to generate dynamic navigation options. By using the Search > Search Features > Dynamic Navigation page, you can create different configurations and apply the configurations to different front ends.

There is no limit to the number of attributes that you can configure in dynamic navigation. However, adding more attributes might affect search latency. The maximum number of results returned per attribute is 5000.

Also, for any configuration, you can enable dynamic navigation for secure search. With secure search, dynamic navigation only includes documents that the user is authorized to see. For more information, see Dynamic Navigation for Secure Search. You can also configure the search appliance to automatically expand configured dynamic navigation attributes to include other terms. For more information, see Configuring Query Expansion for Dynamic Navigation.

Dynamic Navigation for Secure Search

With dynamic navigation for secure search, the search appliance only uses documents that the user is authorized to see to generate navigation options. Only attributes and values that are in the accessible documents appear in the options and the counts include only the accessible documents.

To use dynamic navigation for secure search, enable it for a configuration and select one of the following authorization modes:

For information about how to enable dynamic navigation for secure search, see Creating a Configuration and Adding Attributes.

Fast Authorization Mode

In fast authorization mode, the search appliance only performs authorization based on Access Control Lists (ACLs) and checks results that are

already available in cache to generate dynamic navigation options. It ignores documents that require real-time authorization. If the search appliance ignores some documents, it indicates this with a greater than sign (>) in the count that appears with the dynamic navigation options.

Google recommends using fast authorization mode, which is the default mode.

All Authorization Mode

In all authorization mode, the search appliance uses all types of authorization methods to generate dynamic navigation options. If ACLs are not the primary method of authorization, users might receive query timeout errors (500) when performing searches. If this happens, you might consider using fast authorization mode instead.

Google recommends using all authorization mode only under the following conditions:

Enabling Dynamic Navigation

Dynamic navigation is disabled by default. To enable dynamic navigation:

To disable dynamic navigation, click Disable.

Creating a Configuration and Adding Attributes

By using the Search > Search Features > Dynamic Navigation page, you can configure different attributes in different configurations and apply the configurations to different front ends. Because an attribute that you add by using this page must exactly match the metadata NAME, ensure that you have the correct name from the metadata attribute before adding the dynamic navigation attribute.

To add a new configuration and attribute:

After this step, the search appliance starts computing the dynamic navigation results for the selected front ends but does not yet show the results on the search pages. However, you can see the dynamic navigation results in the search XML output. To display the dynamic navigation results on the search page, follow the procedure in Showing Dynamic Navigation in a Front End.

For complete information about dynamic navigation configurations, click Admin Console Help > Search > Search Features > Dynamic Navigation in the Admin Console.

Showing Dynamic Navigation in a Front End

After enabling dynamic navigation, creating a configuration with some attributes, and applying the configuration to a front end, you can show dynamic navigation with search results in a specific front end.

To show dynamic navigation in a front end:

Configuring Query Expansion for Dynamic Navigation

The search appliance enables you to configure query expansion (see Using Query Expansion to Widen Searches) for configured dynamic navigation attributes.

To configure query expansion for dynamic navigation:

Dynamic Navigation starts using these synonyms in its calculations for a query against that front end.

Back to top

Providing Expert Search for Users

You can enhance the search experience for your users with expert search, which enables them to find experts in your organization. When a user searches on a keyword, such as “security,” a list of security experts appears in a sidebar next to search results.

This list includes photos, names, job titles, email addresses, locations, and phone numbers. There might also be a more detailed list of experts on a separate page that is linked to the search results page.

To use expert search, perform the following tasks:

You can determine the profile elements and their layout in both the sidebar and on a separate page when you configure expert search. Because expert search is configured by front end, you can create different configurations for that address the needs and levels of different end users.

Configuring Data Sources for Expert Search

The search appliance gets profile properties for expert search from collections that only contain profile metadata. Data sources for this collection can include Microsoft SharePoint, LDAP, or any other profile content with metadata that can be crawled or fed into the search index.

Before configuring expert search for a front end, add profile metadata to the index. You can add it through crawling documents or databases with metadata, using feeds, or by using connectors, such as the SharePoint or LDAP connectors. After populating the index with metadata, you can add a collection that only contains the profile metadata.

For complete information about configuring data sources for expert search, click Admin Console Help > Search > Search Features > Expert Search in the Admin Console.

Enabling and Configuring Expert Search

To enable and configure expert search for a front end, use the Configure User Interface tab on the Search > Search Features > Expert Search page. This tab lists all the front ends that have been created for the search appliance.

To enable and configure expert search:

For complete information about enabling and configuring expert search, click Admin Console Help > Search > Search Features > Expert Search in the Admin Console.

Using People Search

In the current search appliance release, people search is deprecated.

With people search, when a user searches on a keyword, the search appliance searches any source collection that you specify and displays people search profiles that match the search term in a sidebar next to ranked search results.

For example, suppose a user searches for “Lee.” People search results appear in the sidebar on the search results page, as shown in the following figure.

People search profiles can include:

The profile information that appears in people search results is derived from metadata attributes found in the HTML of the documents in the search index, or metadata from databases, feeds, or connectors, including the LDAP connector. If the profile information for a single person is drawn from multiple sources, then this information must be merged into a single document before it is sent to the search appliance.

Before configuring people search, populate the search index with content and metadata for people search. By using metadata attributes and the Search > Search Features > Expert Search page, you can configure the attribute profile information that you want to appear in search results.

For example, suppose your people database includes the following metadata attribute value pairs:

<meta name="cn" content="Benjamin Grimm"/>

<meta name="uid" content="bgrimm"/>

<meta name="title" content="Test Pilot"/>

<meta name="location" content="401D"/>

<meta name="telephoneNumber" content="+1 (555) 465-2782"/>

<meta name="manager" content="Lee"/>

By configuring people search using this metadata, you can enable the search appliance to return people search profiles, such as the one for Benjamin Grimm, shown in the preceding figure. For information about how to specify attribute names on the Search > Search Features > Expert Search page, click Admin Console Help > Search > Search Features > Expert Search in the Admin Console.

You can enable the search appliance to return people search results by performing the following tasks:

Before configuring people search, create a people search source collection. A people search source collection is a segment of the search index that contains profile information. The source collection must contain one document for each person. You can create a people search source collection by using the Index > Collections page in the Admin Console. For information about creating a collection, click Admin Console Help > Index > Collections.

Configuring People Search

To configure people search:

For complete information about configuring people search, click Admin Console Help > Social Connect > People Search in the Admin Console.

Showing People Search Results in a Front End

After you configure people search, show the people search results sidebar element in a front end.

To show the people search sidebar element in a front end:

Back to top

Experimenting with Host Crowding Options

You might notice that search results are sometimes indented, as shown in the following example.

The indenting indicates “host crowding,” or presenting only the most relevant search results by eliminating duplicates. To eliminate duplicate search results, the search appliance uses the following automatic filters:

By default, automatic filters are enabled and host crowding significantly reduces the number of results returned.

In some situations, you can turn off host crowding by disabling one or more automatic filters to produce better relevancy. You might want to experiment with the settings for the Duplicate Directory filter and/or the Duplicate Snippet filters.

To disable the Duplicate Directory filter and/or the Duplicate Snippet filter, use the filter query parameter. For information about this topic, refer to Filtering in the Search Protocol Reference.

Back to top

Using Filters to Restrict Search Results

As an administrator, you can create custom filters for a front end to ensure that the search appliance serves appropriate results to end users. Filters are especially useful when a search appliance has multiple front ends for multiple types of end users.

The following table lists the types of filters you can create, with references to sections that provide more details on each type of filter.

 

Filter	Description	Refer to
Domain	This type of filter restricts searches to one or more domain names (not IP addresses).	Restricting Search Results by Domain Name
Language	This type of filter restricts searches to either all languages or a selected set of languages.	Restricting Search Results by Language
File type	This type of filter restrict searches to one or more content types or file types, such as HTML, PDF, and so on.	Restricting Search Results by File Type
Meta tag	This type of filter restricts searches by values and value types in meta tags.	Restricting Search Results by Meta Tag

You can use multiple filters in a front end. For example, a front end that is used in a specific region could filter results by both domain and language.

Working with Filters

To work with filters, use the Filters tab on the Search > Search Features > Front Ends > Output Format page in the Admin Console. For complete information about using the Filters tab, click Admin Console Help > Search Features > Front Ends > Filters in the Admin Console.

Restricting Search Results by Domain Name

You can use a domain filter to restrict results by domain name.

Suppose you want to ensure that searches in various regions return only results with local information. For example, you want to restrict results on the Australian pages to show only products and special offers available there, so you create a front end for users in Australia.

The domain name for Australia is www.mediacompany.com.au. You might use this domain name to create a domain filter so that when end users in Australia perform a search, only results that match the domain name appear. All domains ending with the name are filtered. For example, the domain mediacompany.com.au returns search results in all of the following domains:

However, if the domain name is followed by a directory name, the domain name must be fully qualified when you enter it on the Filters tab. For example, mediacompany.com.au/marketing does not return any results under the domain name filter alone. The correct filter is www.mediacompany.com.au/marketing. If the directory marketing is in multiple domains, each filter must be specified individually on the Filters tab—one per line, one for each domain, as shown in the following example:

Restricting Search Results by Language

You can use a language filter to restrict results by language.

Suppose you have created a front end for users in Switzerland. You want to restrict search results for this front end to the country's three official languages, German, French, and Italian. You might create a language filter for the Switzerland front end with these languages selected. When end users in Switzerland perform a search, only results in the selected languages appear.

When the search appliance receives a language-restricted search request for which there are no results in the languages specified by a filter, it displays search results in all languages. If search users in Switzerland perform searches for which there are no results in German, French, or Italian, the users see results in other languages that are represented in the indexed content.

You can also create a filter with the Filters tab to display results for pages in any language.

Restricting Search Results by File Type

The search appliance can crawl many file types. You can use a file type filter to restrict results by file type. For a list of file types that the search appliance can crawl, click Admin Console Help > More Information > Crawling and Indexing in the Admin Console.

Suppose you have created a front end for mediacompany.com's sales staff. The only documents that interest the sales staff are in Portable Document Format (.pdf) or Microsoft PowerPoint (.ppt) format. You can create a file type filter that serves only these file types in the sales staff front end. When members of the sales staff perform a search, only results of the selected file types appear.

Restricting Search Results by Meta Tag

You can use meta tag filters to restrict results by meta tags and meta tag values.

The site www.mediacompany.com sells DVDs worldwide. Most DVDs are encoded by region. For example, DVDs encoded for region 1 (Canada, the United States, Bermuda, the Cayman Islands, and U.S. territories) play only on region 1 players.

On the website, each DVD has a product page that includes a meta tag indicating its region, as shown in the following example.

<META NAME="region" CONTENT="region_1">

Suppose you have created a front end for users in region 1. You can restrict search results to products for region 1 only. You might create a meta tag filter for the region 1 front end so that only documents with CONTENT=region_1 appear. When end users in region 1 perform a search, only results for DVDs that are playable in region 1 appear.

Value Type Input Parameters

You can also filter results by the values of the results' meta tags using the requiredfields and partialfields input parameters in a search query. For information about these input parameters, refer to the Search Protocol Reference.

If you set meta tag filters in the front end (using the Meta Tag Filter area), the search appliance appends these settings to the search query as requiredfields and partialfields input parameters. If you set meta tag filters in both the front end and in requiredfields and partialfields input parameters, the front end settings overwrite any input parameters that you have added to the search query.

The following table lists front end meta tag value types and the input parameters that the search appliance appends to the search request for each value type.

 

Front End Value Type	Input Parameter
Exact	requiredfields=name:value
Partial	partialfields=name:value
Existence	requiredfields=name

Selecting a Query Expansion Policy for Meta Tags

Use a query expansion policy for meta tags to select the parts of the name/value pair in a meta tag that the search appliance expands with synonyms. The data used in this expansion comes from the query expansion files listed under Synonyms Data on the Search > Search Features > Query Settings page. Each file can be enabled and disabled independently for normal query expansion, meta name expansion and meta value expansion. Google recommends using a separate file for meta tag expansion. Using the normal language file may result in unintended expansions, such as stemming words.

If you have dynamic navigation enabled on this front end, enabling query expansion for meta tag also affects dynamic navigation. For more details, click Admin Console Help > Search > Search Features > Dynamic Navigation.

To set the query expansion policy for meta tags, use the Filters tab of the Search > Search Features > Front Ends page in the Admin console. For complete information about using the Filters tab, click Admin Console Help > Search > Search Features > Front Ends > Filters in the Admin Console.

To set the query expansion policy for meta tags for a front end:

To disable the query expansion policy for meta tags for a front end:

Back to top

Removing URLs from Search Results

Occasionally, a search index contains URLs that the search appliance should not serve. For any front end, you can prevent the search appliance from serving URLs that match specific patterns.

For example, suppose you do not want the search appliance to serve results about out-of-print DVDs in the customer front end. All documents that pertain to out-of-print DVDs are located in www.mediacompany.com/obsolete/. To prevent results from this URL being served, enter the URL pattern in the box on the Remove URLs tab. The URL patterns you provide must conform to the rules for valid URL patterns (see Constructing URL Patterns in Administering Crawl).

You can add URL patterns at any time, and they will be immediately removed from the served results. You can also delete the URL patterns at any time to return those patterns to the served results immediately.

For complete information about using the Remove URLs tab, click Admin Console Help > Search > Search Features > Front Ends > Remove URLs in the Admin Console.

The remove URLs feature affects results only. It does not remove URLs from the index. To remove URLs from the index, enter them in the Do Not Follow Patterns section on the Content Sources > Web Crawl > Start and Block URLs page in the Admin Console. For more information about removing URLs from the index, refer to Administering Crawl.

Back to top

Using Query Expansion to Widen Searches

The Google Search Appliance can automatically expand search terms to include other terms. This expansion is based on synonyms, or alternative terms for the original search term, as well as inflection variants, and related terms. The search appliance includes the following types of query expansion files:

Additionally, you can add your own customized local query expansion files to a search appliance.

Whenever a term matches a built-in synonym, the query is expanded to include the synonym. For example, suppose a user searches with the term “video.” Because this term matches a built-in synonym (“DVD”), the search is expanded to include the term DVD.

You can add your own set of meaningful terms to be added as synonyms. When query expansion is enabled, all synonyms on a search appliance apply to all front ends. To add terms for a specific front end, consider adding related queries instead (see Using Related Queries to Suggest Alternative Searches).

There are two steps to adding synonyms to query expansion:

Working with Query Expansion Files

This section describes tasks for managing query expansion files for a Google Search Appliance, including:

To manage query expansion files, use the Search > Search Features > Query Settings page in the Admin Console. For complete information about using the Query Settings page, click Admin Console Help > Search > Search Features > Query Settings in the Admin Console.

Using Preconfigured Local Query Expansion Files

By default, query expansion terms are available in several languages. The Google Search Appliance's default language bundle contains these languages. You can change the supported languages by installing and activating a different language bundle (see Changing Languages for Query Expansion and Spelling Suggestions).

For customers who are using the supported languages, the following preconfigured synonyms files are provided with the search appliance:

These files appear by default in the list of query expansion files on the Search > Search Features > Query Settings page in the Admin Console. Each file contains a set of common words that can supplement standard terms. By default, Google_English_stems is enabled.

You can use a preconfigured local file as it is. Alternatively, you can:

To perform any of these tasks, go to the Search > Search Features > Query Settings page.

You cannot delete preconfigured local files.

Using Customized Local Query Expansion Files

You can use customized local query expansion files to configure site-specific terminology. For example, you might:

A local synonyms file is a text file of three megabytes or less, containing case-insensitive entries.

Follow these steps to create a local synonyms file:

Entry format 1: term1 operator term2

In this format:

Examples:

ebu = education business unit

tbu = telecomm business unit

telecom business unit = telecomm business unit

partner > indirect sales

widgets > parts, widgets > items

A query where the search term is ebu is expanded to include additional documents that contain the phrase educational business unit. A query where the search term in educational business unit is expanded to include additional documents that contain the term ebu. Notice that the two queries, ebu and educational business unit, are not equivalent. Also, a query where the search term is a phrase (enclosed by quotation marks), such as "educational business unit," is not expanded.

Entry format 2: {term, term, ...}

In this format:

Examples of valid entries:

{run, runs, running, ran}

{widgets, parts, items}

Example of an invalid entry:

{safe}

For information about uploading a synonyms file, click Admin Console Help > Search > Search Features > Query Settings in the Admin Console.

Using Blacklists

You can control query expansion by creating a blacklist. A blacklist is a set of words that are excluded from query expansion. A blacklist can be useful for eliminating unwanted search results that result from synonym matching and clarifying special words used in your environment.

For example, suppose mediacompany.com starts a new project with the code name “glue.” You could add “glue” to the blacklist to ensure that user queries do not expand to include “adhesive.”

A blacklist file is a text file of three megabytes or less, containing a simple case-insensitive list of single words, with one word on each line.

Follow these steps to create a blacklist file:

This is an example of a blacklist file:

#Blacklist file created July 2006 

#Author: lana

glue

component

This file prevents queries for “glue” and “component” from being enhanced with synonyms.

For information about uploading a blacklist file, click Admin Console Help > Search > Search Features > Query Settings in the Admin Console.

Using Stopwords

A stopword is a search term that is ignored by the search appliance. Examples of stopwords include “to,” “a,” and “the.” However, if a stopword is the only keyword in a query, it is not ignored. For example, if "salary" is a stopword is and a user submits a query where "salary" is the only keyword, the query will execute and display results. But if a user searches for "my salary," "salary" is ignored.

A stopwords file is a text file of three megabytes or less, containing a case-insensitive list of one or more alphanumeric stopwords. By default, the search appliance has 26 files of stopwords for supported languages. For a list of the default stopwords files, see the files listed under Stopwords Data on the Search > Search Features > Query Settings page. Of these files, two are enabled by default: Google_Default_Stopwords and Google_English_Stopwords. Additionally, you can create and upload your own stopwords files.

To create a Stopwords file:

The following example shows an excerpt from the contents of the Google_Default_stopwords.txt file. Each of the following words is ignored in a search query.

the

of

to

in

for

is

on

that

by

with

this

be

it

www

are

...

For information about uploading a stopwords file, click Admin Console Help > Search > Search Features > Query Settings in the Admin Console.

For a stopwords file for a particular language to take effect, searches must be restricted to the same language. For example, if you upload and enable a stopwords file for French, searches must be restricted to French for those stopwords to take effect.

Searches can be restricted to a particular language in either of the following ways:

For information about creating a language filter in a front end, see Restricting Search Results by Language. For information about language restrict query parameter, see the Search Protocol Reference.

Files with Macintosh style end-of-line characters

Some text files created in Macintosh OS use Mac-style end-of-line characters (/r). Before uploading a synonyms or blacklist file that contains this style of end-of-line characters, ensure that the first line in the file is not a comment (that is, starts with #).

Setting the Query Expansion Policy for a Front End

After you have configured and enabled the appropriate query expansion files, you can set a query expansion policy for a front end. A query expansion policy determines the synonym or blacklist files that are used with a front end. You can use just one type of file or use both types of files together. You can create a combined total of up to 300 files with a front end.

The following table describes the query expansion policies that you can set for a front end.

 

Query Expansion Policy Setting	Description
None	Disables query expansion for the front end
Standard	Enables query expansion for the front end, using only the search appliance's internal contextual files
Local	Enables query expansion for the front end, using all displayed and activated synonym files, including any uploaded files.
Full	Enables query expansion for the front end, using both Google's built-in synonyms and the files that you upload to the appliance

Query expansion files are used only if the query expansion policy for a front end is set to Local or Full on the Search > Search Features > Front Ends > Filters tab.

To set the query expansion policy for a front end, use the Filters tab of the Search > Search Features > Front Ends page in the Admin console. For complete information about using the Filters tab, click Admin Console Help > Search > Search Features > Front Ends > Filters in the Admin Console.

Back to top

Enabling Translation of Search Results

The Google Search Appliance can translate titles and snippets in search results, as well as cached documents into the user’s language in real time. The user’s language is determined by the default language set in the user’s browser. When translation is enabled, translation links appear in search results. The user can translate everything on the page or just individual titles, snippets, or cached documents. Take note that translate does not work for the Document Preview feature.

When the user clicks a translation link, the search appliance sends the content, client-id, and user language to Google Translate using a secure connection. For more information about the Website Translator plugin, visit the Google Translate Help Center. Google recommends that Internet Explorer customers use translate from the HTTPS search results page.

You can enable or disable translation for any front end. To enable translation, use the Search > Search Features > Front Ends > Output Format page in the Admin Console. For complete information about using this page, click Admin Console Help > Search > Search Features > Front Ends > Output Format - Page Layout Helper in the Admin Console.

Back to top

Changing Languages for Query Expansion and Spelling Suggestions

A language bundle is a collection of resource files that the Google Search Appliance uses for query expansion and spelling in several languages. The following table lists the language bundles that Google provides.

 

Language Bundle	Languages	Download Link
Built-in	• Dutch • English • French • German • Italian • Portuguese • Spanish	Installed on the Google Search Appliance by default
All languages	• Arabic • Danish • German • Greek • English • Spanish • Finnish • French • Hungarian • Italian • Hebrew • Japanese • Korean • Dutch • Norwegian (includes both Bokmål and Nynorsk) • Polish • Portuguese • Romanian • Russian • Swedish • Thai • Turkish	http://dl.google.com/dl/enterprise/all_langs-lang-pack-2.2-1.bin
Scandinavia	• English • German • Dutch • Swedish • Norwegian (includes both Bokmål and Nynorsk) • Danish • Finnish	http://dl.google.com/enterprise/scandinavia-lang-pack-2.1-1
Middle East	• Arabic • Greek • English • French • Hebrew • Turkish	http://dl.google.com/enterprise/mid_east-lang-pack-2.1-1
Eastern Europe	• German • English • French • Hungarian • Hebrew • Polish • Romanian • Russian	http://dl.google.com/enterprise/east_europe-lang-pack-2.1-1
egfisdfp	• English • German • French • Italian • Spanish • Dutch • Finnish • Polish	http://dl.google.com/enterprise/egfisdfp-lang-pack-2.1-1.bin
Northern Europe + Eastern Europe + Extra languages	• English • German • Dutch • Swedish • Norwegian (includes both Bokmål and Nynorsk) • Danish • Finnish • Russian • Polish • Spanish	http://dl.google.com/dl/enterprise/mea_north_eastern-lang-pack-2.1-1.bin

You can enable search appliance support for a language bundle by performing the following tasks:

You can install multiple language bundles on a search appliance, but only one language bundle can be active at any time. By default, the built-in language bundle is active.

The currently active language bundle provides spelling support for the languages in the bundle, as well as query expansion. The Google Search Appliance supports several types of query expansion, including:

The search appliance supports contextual query expansion for all languages in the language bundles. Support for non-contextual query expansion is currently only available for Dutch, English, French, German, Italian, Portuguese, and Spanish.

You cannot delete the currently active language bundle. However, you can delete any other inactive language bundle that you no longer need.

To install and activate a language bundle, use the Search > Search Features > Language Bundles page in the Admin Console. For information about using this page, click Admin Console Help > Search > Search Features > Language Bundles in the Admin Console.

Back to top

Enabling/Disabling Click-Jacking Defense

Click-Jacking (sometimes called UI Redress) is a type of web attack where an attacker modifies the user interface of a target web site so that a victim does not realize that he is taking an important action.

For example, a malicious web site could iframe an approval page for granting access to a third-party application. When a user visits the malicious web site, the site would overlay the approval button on the targeted site with a dancing hamster. When the user clicked on the hamster, the click would be processed by the targeted site. The user would unknowingly have granted access to the third-party application.

When the click-jacking defense is enabled the search appliance sends an X-Frame-Options: SAMEORIGIN header to prevent the iframe of search results pages.

Also, when click-jacking defense is enabled:

By default, click-jacking defense is enabled.

To enable/disable click-jacking defense:

Back to top

Using OneBox Modules to Integrate Structured Results

In some instances, the most relevant result for a search query is real-time, structured data. This type of data does not usually reside in the search index because it would be obsolete before it could be indexed.

For example, as a service to its users, mediacompany.com provides information about local movie times. When a user searches for “movies,” a specially formatted search box appears at the top of the search results, as illustrated in the following figure.

When a user enters a location in the search box, formatted, real-time data about theater show times appear, as illustrated in the following figure.

This type of result is served by a OneBox module. A OneBox module sends the user’s query to a back-end or third party system and retrieves relevant data immediately. A OneBox module is returned when an end user's search term matches a “trigger” term. In the previous example, the trigger is “movies.”

The search appliance supports two types of OneBox modules:

You can develop OneBox modules with the use of simple APIs and a standard XML format. A OneBox module that has been integrated with the search appliance can be used with any front end on the search appliance. A front end can use an unlimited number of OneBox modules.

For detailed information about developing OneBox modules, refer to the following documents:

Back to top

Using Result Biasing to Influence Result Ranking

The Google Search Appliance ranks the documents that it finds in response to a user search query. For each document, the search appliance calculates a score that:

You can use result biasing to increase or decrease the scores of specified sources, or types of sources, in the search index. These local settings may affect the order of the search results. You can influence results ranking by using:

Result biasing is one way to affect the order of results. You might consider using other features to meet the following objectives:

Working with Result Biasing

To influence search appliance rankings, use a result biasing policy. A result biasing policy determines the source biasing, date biasing, and metadata and entity biasing settings that are used with a front end. A default result biasing policy (default_policy) is built into the search appliance. You can use default_policy, or create one or more custom result biasing policies. A result biasing policy is specific to a front end, so it can be aimed at specific types of end users.

To work with result biasing:

If you are updating a search appliance with existing result biasing settings, your existing settings and any existing front ends that have result biasing turned on remain intact after the update.

For complete information about using the Search > Search Features > Result Biasing page, the Search > Search Features > Result Biasing > edit page and the Search > Search Features > Front Ends > Filters page, refer to the Admin Console Help in the Admin Console.

Using Source Biasing

Using source biasing, you can boost or weaken the relevancy score of a document that belongs to a specified collection, matches certain URL patterns, or is fed from a data source. Boosting a score usually moves a result up in the rankings. Weakening a score usually moves it down. The search appliance offers two controls over source biasing, as described in the following table.

 

Control	Description
Influence	Specifies how much influence source biasing has in calculating scores for results rankings overall. The default influence is No influence. You can change this to one of ten settings in a range of More influence for a search appliance.
Strength	Specifies how much influence source biasing has in calculating scores for documents that match specific URL patterns. The default strength is Leave unchanged. You can change this to Strong, Medium, or Weak increase or Strong, Medium, or Weak decrease for each collection or specified URL pattern.

For example, suppose most official content in your organization is drafted in Microsoft Word (.doc), but published in Portable Document Format (pdf). In some instances, both the .doc and .pdf versions of documents have the same content. However, each type of document is stored in a different location.

Both types of documents are crawled and appear in the search index. However, you want .pdf versions to be higher in the search results than .doc versions. You create a result biasing policy where you can influence the score of .pdf documents. For this result biasing policy, you can use source biasing to:

By adjusting the strength of individual URLs you influence the score that reflects the relevance of documents that match the URL patterns. After you select the result biasing policy for use with a front end, .pdf documents are more likely to appear closer to the top of results listings.

The effect of changing a document's score is not always predictable. The order of a search result among the other results is determined by many factors, including the scores of the other documents with which it is returned.

Using Date Biasing

Using date biasing, you can specify the influence date biasing has in increasing the scores of more recent documents relative to older documents. The default influence is No influence. You can change this to one of ten settings in a range of More influence for a search appliance.

For example, suppose the mediacompany.com search index contains all DVD reviews written during the past ten years. Typically, end users are interested in only searching the most recent reviews. However, staff is interested in searching for all reviews.

You have created a front end for end users and another front end for staff. In the front end for end users, you create a result biasing policy where you can configure date biasing to increase the rankings of new documents and lower the rankings of legacy documents. After you select the result biasing policy for use with the front end, documents with a more recent date are more likely to appear closer to the top of results listings.

In the front end for staff, you do not create a result biasing policy. This front end preserves normal ranking.

You can also specify how quickly documents' scores are decreased as they age, by selecting an age at which you would consider a document to be moderately old. This setting indicates that a document of the specified age should get a moderate decrease in score from date biasing. More recent documents get smaller date biasing effects, and documents older than that age get larger decreases in score.

For example, if you select “a day” as the age at which documents become moderately old, then documents that are a day old receive a moderate decrease in score from date biasing, and documents much older than that quickly get nearly the maximum effect of date biasing. On the other hand, if you choose “a year” as a moderately old age, then documents that are a year old get a moderate score decrease, those that are a few months old get their score decrease slightly, while documents that are a day old get very little date biasing effect.

In general, a good starting point for using this parameter is to think about some queries your users might issue and the types of pages they would get back. Consider how old a result would have to be before it is likely to be obsolete compared to pages authored or modified more recently. That age may be a reasonable setting for a document to be considered “moderately old,” although experimenting with different settings is the best way to find out how it affects your search results.

The date biasing feature does not provide results that are ordered strictly by date, because other factors are considered in a document's score. To order results strictly by date, any user can click the Sort by date link.

Date biasing is applied to search results in a flexible manner. To experiment with the settings to see how it affects the documents in your index. You'll typically notice that date biasing affects the order of recent documents with small differences in date more than it affects older documents with small differences in date.

Which Document Dates Are Used for Date Biasing?

The document date that the Google Search Appliance evaluates for date biasing is specified on the Index > Document Dates page. For example, the search appliance can use one of the following dates:

However, if a document is added to the index by a feed rather than by a crawl, the document might not have a useful associated date for use with date biasing.

Using Metadata and Entity Biasing

Using metadata and entity biasing, you can boost or weaken the relevancy score of a document based on metadata or entities associated with a document. Boosting a score usually moves a result up in the rankings. Weakening a score usually moves it down. The search appliance offers two controls over metadata and entity biasing, as described in the following table.

 

Control	Description
Influence	Specifies how much influence metadata and entity biasing has in calculating scores for results rankings overall. The default influence is No influence. You can change this to one of ten settings in a range of More influence for a search appliance.
Strength	Specifies how much influence metadata and entity biasing has in calculating scores for documents that match specific META tag NAME-CONTENT value pairs. The default strength is Leave unchanged. You can change this to Strong, Medium, or Weak increase or Strong, Medium, or Weak decrease for each specified URL pattern.

For example, suppose that you have created a front end for your organization's human resources department. For users of this front end, you want to boost the score of HTML documents that include meta tags that indicate human resources as the author, as shown in the following example.

<META NAME="author" CONTENT="human_resources">

To bias metadata, create a result biasing policy called human_resources and configure metadata and entity biasing for this policy by entering the metadata name and content (value) pair and strength to apply to the score of any document that contains the metadata. After you select the human_resources policy for use with the front end, documents by human_resources are more likely to appear closer to the top of results listings. If you use metadata and entity biasing to weaken the score of documents by human_resources, those documents are likely to appear lower in the results listing.

If more than one meta data pair is configured, the document is tested against each metadata pair in turn until one matches. If more than one metadata pair matches, only the first one is used. In addition to working with metadata that is contained within HTML documents, metadata biasing also works with external metadata that is associated with documents.

If you have configured entity recognition, the search appliance discovers interesting entities in documents and stores them in the index. For example, suppose that the search appliance has discovered the term “human resources” in documents with poor or missing metadata. To bias this entity, you can configure metadata and entity biasing by selecting “human resources” from the pull-down menu and entering entity content.

The search appliance only applies metadata and entity biasing to the more relevant URLs, rather than all the URLs, that match the search query.

The effect of changing a document's score is not always predictable. The order of a search result among the other results is determined by many factors, including the scores of the other documents with which it is returned.

Back to top

Providing Alerts for End Users

Some users might want to monitor topics of interest by receiving search results for these topics in email messages. You can allow users to monitor topics this way by enabling alerts. Alerts are email updates of the latest relevant search results based on a user's topic of interest.

A user sets up an alert by clicking My Alerts on the search page (shown in the following figure) and then logging in to the search appliance.

On the Manage your Alerts page, the user can create an alert by identifying search terms that will return relevant results and a frequency of searches. After the user creates an alert, the search appliance sends the user an email whenever it finds new or changed documents about the topic of interest. The following figure shows the Manage your Alerts page.

For example, suppose a user is interested in changes to personnel policies. He might create an alert for this topic. The search appliance will run searches on all the publicly shared documents and send an email to the user whenever it finds new or changed publicly-shared documents about changes to personnel policies (secure results are not returned). The email contains a batch of result listings. Clicking any result listing in an alert email displays the relevant document.

To provide alerts for users, you must:

Alert emails use the sender of outgoing emails that is specified in the Email Notification area on the Administration > System Settings page during search appliance installation. If the sender of outgoing emails is not specified during installation, the default value of nobody@localhost is used. For information about specifying the value of sender of outgoing emails, refer to Configuring the Network Settings in Installing the Google Search Appliance.

Enabling Alerts

If alerts are not currently enabled for a search appliance, you can enable them using the Index > Alerts page in the Admin Console (see Providing Alerts for End Users). If alerts are enabled, you can disable them.

To enable alerts for a search appliance:

To disable alerts for a search appliance:

Showing the My Alerts Link

The Google Search Appliance supports two methods of showing the My Alerts link on a search page:

You cannot use the Page Layout Helper to show the My Alerts link if you have customized the XSLT stylesheet. If you have done this, you must show the My Alerts link directly in the XSLT stylesheet.

If you want to use a customized XSLT stylesheet from an earlier release, refer to the update instructions for the current search appliance software release.

Using the Page Layout Helper

To show the My Alerts link using the Page Layout Helper:

Using the XSLT Stylesheet Editor

This section describes showing the My Alerts link using the XSLT Stylesheet Editor. If you prefer, you can edit the XSLT stylesheet in another editor.

To show the My Alerts link in an XSLT stylesheet:

<!-- *** alerts2 options *** -->

<xsl:variable name="show_alerts2">0</xsl:variable>

Back to top

Providing User Results

You can give users the capability of enhancing the search experience collaboratively by adding search results for certain keyword searches. User results appear for the specified keyword searches on the search results page of a specific front end.

For example, suppose a user wants a document about your organization's new vacation policies to appear on the results page when anyone searches using the keyword “vacation.” To accomplish this, the user can create a result for the document.

When anyone searches on “vacation,” the user result always appears on the results page. The result displays the title, the specified URL, and the user's name, as shown in the following example.

Duplicate results are not displayed. So for a given query if any newly submitted result has the same URL as a pre-existing result, then it is not returned in the search page.

To provide user results capability, add one or more user results configurations. Google recommends enabling query suggestions (see Providing Query Suggestions) with user results so that they can appear as query suggestions.

Adding a User Results Configuration

To add a user results configuration, use the Search > Search Features > User Results page.

For each configuration, you can specify:

Because a user result configuration can be associated with one or more front ends, you can create multiple configurations with different settings and associate them with separate front ends.

For complete information about adding a user results configuration, refer to the Admin Console Help > Search > Search Features > User Results page in the Admin Console.

Moderating User Results

By using the Search > Search Features > User Results page, you can moderate new or existing user results. When there is one or more new user results to validate, a Validate link on the page is highlighted in red and shows the number of results awaiting validation.

You can moderate either all user results at once or one or more individual results.

Enabling Authentication for User Results

When you enable authentication for user results, a user must be properly authenticated with a verified identity before the user can add, edit, or remove user results.

If authentication for user results is enabled, and the user is not logged in with a proper verified identity, the user cannot add, edit, or delete user results. If authentication for user results is not enabled, the user is not required to be properly authenticated before adding, editing, or removing them.

To enable authentication for user results:

To disable authentication for user results:

How Users Can Add Results

To add a result, a user performs the following steps:

If you, as the search administrator, are not moderating search results, the user result begins to appear immediately for the appropriate keyword searches.

If you are moderating user results, a confirmation box appears telling the user that the new result requires your approval. To submit the result, click OK. After you approve the result, it begins to appear for the appropriate keyword searches.

Back to top

Providing Query Suggestions

You can help users improve searches by enabling query suggestions for a new or existing front end. When query suggestions are enabled, search queries auto-complete and query suggestions appear as a user types in the search box.

For example, suppose a user starts typing “Google Search Appliance” in the search box. Query suggestions causes the term to auto-complete before the user finishes typing it. Alternative terms that narrow the search also appear in a menu below the search box. For example, for this search, terms that appear might include “Google Search Appliance training,” “Google Search Appliance documentation,” “Google Search Appliance Forum,” and other similar terms. Query suggestions can include user results (see Providing User Results), which are displayed in italic font style. The user can execute a search by selecting one of the terms.

To provide query suggestions:

Query suggestions are created by using the terms entered in previous searches. Only queries that returned results are used to build the database of query suggestions.

Each query suggestion entry is tagged under a unique front end and collection pair based on the previous searches. Query suggestion requests must be made against the same front end and collection pair to get suggestion results. Queries against multiple collections (using AND or OR boolean operators) are not made available as suggestions.

The search appliance automatically refreshes query suggestions every 24 hours, so it might be a day before a new query suggestion is available. However, you can manually trigger a refresh of query suggestions by toggling suggestion off and on again for the front end.

The search appliance keeps query suggestions for 90 days. If you delete the matching document from the index or reset the index, the query suggestion continues to appear, even though the suggestion does not return results.

To refresh query suggestions:

Exporting Query Suggestions

You can see which query suggestions the search appliance is using by exporting them. When you export query suggestions, the search appliance creates a file that contains an inventory of all query suggestions. Using the options on this page, you can export query suggestions for:

You can also select one of the following options for the format of the exported query suggestions file:

To export query suggestions:

Exporting and Importing the Suggestions Blacklist

The search appliance also has a suggestions blacklist, which contains words that are excluded from query suggestions. If you want to change the blacklist, you can use the options on the Search > Search Features > Suggestions page to perform the following tasks:

You can export the search appliance's suggestions blacklist by using the options under Export Suggestions Blacklist. To export a suggestions blacklist

You can import a suggestions blacklist by using the options under Import Suggestions Blacklist. To import a suggestions blacklist:

The imported suggestions blacklist overwrites the existing one. To remove the existing blacklist, upload an empty file.

A partial match is used for entries in the suggestions blacklist. For example, an entry for ray in the blacklist blocks ray and raymond. To block only ray, use regular expression ^ray$.

Back to top

Providing Document Previews

Document previews enable users to view a thumbnail image of a document in the search results. To view a document preview, the user hovers the pointer over the search result. The preview appears, as shown in the following figure.

The search appliance supports document previews for the following formats:

However, document previews are not available for .doc, .pdf and .ppt files in zip files.

To provide document previews to your users, perform the following tasks:

For complete information about providing document previews, click Admin Console Help > Search > Search Features > Document Preview Module in the Admin Console.

For information about document preview limitations, see Specifications and Usage Limits.

Back to top

Enabling Wildcard Search

Wildcard search enables your users to search by entering a word pattern rather than the exact spelling of a term. The search appliance supports two wildcard operators:

The search appliance is able to consider all words with * as wildcard terms, so users don't need to prepend the wildcard: special operator to a pattern that contains this operator. To enable the search appliance to do this, click the Consider words with * as wildcards by default checkbox on the Search > Search.

Using wildcards can simplify queries for long names, technical data, pharmaceutical information, or strings where the exact spelling varies or is unknown. A user can search for all words starting with a particular pattern, ending with a particular pattern, or having a particular substring pattern. A wildcard query term must satisfy at least one of the following conditions:

To search using a wildcard pattern, prepend the wildcard: special operator to a pattern. For example: wildcard:test* and wildcard:?nter.

For more information about the wildcard: special operator, see the Search Protocol Reference. Wildcard search is also supported for metadata queries, but the wildcard: special operator is omitted. For example: inmeta:name*. Also, metadata queries are %-encoded, which affects the form of an inmeta: wildcard query.

To enable wildcard search:

Wildcard search is not supported for other common queries, including filetype, inurl, intext, and so on. Also, wildcard search is not supported with Chinese, Japanese, Korean, or Thai languages.

For complete information about enabling wildcard search, click Admin Console Help > Search > Search Features > Front Ends > Filters in the Admin Console.

Back to top

Tuning Search Results

Serving quick and relevant search results helps ensure user satisfaction with the search experience. Ways that you, as an administrator, can help maintain results include:

Optimizing the Speed of Results

Studies show that you can lose more users due to poor response time than to poor relevancy. If you find that performance is less than optimal, perform the tasks described in the following table.

 

Task	Comments
Make sure you have the right search appliance model for handling your query load.	If your search appliance model is not appropriate for your query volume, you might consider upgrading to a higher-capacity model.
Ensure that your user interface is uncluttered and free from large images or backgrounds, and that it does not contain non-search related server calls.	Any of these items can slow down response time. If any of these items are present, consider removing them from the user interface.
Check whether the volume of search queries is affecting response time.	If the volume of search queries is affecting response time, consider getting a second search appliance and load balancing the two search appliances.
Determine whether your search appliance is trying to crawl more documents than your license limit allows.	If your search appliance is trying to crawl more documents than your license limit allows, consider the following options: • Whitelist URLs for crawling, as described in Using Only a Whitelist of URLs. • Increase the license limit of the search appliance. For information about increasing the license limit of your search appliance, contact Google for Work Sales.
Determine whether security checks are taking too long.	Before returning secure results to a user, the search appliance queries a secure server, such as an LDAP, SAML, or NTLM server, for user authorization. In some instances, the secure server's performance may compromise response time. If so, optimize the secure server.
Monitor your network traffic to find out if it is especially high.	Other devices on your network may be slowing down search appliance performance.

Analyzing Searches that Do Not Return Results

Sometimes, user search queries fail to return available information. In these instances, you can use front end configuration features such as KeyMatch (see Using KeyMatches to Guide Users to URLs), related queries (see Using Related Queries to Suggest Alternative Searches), and query expansion (see Using Query Expansion to Widen Searches) to provide better results.

To identify search terms that do not return results, generate a search report, as described in Generating a Report of Unsuccessful Search Queries. The report on searches that do not return results contains lists of top keywords and top queries that do not return results. The following example shows Top Keywords and Top Queries in a search report.

 

Top Keywords	#Occurrences
plans	920
retirement	812
savings	809
tax	667
pre	609
401K	511
options	332
employee	276
benefits	255

 

Top Queries	#Occurrences
401K	512
pre-tax savings plans	423
retirement	411
retirement plans	358
savings plans	358
retirement options	332
employee benefits	287
pre-tax plans	232
retirement savings	166

Notice that “pre-tax plans,” appears for 232 queries that did not return results. To suggest alternative search terms, create a related query, as shown in the following example:

You could also try: 401K Pre-Tax Plans

To guide end users to the URL where the information resides, create a KeyMatch, as shown in the following example:

Generating a Report of Unsuccessful Search Queries

When you generate a report of unsuccessful search queries, you specify the following information:

For example, you might create a report of unsuccessful search queries called Operations Zero Results Report on the default_collection for the previous week.

To create a report of unsuccessful search queries:

To view the report, click View under List of search reports.

Back to top

Managing the Search Index

A search index provides the foundation for a positive search experience. As an administrator, you can perform the following tasks to ensure that the index continues to support search effectively:

Keeping the Search Index Clean

You can help improve user searches by making sure that your index is as “clean” as possible. A clean index contains valuable documents and does not contain unnecessary documents. You can ensure a clean index when you set up the URLs for crawling your content on the Content Sources > Web Crawl > Start and Block URLs page in the Admin Console.

Generally, there are two methods for setting up URLs for crawling your content:

To keep the search index clean, you can use both methods together or simply use a whitelist. Generally, using only a whitelist is more effective than using only a blacklist. The following sections describe the advantages and disadvantages of both approaches. For information about setting up URLs for crawling your content, refer to Preparing Data for a Crawl in Administering Crawl.

If you have a search appliance that you use for testing, test your crawl patterns first and then deploy them if the quality of the search results has improved.

Using Both a Whitelist and a Blacklist of URLs

You can set up a crawl with a whitelist of URLs. After the search index has been created, you can prune unwanted URLs from the search index using a blacklist. Starting from the comprehensive list of start URLs and then pruning them has the benefit of ensuring that the crawler has found every document in your organization.

Using Only a Whitelist of URLs

An alternate approach is to set up a crawl with a whitelist that contains only URLs that you know to be valuable. This doesn’t mean you should get too specific and place specific low-level folders and documents in the Crawl list, but it does mean you should be cautious of what a large root node might bring into the index.

The benefit of this approach is that the index will not be bloated to include documents that may be unnecessary to index. The disadvantage of this approach is you need to be especially careful to include every start URL that might be of value.

Segmenting Data in the Search Index

User searches can be more efficient when they are restricted to subsets of the entire search index. As an administrator, you can help users to search more efficiently by using collections. A collection is a segment of the complete search index that you define by specifying URL patterns to include.

Using collections, you can show different results to different users. For example, suppose you want to create different collections, such as:

To search a collection, a user can select a collection from a pull-down menu on the search box, as illustrated in the following figure.

For more information about this topic, refer to Adding a Menu to Search by Collection in Customizing the User Interface.

The maximum number of collections for a search appliance is 200. Having more than this number of collections can cause serving to fail. The solution for this problem is to reset the index.

The search appliance allows you to create an unlimited number of collections for a search index. To create a collection, use the Index > Collections page in the Admin Console. For information about using this page to create a collection, see Admin Console Help > Index > Collections.

Searching Collections

Individual collection search results have the same relevance ranking as full index searches. Only the content searched differs as it is restricted to the individual collection's content.

To restrict searches to a collection that you have defined, add the following to the URL of your search query:

&site=COLLECTION_NAME

The following examples show search queries for searching collections.

A search for “vacation” in the collection Human_Resources:

http://www.google.com/search? q=vacation&output=xml&client=yoursite&site=human_resources

This search returns vacation results specifically from URLs in the Human_Resources collection.

A search for “product” in the collections Development and Marketing:

http://www.google.com/search?q=product&output=xml&client=yoursite&site= (development)|(marketing)

This search for “product” returns results from either the Development or Marketing collections.

For more information, see the Filtering section of the Search Protocol Reference.

Enabling Users to Search Multiple Collections

Once you have created collections, determine if users will ever want to search multiple collections at the same time. For example, you might want to enable a sales person to search the “Marketing” collection and the “Sales” collection. The Google Search Appliance allows search within multiple collections by using the “|” (OR) or “.” (AND) operator.

To specify the collection that you want to search, you set the site parameter on the GET request. The following example shows a GET request where the collection specified is one named “'all_content.”

http://search.corp.mycompany.com/search?q=query+string

                        &site=all_content

                        &client=default_frontend

                        &output=xml_no_dtd

                        &proxystylesheet=default_frontend

To search for terms that appear in either the “sales” or “marketing” collection, use the boolean OR [|] operator on the site parameter. The following example shows a GET request that specifies both collections.

http://search.corp.mycompany.com/search?q=query+string

                        &site=sales|marketing

                        &client=default_frontend

                        &output=xml_no_dtd

                        &proxystylesheet=default_frontend

To search for terms that appear in both the “engineering” and “support” collections, use the boolean AND [.] operator on the site parameter. The following example shows a GET request that specifies both collections.

http://search.corp.mycompany.com/search?q=query+string

                        &site=engineering.support

                        &client=default_frontend

                        &output=xml_no_dtd

                        &proxystylesheet=default_frontend

Once you have exposed these multi-select collections in your UI, make sure that the users know that they can segment a search to get better relevancy.

For complete information about using search parameters, refer to the Search Protocol Reference.

Back to top

Evaluating Search Performance

The most effective way for you to create an appropriate search experience is to focus on the end user. To gain insight into your user's opinions about search, you can solicit their feedback. Ways to solicit feedback from end users include:

In addition to getting feedback from end users, you might want to exchange ideas with other search appliance administrators or members of the Google for Work team. For information on this topic, refer to Exchanging Information on Google Groups.

Adding a Feedback Mechanism for Users

The number of user searches tends to increase when users can provide feedback about the quality of results. User feedback is also an effective way to identify usability issues. When you solicit feedback, you let users know that their opinions about the search experience are important. As users see improvements based on their feedback, they search more.

Some easy ways you can enable users to give feedback might include:

Feedback that is sent with the user information is very useful. It enables you to contact users to get clarification and show that you are following up with them.

Conducting a User Satisfaction Survey

A survey can be an effective way of soliciting feedback from users about the search experience. A survey also enables you to establish a baseline of search quality metrics before beginning to implement best practices.

Some tips for creating a user satisfaction survey are:

The following example questions might help you develop your own survey questions.

Finally, an effective way to evaluate the quality of search results is by using side-by-side evaluations. You could use this type of evaluation to test the following types of changes:

Exchanging Information on Google Groups

Google wants you to get all possible value from your Google Search Appliance. An effective way to do this is to join the Google Search Appliance Discussion Forum, http://groups.google.com/group/Google-Search-Appliance. This group is a discussion forum where you can post questions, feedback, or advice for other users. The group also provides access to a knowledge base and useful files for administering a Google Search Appliance.

Members of the Google Search Appliance group includes other Google Search Appliance customers, administrators, and users. Members of the Google Search Appliance product, engineering, and support teams monitor the groups and occasionally provide assistance to other members.

Back to top

Updating Your Search Appliance

There are usually many performance improvements, security enhancements, and/or features that are included in new Google Search Appliance software releases.

Unless Google for Work Support organization has advised you not to upgrade, you should always download the latest software release. If you are a current Google for Work customer, you can: