Google Search Appliance software version 6.0
Posted June 2009
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.
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.
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 |
| Divide the search index into meaningful partitions | Collections | Segmenting Data in the Search Index |
| Allow users to choose results by topic | Dynamic result clusters | Using Dynamic Result Clusters to Narrow Searches |
| 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 Enterprise and Google Groups | Exchanging Information on Google Groups |
| Update to the most recent software version | Google Enterprise Support site | Updating Your Search Appliance |
| Eliminate duplicate search results and provide the most relevant set of diverse results | Host Crowding | Experimenting with Host Crowding Options |
| Present recommended links above search results | KeyMatches | Using KeyMatches to Guide Users to URLs |
| Enable query expansion and spelling suggestions for a set of languages | Language bundles | Changing Languages for Query Expansion and Spelling Suggestions |
| Add structured, real-time application data to search results | OneBox modules | Using OneBox Modules to Integrate Structured Results |
| Create a user interface that focuses on your users | Page Layout Helper or XSLT Stylesheet Editor | Customizing the User Interface |
| 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 Results Ranking |
| Identify problematic query topics for related queries, KeyMatches, and query expansion synonyms | Search Report | Analyzing Searches that Do Not Return Results |
| Obtain user responses about the search experience | Surveys | Conducting a User Satisfaction Survey |
| Enable users to add search results for certain keywords in a specific front end | User-Added Results | Providing User-Added Results |
| Allow users to give you feedback | User Interface | Adding a Feedback Mechanism for Users |
| Optimize the response time of results | Various features | Optimizing the Speed of Results |
| Remove obsolete or non-essential content from the search index | Whitelist URLs or Blacklist URLs | Keeping the Search Index Clean |
The Google Search Appliance enables you to personalize the search experience. Rather than providing one centralized search experience for everyone, you can provide different search experiences for different groups of users. Each personalized search experience is based on the interests, roles, departments, locations, or languages of the user group.
For example, suppose your Google Search Appliance provides search for internal users from different organizations. Users often search for "acme widgets," but they are not all searching for the same results. More typically, when searching for acme widgets:
With a centralized search experience, some users may find what they are looking for at the top of the results listings while other users might have to view several results before finding what they are looking for. With a personalized search experience:
Users do not need to take any action to have a personalized search experience. The search appliance automatically presents a personalized search experience based on changes that you, as the system administrator, have implemented using search appliance features, including front ends, KeyMatches, and source biasing.
The first step to personalizing the search experience is gathering information about the search experience as it is currently deployed on the Google Search Appliance. After gathering this information, you can analyze it and decide:
In this document, descriptions of features that you can use to personalize the search experience are marked with the following personalization icon. 
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.
For one Google Search Appliance, you can create multiple front ends, each with its own customized settings. For example:
For more information about front ends, refer to Managing the Search Experience.
Before you can effectively personalize the search experience, you need to have knowledge about your end users, such as their roles, functional groups, locations, what they are searching for, and whether they are finding it or not. The Google Search Appliance enables you to gather information about user clicks. From this information, you can gain knowledge about end users and their interactions with search results. Information about user clicks can tell you:
By analyzing user clicks, you can identify ways to personalize and improve the search experience. For example, suppose information about user clicks shows that a users in range of IP addresses are all searching for information about project Malta. None of the users are finding a satisfactory URL at the top of the search results. Some of the users are finding a satisfactory URL on page 3 of the results. However, many users are abandoning the search after viewing page 2 of the results.
The range of IP addresses tells you that the users who are searching for the results are all Engineers in the U.S. who are working on project Malta. You might create a front end for this group of users. For information about this task, refer to Creating a Front End.
For this front end, you might promote project Malta URLs to the top of the search results using KeyMatches. Another alternative for promoting these URLs is to use 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.
The Google Search Appliance feature that enables you to gather information about user clicks is advanced search reporting. When advanced search reporting is enabled in the Admin Console, you can export 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.
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/.
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 |
| 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:
You can also add your own custom ctypes 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.)
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 Serving > OneBox Modules page in the Admin Console or an editor of your choice.
The examples in this section show you how to interpret detailed data about user clicks in an advanced search report. The examples omit some values from the each entry in the advanced search report, as indicated by the ellipses (...).
The following example shows a user searching on the term enterprise and finding a result on page 2 of the listings:
The following example shows a user searching on the term corfu clicking on the tenth result on the first page of listings:
The following steps outline an effective method for using advanced search reporting to personalize the search experience:
Because an advanced search report is a comma-separated values file, you can import it into a spreadsheet where you can sort the values. For example, you might sort an advanced search report by URL to find all user clicks that pertain to a specific URL.
Before you begin personalizing the search experience, identify the initial state of the search experience by taking baseline measurements. You can get baseline measurements by:
As you personalize the search experience, continue to generate advanced search reports that you can compare with baseline measurements.
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%.
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.
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 and front end especially for this group.
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.
After you personalize the search experience, generate another advanced search report and compare with it the 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.
Use the Google Search Appliance Admin Console to generate an advanced search report by:
You can enable or disable advanced search reporting for any front end. To enable advanced search reporting, use the Serving > Front Ends > Output Format page in the Admin Console. For complete information about using the Output Format page, refer to Help Center >Serving > Front Ends > Output Format - Page Layout Helper in the Admin Console.
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 Status and Reports > Search Log page in the Admin Console. For complete information about using the Search Log page, click Help Center >Status and Reports>Search Log in the Admin Console.
You can also use the Status and Reports > Search Reports page to view the following advanced search report data:
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:
There can be up to five KeyMatches for a single search term, and you can associate up to five URLs for each KeyMatch. If you associate more URLs, only five are available for use. The default maximum number of KeyMatches that are returned for a search is three, but you can increase this number by modifying the query parameter numgm=. For information about this query parameter, refer to Search Protocol Reference.
To work with KeyMatches, use the KeyMatch tab on the Serving > Front Ends > Output Format page in the Admin Console. For any front end, you can:
For complete information about using the KeyMatch tab, click Help Center >Serving > Front Ends > KeyMatch in the Admin Console.
To identify potential KeyMatches:
You might also get input for KeyMatches from people in your own organization who have domain expertise. For example, suppose you want to improve searches that pertain to sales issues. You might ask people in your sales offices to identify keywords that need KeyMatches.
You can change the appearance of KeyMatches in the user interface for a front end. Components that you can change include:
For example, you might make the following changes:
The following figure illustrates these changes.
To make changes to the appearance of KeyMatches, edit the Result Page Component section of the XSLT stylesheet. For information about editing the XSLT stylesheet, refer to Customizing the User Interface in the XSLT Stylesheet.
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 to add it as a local synonym.
Related queries are not set up by default. You can create a related query by associating a search term with a related query. In the previous example:
Search terms and related queries can be words or phrases.
Related queries are unidirectional only. When the end user's query matches the search term, the related query appears. However, when the end user's query matches the related query, the related query does not appear. Continuing the previous example, if a user searches for "Malta," the search term "Valise" does not appear.
When you add related queries to a new front end, they can appear immediately. If you add them to an existing front end, it can take 30 minutes or more for them to appear.
To work with related queries, use the Related Queries tab on the Serving > Front Ends > Output Format page in the Admin Console. For any front end, you can:
For complete information about using the Related Queries tab, click Help Center >Serving > Front Ends > Related Queries in the Admin Console.
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.
You can change the appearance of related queries in the user interface for a front end. Components that you can change include:
For example, you might make the following changes:
The following figure illustrates these changes.
Search again using this term?: Malta
To make changes to the appearance of related queries, edit the Result Page Component section of the XSLT stylesheet. For information about editing the XSLT stylesheet, refer to Customizing the User Interface in the XSLT Stylesheet.
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:
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.
To enable or disable dynamic result clusters using the Page Layout Helper:
The Front Ends page appears.
The Output Format page appears.
The section expands.
Notice that dynamic result clusters appear in the preview.
To disable dynamic result clusters, click Dynamic result clusters. The checkmark disappears.
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:
The Front Ends page appears.
The Output Format page appears.
<!-- *** dynamic result cluster options *** -->
<xsl:variable name="show_res_clusters">0</xsl:variable>
<xsl:variable name="res_cluster_position">right</xsl:variable>
You might notice that search results are sometimes indented, as shown in the following example.
The indenting indicates "host crowding," or presenting only the most relevant search results by eliminating duplicates. To eliminate duplicate search results, the search appliance uses the following automatic filters:
By default, automatic filters are enabled and host crowding significantly reduces the number of results returned.
In some situations, you can turn off host crowding by disabling one or more automatic filters to produce better relevancy. You might want to experiment with the settings for the Duplicate Directory filter and/or the Duplicate Snippet filters.
To disable the Duplicate Directory filter and/or the Duplicate Snippet filter, use the filter query parameter. For information about this topic, refer to Filtering in Search Protocol Reference.
As an administrator, you can create custom filters for a front end to ensure that the search appliance serves appropriate results to end users. Filters are especially useful when a search appliance has multiple front ends for multiple types of end users.
The following table lists the types of filters you can create, with references to sections that provide more details on each type of filter.
| Filter | Description | Refer to |
|---|---|---|
| Domain | This type of filter restricts searches to one or more domain names (not IP addresses). | Restricting Search Results by Domain Name |
| Language | This type of filter restricts searches to either all languages or a selected set of languages. | Restricting Search Results by Language |
| File type | This type of filter restrict searches to one or more content types or file types, such as HTML, PDF, and so on. | Restricting Search Results by File Type |
| Meta tag | This type of filter restricts searches by values and value types in meta tags. | Restricting Search Results by Meta Tag |
You can use multiple filters in a front end. For example, a front end that is used in a specific region could filter results by both domain and language.
To work with filters, use the Filters tab on the Serving > Front Ends > Output Format page in the Admin Console. For complete information about using the Filters tab, click Help Center >Serving > Front Ends > Filters in the Admin Console.
You can use a domain filter to restrict results by domain name.
Suppose you want to ensure that searches in various regions return only results with local information. For example, you want to restrict results on the Australian pages to show only products and special offers available there, so you create a front end for users in Australia.
The domain name for Australia is www.mediacompany.com.au. You might use this domain name to create a domain filter so that when end users in Australia perform a search, only results that match the domain name appear. All domains ending with the name are filtered. For example, the domain mediacompany.com.au returns search results in all of the following domains:
However, if the domain name is followed by a directory name, the domain name must be fully qualified when you enter it on the Filters tab. For example, mediacompany.com.au/marketing does not return any results under the domain name filter alone. The correct filter is www.mediacompany.com.au/marketing. If the directory marketing is in multiple domains, each filter must be specified individually on the Filters tab -- one per line, one for each domain, as shown in the following example:
www.mediacompany.com.au/marketing
news.mediacompany.com.au/marketing
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.
You can also create a filter with the Filters tab to display results for pages in any language.
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 Help Center > 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.
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.
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 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 |
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.
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 Help Center >Serving > 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 Crawl URLs with the Following Patterns section on the Crawl and Index > Crawl URLs page in the Admin Console. For more information about removing URLs from the index, refer to Administering Crawl for Web and File Share Content.
The Google Search Appliance can automatically expand search terms to include other terms. This expansion is based on synonyms, or alternative terms for the original search term, as well as inflection variants, and related terms. The search appliance includes the following types of query expansion files:
Additionally, you can add your own customized local query expansion files to a search appliance.
Whenever a term matches a built-in synonym, the query is expanded to include the synonym. For example, suppose a user searches with the term "video." Because this term matches a built-in synonym ("DVD"), the search is expanded to include the term DVD.
You can add your own set of meaningful terms to be added as synonyms. When query expansion is enabled, all synonyms on a search appliance apply to all front ends. To add terms for a specific front end, consider adding related queries instead.
There are two steps to adding synonyms to query expansion:
This section describes tasks for managing query expansion files for a Google Search Appliance, including:
To manage query expansion files, use the Serving > Query Expansion page in the Admin Console. For complete information about using the Query Expansion page, click Help Center >Serving > Query Expansion in the Admin Console.
By default, query expansion terms are available in seven supported languages: Dutch, English, French, German, Italian, Portuguese, and Spanish. 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.
For customers who are using the supported languages, the following preconfigured synonyms files are provided with the search appliance:
These files appear by default in the list of query expansion files on the Serving > Query Expansion page in the Admin Console. Each file contains a set of common words that can supplement standard terms. By default, Google_English_stems is enabled.
You can use a preconfigured local file as it is. Alternatively, you can:
To perform any of these tasks, go to the Serving > Query Expansion page.
You cannot delete preconfigured local files.
You can use customized local query expansion files to configure site-specific terminology. For example, you might:
A local synonyms file is a text file of three megabytes or less, containing case-insensitive entries.
Follow these steps to create a local synonyms file:
Entry format 1: term1 operator term2
In this format:
Examples:
ebu = education business unit tbu = telecomm business unit telecom business unit = telecomm business unit partner > indirect sales
Entry format 2: {term, term, ...}
In this format:
Examples:
|
{run, runs, running, ran}
{widgets, parts, items}
For information about uploading a synonyms file, click Help Center >Serving > Query Expansion in the Admin Console.
You can control query expansion by creating a blacklist. A blacklist is a set of words that are excluded from query expansion. A blacklist can be useful for eliminating unwanted search results that result from synonym matching and clarifying special words used in your environment.
For example, suppose mediacompany.com starts a new project with the code name "glue." You could add "glue" to the blacklist to ensure that user queries do not expand to include "adhesive."
A blacklist file is a text file of three megabytes or less, containing a simple case-insensitive list of single words, with one word on each line.
Follow these steps to create a blacklist file:
This is an example of a blacklist file:
#Blacklist file created July 2006
#Author: lana
glue
component
This file prevents queries for "glue" and "component" from being enhanced with synonyms.
For information about uploading a blacklist file, click Help Center >Serving > Query Expansion in the Admin Console.
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 #).
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 100 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 Serving > Front Ends > Filters tab.
To set the query expansion policy for a front end, use the Filters tab of the Serving > Front Ends page in the Admin console. For complete information about using the Filters tab, click Help Center >Serving > Front Ends > Filters in the Admin Console.
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 |
|
Installed on the Google Search Appliance by default |
| Scandinavia |
|
http://dl.google.com/enterprise/scandinavia-lang-pack-2.1-1. |
You can enable search appliance support for a language bundle by performing the following tasks:
You can install multiple language bundles on a search appliance, but only one language bundle can be active at any time. The currently active language bundle provides query expansion and spelling support for the languages in the bundle. By default, the built-in language bundle is active.
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 Serving > Langauge Bundles page in the Admin Console. For information about using this page, click Help Center >Serving > Language Bundles in the Admin Console.
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:
Several OneBox modules are free downloads from the Google Enterprise Developer forum. You can also develop OneBox modules with the use of simple APIs and a standard XML format. For information, technical specifications for developing OneBox for Enterprise extensions, and the full OneBox for Enterprise module gallery, visit http://code.google.com/enterprise/oneboxgallery.html.
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:
The Google Search Appliance ranks the documents that it finds in response to a user search query. For each document, the search appliance calculates a score that:
You can use result biasing to increase or decrease the scores of specified sources, or types of sources, in the search index. These local settings may affect the order of the search results. You can influence results ranking by using:
Result biasing is one way to affect the order of results. You might consider using other features to meet the following objectives:
To influence search appliance rankings, use a result biasing policy. A result biasing policy determines the source biasing, date biasing, and metadata biasing settings that are used with a front end. A default result biasing policy (default_policy) is built into the search appliance. You can use default_policy, or create one or more custom result biasing policies. A result biasing policy is specific to a front end, so it can be aimed at specific types of end users.
To work with result biasing:
If you are updating a search appliance with existing result biasing settings, your existing settings are added to default_policy. Also, any existing front ends that have result biasing turned on are automatically set to use default_policy after the update.
For complete information about using the Serving > Result Biasing page, the Serving > Result Biasing > Edit page and the Serving > Filters page, refer to the Help Center in the Admin Console.
Using source biasing, you can boost or weaken the relevancy score of a document that belongs to a specified collection or that matches certain URL patterns. Boosting a score usually moves a result up in the rankings. Weakening a score usually moves it down. The search appliance offers two controls over source biasing, as described in the following table.
| Control | Description |
|---|---|
| Influence | Specifies how much influence source biasing has in calculating scores for results rankings overall. The default influence is No influence. You can change this to one of ten settings in a range of More influence for a search appliance. |
| Strength | Specifies how much influence source biasing has in calculating scores for documents that match specific URL patterns. The default strength is Leave unchanged. You can change this to Strong, Medium, or Weak increase or Strong, Medium, or Weak decrease for each collection or specified URL pattern. |
For example, suppose most official content in your organization is drafted in Microsoft Word (.doc), but published in Portable Document Format (pdf). In some instances, both the .doc and .pdf versions of documents have the same content. However, each type of document is stored in a different location.
Both types of documents are crawled and appear in the search index. However, you want .pdf versions to be higher in the search results than .doc versions. You create a result biasing policy where you can influence the score of .pdf documents. For this result biasing policy, you can use source biasing to:
By adjusting the strength of individual URLs you influence the score that reflects the relevance of documents that match the URL patterns. After you select the result biasing policy for use with a front end, .pdf documents are more likely to appear closer to the top of results listings.
The effect of changing a document's score is not always predictable. The order of a search result among the other results is determined by many factors, including the scores of the other documents with which it is returned.
Using date biasing, 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 by human_resources 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.
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.
The document date that the Google Search Appliance evaluates for date biasing is specified on the Crawl and Index > Document Dates page. For example, the search appliance can use one of the following dates:
However, if a document is added to the index by a feed rather than by a crawl, the document might not have a useful associated date for use with date biasing.
Using metadata biasing, you can boost or weaken the relevancy score of a document based on metadata 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 biasing, as described in the following table.
| Control | Description |
|---|---|
| Influence | Specifies how much influence metadata 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 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">
You create a result biasing policy called human_resources and configure metadata 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 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.
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.
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 by using his LDAP user name and password.
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 documents about changes to personnel policies (secure results are not returned). The email contains a batch of result listings. Clicking any result listing in an alert email displays the relevant document.
To provide alerts for users, you must:
Alert emails use the sender of outgoing emails that is specified in the Email Notification area on the Administration > System Settings page during search appliance installation. If the sender of outgoing emails is not specified during installation, the default value of nobody@localhost is used. For information about specifying the value of sender of outgoing emails, refer to Configuring the Network Settings in Installing the Google Search Appliance on the public search appliance documentation page.
If alerts are not currently enabled for a search appliance, you can enable them using the Serving > Alerts page in the Admin Console. If alerts are enabled, you can disable them.
To enable alerts for a search appliance:
To disable alerts for a search appliance:
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.
To show the My Alerts link using the Page Layout Helper:
The Front Ends page appears.
The Output Format page appears.
The section expands.
To hide the My Alerts link, deselect Show Alerts Link.
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:
The Front Ends page appears.
The Output Format page appears.
<!-- *** alerts2 options *** -->
<xsl:variable name="show_alerts2">0</xsl:variable>
You can give users the capability to add search results for certain keywords in a specific front end. User-added results cause designated documents always to appear on the results pages for specified keyword searches performed in the 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 user-added result for the document.
A user can add a result by specifying:
When anyone searches on "vacation," the user-added result always appears on the results page. The result displays the title, linked to the specified URL, and the user's name, as shown in the following example.
You provide user-added results by performing the following tasks:
To create a OneBox module definition for user-added results:
After you create the OneBox module for user-added results, you can enable it for a new or existing front end.
The Front Ends page appears.
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. The user can execute a search by selecting one of the terms.
To provide query suggestions:
The Front Ends page appears.
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:
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, visit http://support.google.com/enterprise. |
| 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. |
Sometimes, user search queries fail to return available information. In these instances, you can use front end configuration features such as KeyMatch, related queries, and query expansion 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:
When you generate a report of unsuccessful search queries, you specify the following information:
For example, you might create a report of unsuccessful search queries called Operations Zero Results Report on the default_collection for the previous week.
To create a report of unsuccessful search queries:
Give the report a name of up to 20 alphanumeric characters, hyphens, and underscores. The name cannot start with a hyphen.
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.
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:
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 Crawl and Index > Crawl URLs page in the Admin Console.
Generally, there are two methods for setting up URLs for crawling your content:
To keep the search index clean, you can use both methods together or simply use a whitelist. Generally, using only a whitelist is more effective than using only a blacklist. The following sections describe the advantages and disadvantages of both approaches. For information about setting up URLs for crawling your content, refer to Preparing Data for a Crawl in Administering Crawl for Web and File Share Content.
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.
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.
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.
User searches can be more efficient when they are restricted to subsets of the entire search index. As an administrator, you can help users to search more efficiently by using collections. A collection is a segment of the complete search index that you define by specifying URL patterns to include.
Using collections, you can show different results to different users. For example, suppose you want to create different collections, such as:
To search a collection, a user can select a collection from a pull-down menu on the search box, as illustrated in the following figure.
For more information about this topic, refer to Adding a Menu to Search by Collection in Customizing the User Interface.
The maximum number of collections for a search appliance is 1500. 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 Crawl and Index > Collections page in the Admin Console. For information about using this page to create a collection, see Help Center > Crawl and Index > 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.
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 Search Protocol Reference.
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 Enterprise team. For information on this topic, refer to Exchanging Information on Google Groups.
The number of user searches tends to increase when users can provide feedback about the quality of results. User feedback is also an effective way to identify usability issues. When you solicit feedback, you let users know that their opinions about the search experience are important. As users see improvements based on their feedback, they search more.
Some easy ways you can enable users to give feedback might include:
Feedback that is sent with the user information is very useful. It enables you to contact users to get clarification and show that you are following up with them.
A survey can be an effective way of soliciting feedback from users about the search experience. A survey also enables you to establish a baseline of search quality metrics before beginning to implement best practices.
Some tips for creating a user satisfaction survey are:
The following example questions might help you develop your own survey questions.
Finally, an effective way to evaluate the quality of search results is by using side-by-side evaluations. You could use this type of evaluation to test the following types of changes:
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. 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.
There are usually many performance improvements, security enhancements, and/or features that are included in new Google Search Appliance software releases.
Unless Google Enterprise Support organization has advised you not to upgrade, you should always download the latest software release. If you are a current Enterprise customer, you can:
In some instances, you might want to use information from various sources to influence results rankings. For example, you might have collected a list of useful URLs or directories of URLs from server logs or reports that you want to raise in results rankings. Or you might have a list of outdated documents that you want to keep in the search index, but lower in results rankings.
You can apply this information to results rankings by using the ranking framework. The ranking framework enables you to:
The input to the ranking framework is a configuration file that contains URL prefixes and their rescoring weights. Input by file enables you to input batch customizations for just a few to millions of URLs.
Implement the ranking framework by performing the following tasks:
Implementing the ranking framework involves using the Google Data API to make HTTP POST requests to the search appliance. If you are unsure of how to make HTTP POST requests, you can use the WizTools RESTClient. It is available at http://code.google.com/p/rest-client/. The following examples use this client, but you can use whatever method you wish to use.
The Google Data API can also be used for deleting a rescoring configuration.
A rescoring configuration file contains a list of URLs and their associated rescoring strength. Strength is indicated by an integer from -3 (not important) to 3 (very important). The rescoring configuration file contains two columns:
URLs that match the prefixes listed in the file are raised or lowered in search results based on the integer value of the rescoring strength.
The following example shows a rescoring configuration file.
http://www.important.com/ 1
http://very.important.com/ 3
http://not.important.com/ -1
http://www.important.com/personal_stuff -3
Create a rescoring configuration file and put the file somewhere URL accessible.
Get authorization on the Google Search Appliance through Google Data API by sending an HTTP POST request to the following URL:
http://gsa:8000/accounts/ClientLogin?Email=username&Passwd=password
where gsa is the name of your Google Search Appliance
username and password are your administrator username and password for accessing the Google Search Appliance
The HTTP POST request returns a message, such as:
Authentication Success!
Auth=990716d6506a0cfd77dc84ca095526f9
The following figure shows the URL and response in the RESTClient tool.
Apply this authorization by adding the Key and Value to the Header of each request.
For example, in the following figure, the Key is authorization and the Value is Auth=990716d6506a0cfd77dc84ca095526f9.
After getting authorization on a Google Search Appliance, add a rescoring configuration file to the search appliance by submitting an HTTP POST request.
Ensure that the Body Content-type is application/atom+xml, as shown in the following figure.
Add a Body for the HTTP POST request. The following example shows a Body for an HTTP POST request submitted to http://gsa:8000/feeds/prefixScorer.
<?xml version='1.0' encoding='UTF-8'?>
<entry xmlns='http://www.w3.org/2005/Atom'
xmlns:gsa='http://schemas.google.com/gsa/2007'> <gsa:content name='prefixScorerConfigName'>test1</gsa:content>
<gsa:content name='rescoringPolicy'>policy1</gsa:content>
<gsa:content name='rescoringWeight'>0.2</gsa:content>
<gsa:content name='prefixScorerConfigUrl'>http://www.mycompany.com/ranking_framework/ranking.cfg</gsa:content>
<gsa:content name='prefixScorerTryPrefixes'/>
</entry>
The following table describes the gsa:content tags that you can include in the Body. Take note that some of the gsa:content tags are required while others are optional.
| gsa:content Tag | Decription | Required/Optional |
|---|---|---|
| prefixScorerConfigName | Unique name that should be associated with a single configuration file | required |
| rescoringPolicy | Name of associated scoring policy. each scoring policy can only be associated with a single configuration, but a single configuration may be associated with multiple scoring policies. | required |
| rescoringWeight | Fraction of the page's score that is affected by this rescoring. | required |
| prefixScorerConfigUrl | URL that points to the configuration file from | optional |
| prefixScorerTryPrefixes | This is actually a boolean tag. if it exists, we search through the prefixes of result URLs to find prefix matches. if it doesn't exist, we only search for exact URL matches. | optional |
| prefixScorerMapType | Values can be "fingerprint" or "sstable". Indicates what kind of weight map we want to use for storing prefix -> strength mappings. | optional |
The following figure shows the example HTTP POST request in the RESTClient tool.
After adding the new rescoring configuration, you need to activate it by using the Serving > Result Biasing > Edit page in the Google Search Appliance Admin Console.
After you click Save Settings, the new prefix rescoring configuration begins setup. This may take a little time, so search requests may not immediately be affected by the new rescoring configuration.
The result biasing policy that the new configuration is associated with should be explicitly named in your search query by using the entsp search parameter. This parameter controls the use of advanced relevance scoring. The a parameter indicates advanced scoring. For example, if the policy is named "sales," the search query would include &entsp=a__sales.
The following example shows the complete query URL.
http://entbr24/search?q=coral&client=default_frontend&output=xml_no_dtd&proxystylesheet=default_frontend&site=default_collection&entsp=a__sales
For more information about query URLs and the entsp search parameter, see Search Protocol Reference.
If you need to change a prefix rescoring configuration or if you no longer need to use it, you can delete it. You cannot change a prefix rescoring configuration directly. To change one, you must delete and replace it.
To delete a single rescoring configuration:
If you want to delete all of the rescoring configurations on a Google Search Appliance, send an HTTP DELETE request to http://gsa:8000/feeds/prefixScorer/deleteALL.