Search
Clear search
Close search
Google apps
Main menu

Creating the Search Experience

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.

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

See Enabling/Disabling Click-Jacking Defense

Divide the search index into meaningful partitions

Collections

See 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

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 Cloud and Google Groups

See Exchanging Information on Google Groups

Update to the most recent software version

Google Cloud Support site

Updating Your Search Appliance

Eliminate duplicate search results and provide the most relevant set of diverse results

Host crowding

See 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

See 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

See 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

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:

  • Engineering staff is searching for design documents and status information
  • Sales staff is searching for sales forecasts and reports
  • Customer support is searching for support metrics and update information

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:

  • Each group of users has a unique search experience where results are ranked according to their interests
  • Users find what they are looking for at the top of the search results

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:

  • Who needs a personalized search experience
  • How to personalize the search experience for each target group
  • Which search appliance features you should use to create personalized search experiences
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:

  • You might create multiple front ends to serve different results to users in various regions, worldwide. For users in a specific country, you might apply a language filter. This example is described in Restricting Search Results by Language.
  • You might use a customized front end with a specific collection to improve searches and enhance results. For information about collections, refer to Using Collections with Front Ends and See Segmenting Data in the Search Index.
  • You might modify the appearance of search and results pages. For information about changing the appearance of a front end, refer to Customizing the User Interface.

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:
  • If users a finding what they're searching for
  • If groups of users are searching for the same information
  • If certain URLs are harder for users to find than others

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 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:

1217555170,172.18.75.121,,c,0,1,,Google+Search +Appliance,http://www.google.com/

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:

  1. On a search page, the user enters the search term enterprise and clicks the search button. The results page loads:
    ...,172.18.75.121,,load,,0,0,,enterprise
  2. The user does not find satisfactory results on the first results page and clicks Next:
    ...,172.18.75.121,,nav.next,0,0,,enterprise...
  3. On the second result page, the user clicks the third result and navigates to http://www.google.com/:
    ...,172.18.75.121,,c,1,3,,enterprise,http://www.google.com/

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

  1. On a search page, the user enters the search term corfu and clicks the search button. The results page loads:
    ...,174.22.35.109,,load,,0,0,,corfu
  2. On the second result page, the user clicks the third result and navigates to http://www.corfu.com/:
    ...,174.22.35.109,,c,0,10,,corfu,http://www.corfu.com/

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:

  1. Getting baseline measurements of percentage of satisfied queries and average click rank (see Getting Baseline Measurements).
  2. Analyzing user clicks to identify areas for improvement in a specific front end (see Analyzing User Clicks).
  3. Personalizing the search experience using front ends (see Personalizing the Search Experience Using Front Ends).
  4. Measuring the effectiveness of personalization (see Measuring the Effectiveness of Personalization).

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:

  1. Generating an advanced search report (see Generating an Advanced Search Report)
  2. Calculating the percentage of satisfied queries (see Calculating the Percentage of Satisfied Queries)
  3. Calculating the average click rank (see Calculating the Average Click Rank)

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:

total number of satisfied clicks / total number of queries x 100=percentage of satisfied clicks

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:

(click start x 10) + click rank=absolute click rank

where click start is the page of the click

The formula for calculating average click rank is:

total of absolute click ranks/number of clicks=average click rank

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:

  • Rank of selected result
  • Page of selected result
  • URLs that are popular
  • IP addresses of the most frequent users of the system

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:

  • The search term is “new movies”
  • The URL is http://mediacompany.com/DVD/recentreleases
  • The title is “New DVD releases”

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:

  1. http://stock.com
  2. http://bond.com
  3. http://stock-bond.com

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

  1. http://stock.com
  2. http://bond.com
  3. http://bond-stock.com

Back to top

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:

  • Select KeyMatch types
  • Add KeyMatches individually
  • View KeyMatches
  • Edit KeyMatches
  • Search for KeyMatches
  • Delete KeyMatches
  • Import KeyMatches from a URL or file
  • Export KeyMatches

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:

  • Check results for top queries by running a report on searches that returned results using the Reports > Search Reports page in the Admin Console. Examine each query. If the best result for a query is not the first result, you might create a KeyMatch.
  • Check missed query terms by creating a report of unsuccessful search queries, as described in Analyzing Searches that Do Not Return Results. If several users are searching on missed query terms, you might create KeyMatches for the missed query terms.

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:

  • Label text (KeyMatch )
  • Label color
  • Background color

For example, you might make the following changes:

  • Reword the label from KeyMatch to Recommended Links
  • Change the KeyMatch text color from blue (#2255aa) to violet (#6600cc)
  • Change the KeyMatch background color from pale violet (#e8e8ff) to aqua (#ccffff)

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:

  • The search term is “Valise”
  • The related query is “Malta”

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

  • View related queries
  • Edit related queries
  • Search for related queries
  • Delete related queries
  • Import related queries from a URL or a file
  • Export related queries

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:

  • Label text (You could also try )
  • Label color

For example, you might make the following changes:

  • Reword the label from You could also try to Search again using this term?
  • Change the label color from red (#CC0000) to orange (#FF6600)

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:

  1. Choose Search > Search Features > Front Ends.

    The Front Ends page appears.

  2. Select a front end from the Current Front Ends list and click Edit.

    The Output Format page appears.

  3. In the Page Layout Helper box, select the Search Results section.

    The section expands.

  4. To enable dynamic result clusters, click Dynamic result clusters. A checkmark appears.

    Notice that dynamic result clusters appear in the preview.

    To disable dynamic result clusters, click Dynamic result clusters. The checkmark disappears.

  5. To change where cluster topics appear on the page, click Top or Side.
  6. Click Save.

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:

  1. Choose Search > Search Features > Front Ends.

    The Front Ends page appears.

  2. Select a front end from the Current Front Ends list and click Edit.

    The Output Format page appears.

  3. In the XSLT Stylesheet Editor, scroll to the dynamic result cluster options in the Other Variables section. The following code shows the dynamic result cluster options.
    <!-- *** dynamic result cluster options *** -->
    <xsl:variable name="show_res_clusters">0</xsl:variable>
    <xsl:variable name="res_cluster_position">right</xsl:variable>
  4. Enable or disable dynamic result clusters:
    • To enable dynamic result clusters, change the show_res_clusters value from 0 (zero) to 1 (one).
    • To disable dynamic result clusters, change the show_res_clusters value from 1 (one) to 0 (zero).
  5. To change where the cluster topics appear on the page, from the right side (default) to the top of the page, change the res_cluster_position value from right to top.
  6. Click Save.

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:

  • Attributes based on META tags found in the HTML of the documents in the search index
  • Attributes based on metadata from databases, connectors, or feeds
  • Attributes based on entities discovered by entity recognition

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:

  1. Enabling Dynamic Navigation.
  2. Creating a Configuration and Adding Attributes.
  3. Showing Dynamic Navigation in a Front End.

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.

Back to top

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 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:

  • Real-time authorization on the content server is fast.
  • Only 3-5% of the documents in the corpus need real-time checks.
  • The rest of the documents in the corpus use ACLs for authorization.

Enabling Dynamic Navigation

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

  1. Choose Search > Search Features > Dynamic Navigation.
  2. Click Enable.

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:

  1. Click Search > Search Features > Dynamic Navigation.
  2. Under Existing Configurations, click Add.
  3. In the Name box, type a name for the new configuration.
  4. Under Attributes, click Add.
  5. In the Display Label box, type the label for the attribute.
  6. In the Attribute Name box, type the name of the attribute.
  7. From the Type pull-down menu, select the attribute type.
  8. If the type is INTEGER, FLOAT, CURRENCY, or DATE, click Range Attribute and Relative to Current Date, if appropriate. See Configuring Dynamic Date Ranges.
  9. If the type is STRING, click Case-Insensitive Attribute, if appropriate.

    If the attribute is a Range Attribute, then provide the range values. No sorting options are available for range attributes. The values appear in the order entered.

    If the attribute is not a Range Attribute, then select the sorting options for the attribute. You can select to sort the attribute values by either counts or by values themselves and in ascending or descending order.

  10. Click OK.
  11. To add more attributes in this configuration, repeat steps 4 to 10.
  12. Under Front Ends, apply the configuration to one or more front ends by selecting front end names from the Available Front Ends box. Selecting them moves them to the Added Front Ends box. To remove the added front ends, select them in the Added Front Ends box and they will move back to the Available Front Ends box. The front ends added to one configuration are not available in other configurations.
  13. Optionally, to use secure dynamic navigation, click Enable dynamic navigation for secure search under More Options and select one of the following authorization modes:
  14. To create the configuration, click Create.

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 Search > Search Features > Dynamic Navigation in the Admin Console.

Configuring Dynamic Date Ranges

You can configure predefined dynamic date ranges. These ranges are based on the current date, for example, this week or past month, or a manual date range with a beginning and ending number of days. Does not support dates older than 1900-01-01.

  1. Follow steps 1 to 6 in Creating a Configuration and Adding Attributes.
  2. From the Type pull-down menu, select DATE.
  3. Click Range Attribute.
  4. Click Relative to Current Date.
  5. In the Dynamic range name box, type a name for the new configuration.
  6. From the Predefined Period pull-down menu, select the time period.
  7. If you select Manual, enter the range in days.

    To create a manual date range, specify a beginning and ending number of days, for example:

    • [-1, 0] includes yesterday (-1) and today (0).
    • [0, 10] includes today (0) and up to 10 days in the future.
    • [-2, 5] includes dates from 2 days ago until 5 days in the future.
  8. Click OK.
  9. To remove a configuration, highlight the name in the list and click Remove.

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:

  1. Click Search > Search Features > Front Ends and click Edit for a particular front end.
  2. In the Page Layout Helper box on the Output Format tab, select the Search Results section.
  3. Click Show Dynamic Navigation.
  4. Click Save.

Configuring Query Expansion for Dynamic Navigation

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

To configure query expansion for dynamic navigation:

  1. Click Search > Search Features > Query Settings.
  2. Under Add Query Expansion File, click Synonyms.
  3. For Language, select either all or the particular desired language.
  4. Specify a name to identify the file.
  5. Click Choose File and browse to a synonyms file containing synonyms for dynamic navigation attributes.
  6. Click Upload.
  7. In the list next to the file name, click Enable for MetaTag Names and MetaTag Values.
  8. Click Apply Settings.
  9. Click Search > Search Features > Front Ends.
  10. Click the Edit link next to the front end for which dynamic navigation has been applied and which needs attributes names synonyms.
  11. Select the Filters tab.
  12. For Query Expansion Policy for Meta Tags , select Names only or Names and values from the pull-down menu.
  13. Click Save.

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

Matching metadata names to synonyms is not case-sensitive. For example, if you define a synonyms file to include AUTHOR, CREATOR, and PUBLISHER, and set up dynamic navigation to display these attributes under the Author label, the counts will include all documents that contain any of these synonyms, regardless of the case.

Grouping Multiple Metadata under a Single Dynamic Navigation Attribute

The search appliance does not consider case when matching synonyms to metadata names. This enables you to group multiple metadata attributes under the same display label in search results.

For example, suppose you have three documents with different metadata:

  • Doc1.docx with metadata:
    <meta name=”Author” value="John P">
  • Doc2.pptx with metadata:
    <meta name=”last saved by” value=”Mark D”>
  • Doc3.pdf with metadata:
    <meta name=”Editor” value=”Mark D”>

Here is how the dynamic navigation configuration looks if you add these three metatags separately:

Here is how the search results would look:

Although these metatags represent the same information, which is the person who edited the file, we cannot filter across all 3 metadata simultaneously. For example, if you filtered by Mark D for “last saved by” meta, you would not get doc3 which was also edited by Mark D.

To group multiple metadata in dynamic navigation:

  1. Create a synonyms file with the following format: {Author, Editor, last saved by}.
  2. Go to Search > Search Features > Query Settings in Admin Console.
  3. Upload this file as a Synonyms file for All Languages.
  4. Enable the MetaTag Names column for the uploaded synonyms file, and click Apply Settings.
  5. Go to Search > Search Features > Front Ends > Filters.
  6. Set Query Expansion Policy for Meta Tags to Names Only or Names and Values. This enables the metadata synonyms feature for the front end.
  7. Delete all metatags except “Author” (Search > Search Features > Dynamic Navigation).

Wait approximately 15 minutes for the changes to take effect, and repeat the search:

When you filter by “Mark D” you will get two documents in search results.

This feature supports synonyms for metatag names only.

Note: By default, metatag names are case-sensitive. If you want metatag names to be case-insensitive:

  1. Go to Search > Search Features > Query Settings in Admin Console.
  2. Click the Enable case insensitive synonym grouping for dynamic navigation attribute names box.
  3. Click Save.

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:

  1. Configuring data sources for expert search
  2. Enabling and configuring expert search

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:

  1. Click Search > Search Features > Expert Search.
  2. On the Configure User Interface tab, click Configure on the line corresponding to the front end where you want to set up expert search.
  3. Under Selected Front End, click Save.
  4. Perform the following tasks:
    • Configuring a collection containing expert data
    • Selecting meta tags for the configuration
    • Configuring expert layout

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 Deprecated

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:

  • Images--Such as photos of members of your organization
  • Text--Such as a member's name, job title, manager, office location, and phone number
  • Links--Both images and text can be linked to web pages

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:

  1. Click Search > Search Features > Expert Search and select the People Search tab.
  2. Select a collection for people search from the Source Collection pull-down menu.
  3. To change the number of profiles that appear in the people search sidebar, enter a number in the Maximum Results box.
  4. To change the title of the people search results sidebar element, enter text in the Title box.
  5. To change the size of the people search sidebar element, enter the number of pixels in the Sidebar Height box.
  6. To specify a URL for profile images, enter it in the Image Source URL box.
  7. To make the profile image a link, enter a URL in the Image Link URL box.
  8. To change the scale of the profile image, enter the number of pixels in the Image Height and Image Width boxes.
  9. To change the sort order of the people search results, enter one or more attribute substitution patterns in the Sort Fields box.
  10. Specify a row of information in each people search profile:
    1. To specify a label for the display value, enter a text string in the Label box. To specify formatting of the label, enter HTML and/or XSL tags.
    2. To specify the content of a people search results row, enter one or more attribute substitution patterns in the Display Value box. To specify formatting of the attribute value, enter HTML and/or XSL tags.
    3. To make the display value a link, enter a URL in the Link URL box.
  11. To specify another row, go to step 7.

    You can specify a maximum of 16 rows.

  12. Click Save.

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:

  1. Click Search > Search Features > Front Ends and click Edit for a particular front end.
  2. In the Page Layout Helper box on the Output Format tab, select the Search Results section.
  3. Under Sidebar Elements, click People Search results.
  4. Click Save.

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:

  • Duplicate Snippet Filter--If multiple documents contain identical titles as well as the same information in their snippets in response to a query, only the most relevant document of that set is displayed in the results.
  • Duplicate Directory Filter--If there are many results in a single web directory, then only the two most relevant results for that directory are displayed. The previous example of host crowding illustrates this type of filtering.

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).

See Restricting Search Results by Domain Name

Language

This type of filter restricts searches to either all languages or a selected set of languages.

See 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.

See Restricting Search Results by File Type

Meta tag

This type of filter restricts searches by values and value types in meta tags.

See 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:

  • www.mediacompany.com.au
  • news.mediacompany.com.au
  • ops.mediacompany.com.au

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:

www.mediacompany.com.au/marketing

news.mediacompany.com.au/marketing

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:

  1. Click Search > Search Features > Front Ends > Filters.
  2. In the Query Expansion Policy for Meta Tags text box, select one of the following values:
    • None: Disables query expansion for meta tags in the front end.
    • Names only: Enables query expansion for names only.
    • Values only: Enables query expansion for values only.
    • Names and values: Enables query expansion for names and values.
  3. Click Save.

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

  1. In the Query Expansion Policy for Meta Tags text box, select None.
  2. Click Save.

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:
  • Built-in query expansion files, which you cannot download or edit
  • Preconfigured local query expansion files, which you can download and edit

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:

  1. Working with Query Expansion Files
  2. Setting the Query Expansion Policy for a Front End

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 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:

  • Google_Arabic_stems
  • Google_Czech_stems
  • Google_Dutch_stems
  • Google_English_stems
  • Google_French_stems
  • Google_German_stems
  • Google_Italian_stems
  • Google_Polish_stems
  • Google_Portuguese_stems
  • Google_Russian_stems
  • Google_Slovak_stems
  • Google_Spanish_stems
  • Google_Swedish_stems

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:

  • Download a preconfigured local file to edit it
  • Upload a modified file
  • Enable or disable a preconfigured local file

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:

  • Configure synonyms that match obsolete catalog numbers with their replacement catalog numbers. A user who searches for an obsolete catalog number would get results for both the obsolete catalog number and the new catalog number.
  • Configure synonyms that expand catalog abbreviations to full names. For example, a user who searches for “L. Bunuel” would get results for both the catalog abbreviation and Luis Bunuel.
  • Configure synonyms that expand generic categories to product names. For example, a user who searches for “documentary” would get results for both documentary and Best Documentary Series.

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:

  1. Create a text (.txt) file.
  2. If the file will contain accented characters and you have not already checked your editor's ability to save a file with UTF-8 encoding, do so now. As an example, if you are using Notepad, do this:
    • From the File menu, choose Save As.
    • Check that the Save options include Encoding, as well as Name and File Type.
    • Pull down the Encoding menu and choose UTF-8.
  3. Edit the file as follows:
    • Put one directive on each line, using the formats described under Entry format 1 and Entry format 2, below.
    • Use only alphanumeric characters and spaces, substituting spaces for hyphens. For example, instead of entering “pro- democracy,” enter “pro democracy.” The results will include the hyphenated version of the term. Each term can consist of multiple words separated by spaces; the maximum number of words for each term is 4.
    • Specify any number of synonyms for a particular term. There is no limit to the number of expansions in a query.
    • Use the pound sign (#) to start a comment line.
  4. Save the file. If the file has accented characters, save it with UTF-8 encoding.

Entry format 1: term1 operator term2

In this format:

  • term1 consists of one word or multiple words that are separated by single spaces.
  • term2 consists of one word or multiple words that are separated by single spaces. operator is one of the following:
    • = Specifies that the expansion is bi-directional. The appliance expands a search query for term1 or term2 by adding the other term.
    • > Causes the appliance to add term2 then a search query contains term1.

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:

  • The curly brackets are required.
  • Each term in the list will be used to expand queries for each other term.
  • Up to 32 terms are permitted.
  • Terms can contain space characters but they cannot contain commas.
  • A minimum of two terms is required.

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:

  1. Create a text (.txt) file.
  2. If the file will contain accented characters and you have not already checked your editor's ability to save a file with UTF-8 encoding, do so now. As an example, if you are using Notepad, do this:
    • From the File menu, choose Save As.
    • Check that the Save options include Encoding, as well as Name and File Type.
    • Pull down the Encoding menu and choose UTF-8.
  3. Edit the file as follows:
    • Put one word on each line.
    • Blacklists should use only alphanumeric characters. Spaces are not allowed.
    • Use the pound sign (#) to start a comment line.
  4. Save the file. If the file has accented characters, save it with UTF-8 encoding.

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:

  1. Create a text (.txt) file.
  2. If the file will contain accented characters and you have not already checked your editor's ability to save a file with UTF-8 encoding, do so now. As an example, if you are using Notepad, do this:
    • From the File menu, choose Save As.
    • Check that the Save options include Encoding, as well as Name and File Type.
    • Pull down the Encoding menu and choose UTF-8.
  3. Edit the file as follows:
    • Put one word on each line. Blank lines are ignored.
    • Use only alphanumeric characters. Spaces are not allowed.
    • Use the pound sign (#) to start a comment line.
  4. Save the file. If the file has accented characters, save it with UTF-8 encoding.

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:

  • Creating a language filter in a front end by using the Filters tab of the Search > Search Features > Front Ends page
  • Adding the lr=lang_<xyz> (language restrict) query parameter to the search request

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

Special characters in query expansion files

The following characters are not allowed in query expansion, blacklist, or stopwords files:

!"#$%()*,-/.:;<?@[\]^'{|}~

In release 7.6.50 and later, the plus (+) character is allowed, at the beginning, middle, or end of a word. For example:

Google+ can be expanded to include "Google Plus"
+Size can be expanded to include "plus size"
yellow+blue can be expanded to include "green"

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:

  1. Downloading and installing the language bundle
  2. Activating the language bundle

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:

  • Contextual--alternative terms for the search term, for example, where the search term “latest apple” is expanded to include “apples,” “fruit,” and “ipod.”
  • Non-contextual--replacement of the search term, for example, where the search term “apple” is expanded to include “apples.”

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:

  • The Admin Console Test Center is unable to display the “cached version” of the URLs returned there.
  • Any Iframe-based application used by the customer to show results will, most likely, stop working if it's accessed by any of the following browsers:
    • Chrome 4.1.249.1042 +
    • Firefox 3.6.9 + (or earlier with NoScript)
    • Internet Explorer (IE) E8 and IE9
    • Opera 10.50 +
    • Safari 4 +
    • Others based on those engines (WebKit, Trident, Gecko)

By default, click-jacking defense is enabled.

To enable/disable click-jacking defense:

  1. Click Search > Search Features > Query Settings.
  2. Under Click-Jacking Defense Settings, click the Enable Click-Jacking Defense checkbox.
  3. Click Save.

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:

  • Internal--Provides real-time access to data from a collection on the search appliance
  • External--Provides real-time access to data from an external source, such as an application or database

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:
  • Reflects the probable relevance of the document content
  • Determines the order in which results appear on the search results page

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:

  • Source biasing--enables you to affect scores of documents that belong to a specified collection, match certain URL patterns., or are fed from a data source. See Using Source Biasing.
  • Date biasing--enables you to affect scores of documents by date. See See Using Date Biasing.
  • Metadata and entity biasing--enables you to affect scores of documents based on metadata or entities associated with documents. See See Using Metadata and Entity Biasing.

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:

  1. Create a result biasing policy using the Search > Search Features > Result Biasing page in the Admin Console.
  2. Configure source biasing, date biasing, or metadata and entity biasing for the policy using the Search > Search Features > Result Biasing > edit page in the Admin Console. A menu-driven interface allows weak or strong increases or decreases, and requires no complex coding or scripting. You can use 11 settings to adjust result biasing from least influence to most influence.
  3. Enable the result biasing policy by selecting it for use with a front end using the Search > Search Features > Front Ends > Filters page in the Admin Console.

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.

  • Microsoft Word documents are stored on www.mediacompany.com/drafts
  • PDF documents are stored on www.mediacompany.com/publications

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:

  • Boost www.mediacompany.com/publications by setting a strong increase
  • Weaken www.mediacompany.com/drafts by setting a weak decrease

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:

  • The last modified date of the document
  • A date in the URL
  • A date in the document title

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:

  1. Configure an authentication mechanism for the search appliance to use to authenticate the user. If the configured authentication mechanism does not provide the user’s email address, then the user can set the email address after logging into the My Alerts page.

    For information about authentication mechanisms, see "Authentication," in "Managing Search for Controlled-Access Content."

  2. Specify rules for document dates by using the Index > Document Dates page or ensure that the rules are working.

    To verify that document dates rules are working, perform a search and ensure that dates are associated with each result.

  3. Enable alerts for the search appliance (see Enabling Alerts).
  4. Show the My Alerts link for a specific front end (see See Showing the My Alerts Link).

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:

  1. Choose Index > Alerts.
  2. Click Enable.

To disable alerts for a search appliance:

  1. Choose Index > Alerts.
  2. Click Disable.

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:

  1. Choose Search > Search Features > Front Ends.
  2. Select a front end from the Current Front Ends list and click Edit.
  3. In the Page Layout Helper box, select the Global Attributes section.
  4. To show the My Alerts link, select Show Alerts Link.

    To hide the My Alerts link, deselect Show Alerts Link.

  5. Click Save.

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:

  1. Choose Search > Search Features > Front Ends.
  2. Select a front end from the Current Front Ends list and click Edit.
  3. In the XSLT Stylesheet Editor, scroll to the alerts2 options in the Other Variables section. The following code shows the alerts2 options.
<!-- *** alerts2 options *** -->
<xsl:variable name="show_alerts2">0</xsl:variable>
  1. Show or hide the My Alerts link:
    • To show the link, change the show_alerts2 value from 0 (zero) to 1 (one).
    • To hide the link, change theshow_alerts2 value from 1 (one) to 0 (zero).
  2. Click Save.

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 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:

  • A name for the configuration.
  • A description of the configuration.
  • Whether user results are moderated, that is, if they require administrator approval before appearing in search results, and which front ends use the configuration.
  • The front ends to associated with the configuration

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:

  1. Choose Search > Secure Search > Access Control.
  2. Click the check box for Require authentication for User Results.
  3. Click Save.

To disable authentication for user results:

  1. Choose Search > Secure Search > Access Control.
  2. Clear the check box for Require authentication for User Results.
  3. Click Save.

How Users Can Add Results

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

  1. Type the keyword for the user result in the search box and click Search. For example, the keyword is "vacation."
  2. On the search results page, click the + icon.
  3. Type a title for the result. For example, the title might be "New Vacation Policies!"
  4. Type the URL of the document.
  5. Type a user name.
  6. Click Save.

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.

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:

  1. Choose Search > Search Features > Front Ends.
  2. Create a new front end or select an existing front end from the Current Front Ends list and click Edit.
  3. Under Page Layout Helper, select the Search Box section.
  4. Check the Enable auto- completion in search box check box.
  5. Click Save.

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:

  1. Uncheck the Enable auto-completion in search box check box.
  2. Click Save.
  3. Recheck the Enable auto-completion in search box check box.
  4. Click Save.

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:

  • Collections--All collections or just a selected collection
  • Front ends--All front ends or just a selected front end

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

  • xml--Provides a structured inventory of query suggestions
  • txt--Provides an unstructured inventory of query suggestions, with one suggestion per line

To export query suggestions:

  1. Click Search > Search Features > Suggestions.
  2. Select a collection from the menu or accept All Collections.
  3. Select a front end from the menu or accept All Front Ends.
  4. Select a file format from the menu.
  5. Click Export.
  6. Open or save the file.

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:

  • Exporting the suggestions blacklist.
  • Adding, editing, or deleting entries.
  • Importing the edited suggestions blacklist to the search appliance.

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

  1. Click Export.
  2. Open or save the file.

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

  1. Enter the filename of a suggestions blacklist file or click Choose File and navigate to the correct file.
  2. Click Import.

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:

  • Microsoft Word (doc, docx)
  • Microsoft PowerPoint (ppt)
  • Adobe Portable Document Format (pdf)

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:

  1. Enabling the document preview module by using the Search > Search Features > Document Preview Module page.
  2. Showing document previews in a front end by using the Page Layout Helper on the Output Format tab of the Search > Search Features > Front Ends page.

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:

  • *--Matches zero or more characters
  • ?--Matches exactly 1 character

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:

  • A sequence to at least 2 characters at the start of a word, for example: go*
  • A sequence to at least 2 characters at the end of a word,, for example: *le
  • A sequence of at least 3 characters anywhere in the word, for example: *ear*

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:

  1. In the Admin Console, click Search > Search Features > Front Ends > Filters.
  2. In the Maximum expansion per wildcard term text box enter a value from 0 (disable wildcard search) to 1000.
  3. Optionally, click the Consider words with * as wildcards by default checkbox
  4. Click Save.

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 Cloud 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:

  • Collection for the report
  • Name for the report
  • Time frame for the report (optional)

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:

  1. Choose Reports > Search Reports.
  2. From the Show Search Reports for Collection drop-down menu, select the collection whose search queries you want to include.
  3. Under Define Search Report, type a name for the report.

    Give the report a name of up to 20 alphanumeric characters, hyphens, and underscores. The name cannot start with a hyphen.

  4. Under Report type, click Searches that did not return results.
  5. Under Report timeframe, specify the period that you want the report to cover.
  6. If you run scripts that create diagnostic data by generating test queries, exclude the diagnostic search terms by entering them under Diagnostic terms to exclude.
  7. By default, the report shows the top 100 keywords and queries. At Number of top queries and keywords to show, change the number if you prefer more results or fewer results.
  8. Click Generate Report.

    The report appears under List of search reports, with its status set to Generating. The page does not automatically update when the report is complete, so refresh the browser page to check the report's status.

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:

  • Using a whitelist of URLs. List all possible URLs at your company in the Start URLs section.
  • Using a blacklist of URLs. List unwanted URLs in the Do Not Follow Patterns section.

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:

  • “Engineering,” for technical users and other user who need to search for engineering documents
  • “Sales,” for sales staff to search for sales documents
  • “Marketing,” for marketing staff to search for marketing documents
  • “Corporate Policies,” for any staff to search for policy documents
  • “Europe Offices,” for users who are geographically located in the European offices

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 Cloud team. For information on this topic, refer to Exchanging Information on Google Groups.

Back to top

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:

  • Adding an email link to the search results page. For example, you might label the link “Email us if you can’t find what you’re seeking.”
  • Adding a button on the search results page. For example, you might label the button “I didn't find what I was looking for.” Logging the percentage of queries that result in a click of this button provide an easy way for you to see whether you are improving the search experience.

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:

  • Keep it brief.
  • Don't make the respondents fill out long essay questions.
  • Keep questions as quantitative as possible so results are easily aggregated and compared to later survey results.
  • Get enough participants to make the results meaningful and statistically significant.

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

  1. How often do you find what you’re looking for?
    • 100% of the time
    • 80% of the time
    • 50% of the time
    • 20% of the time
    • Never
  2. How often does your result show up in the top 10 (first page)?
    • 100% of the time
    • 80% of the time
    • 50% of the time
    • 20% of the time
    • Never
  3. How often does your result show up as the first result?
    • 100% of the time
    • 80% of the time
    • 50% of the time
    • 20% of the time
    • Never
  4. How often do you click on the shaded key matches at the very top of the results?
    • Whenever I see one
    • Sometimes
    • Never
  5. How is the query response time?
    • Excellent
    • Sufficient
    • Unacceptable
  6. Is the query result description (snippet) useful?
    • Definitely
    • Somewhat
    • No
  7. How satisfied are you with your overall search experience?
    • Very satisfied
    • Somewhat satisfied
    • Not satisfied
  8. What would you like to see added?

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 Cloud Support organization has advised you not to upgrade, you should always download the latest software release. If you are a current Google Cloud customer, you can:

Back to top

Was this article helpful?
How can we improve it?