Tuesday, 15 January 2019

WCS Search Logic flow and customization




1    Introduction

1.1     Purpose of the document

          This documents purpose is to understand how Search results were displayed and to shoppers and hot to customize the search results for improving the product recommendation strategy as per the business requirements. This document contains all the information that expresses business goals and needs and the impact on the business solution(s), process(es), and organisation, within scope for a specific Change Request (CR).

2    Search Configuration in OTB

2.1     Search Flow

          In default OTB configuration, the search type will be set to '1000' which means when an shopper searches with a search term SOLR does a match using an match type 'ANY' and looks up for the search term within products, kits, bundles, category level SKUs and gathered.
Note : In Default WCS search setup configuration, the product level SKUs will be excluded from the search results.

2.2     Search Results Order

          In default OTB configuration, the gathered search results in 2.1 will be sorted based on the relevancy score configuration and displays the search results at storefront.

3    Search Customizations

3.1     Customizations Available in WCS 7

          For Future pack 6+, WC provides below search customizations.

3.1.1 Search Term Associations

          Search term associations suggest additional, different, or replacement products in search results. They can also link search terms to a selected landing page in the store. Search term associations are used as a product recommendation strategy to increase store sales when customers search for products, as the search submission is modified to increase or target search results.

3.1.2 Search Rules

          Search rules are used to influence the ordering and contents of search results that are displayed to shoppers. Search rules are typically used to promote specific catalog entries by displaying them on the first page of the search results, or to order catalog entries according to a specific attribute, such as price.

3.1.3 Business Features Using Search Customizations

          WC comes with a powerful and fully integrated search function. The search functions in WC provide an enriched customer experience and you can deliver powerful search-based catalog browsing flows by enabling WC Search.
          Also WC provides various search types that can be customized according to Business requirements. They are

S.No
Match Type
Search Type
Description
1
Any
0
Search Includes in products, kits, bundles and exclude product level SKUs and category level SKUs
2
Exact
1
Search Includes in products, kits, bundles and exclude product level SKUs and category level SKUs
3
All
2
Search Includes in products, kits, bundles and exclude product level SKUs and category level SKUs
4
None
3
Search Includes in products, kits, bundles and exclude product level SKUs and category level SKUs
5
Any
10
Search includes in products, kits, bundles, product level SKUs, category level SKUs
6
Exact
11
Search includes in products, kits, bundles, product level SKUs, category level SKUs
7
All
12
Search includes in products, kits, bundles, product level SKUs, category level SKUs
8
None
13
Search includes in products, kits, bundles, product level SKUs, category level SKUs
9
Any
100
Search includes in product level SKUs, category level SKUs and excludes products, kits, bundles
10
Exact
101
Search includes in product level SKUs, category level SKUs and excludes products, kits, bundles
11
All
102
Search includes in product level SKUs, category level SKUs and excludes products, kits, bundles
12
None
103
Search includes in product level SKUs, category level SKUs and excludes products, kits, bundles
13
Any (Default)
1000
Search includes in products, kits, bundles, category level SKUs and excludes product level SKUs
14
Exact
1001
Search includes in products, kits, bundles, category level SKUs and excludes product level SKUs
15
All
1002
Search includes in products, kits, bundles, category level SKUs and excludes product level SKUs
16
None
1003
Search includes in products, kits, bundles, category level SKUs and excludes product level SKUs
17
Any
1000
Search includes only category level SKUs and excludes products, kits, bundles, product level SKUs
18
None
1001
Search includes only category level SKUs and excludes products, kits, bundles, product level SKUs
19
All
1002
Search includes only category level SKUs and excludes products, kits, bundles, product level SKUs
20
None
1003
Search includes only category level SKUs and excludes products, kits, bundles, product level SKUs
          A key feature of Search is that sales personnel can create and manage search term associations, and search-based merchandising rules, from within the Management Center and Store view.
          With features such as Search term associations suggest additional, different, or replacement products in search results. They can also link search terms to a selected landing page in the store. Search term associations are used as a product recommendation strategy to increase store sales when customers search for products, as the search submission is modified to increase or target search and Search rules can modify search results and how they are displayed in the storefront.

4    Search Term Associations

4.1     Synonyms

          Synonyms increase the scope of search results by adding more search terms to search submissions.

4.2     Replacements

          Replacements modify potential search results by changing search terms from search submissions.

4.3     Implementation Procedure

4.3.1 Synonyms

          The below example describes how to customize/implement Synonyms.
Step 1: Open catalogs tool in Management Center
Step 2: From the explorer tree, select Search Term Associations.
Step 3: Click the Synonyms tab. The synonym list is displayed.
Step 4: Click New to create a synonyms row.
Step 5: Create synonyms for the 'sjampo' and 'shampoo' search terms, by creating synonyms with the following value


With this synonym enabled in the store, shoppers see search results for both the 'sjampo' and 'shampoo' search terms, whenever they search on either search term.
Step 6: Restart WC server to reflect the changes.

4.3.2 Replacements

          The below example describes how to customize/implement Replacements.
Step 1: Open catalogs tool in Management Center
Step 2: From the explorer tree, select Search Term Associations.
Step 3: Click the Replacements tab. The synonym list is displayed.
Step 4: Click New to create a Replacements row.
Step 5: Create Replacements for the search term 'shampoo' with a replace term 'sjampo' by providing a replacement type as mentioned below


With this Replacements enabled in the store, we can include 'sjampo' when shoppers search for 'shampoo' or we can promote search results of 'sjampo' instead of 'shampoo' search terms
Step 6: Restart WC server to reflect the changes.

5           Search Rules

          Search rules are typically used to promote specific catalog entries by displaying them on the first page of the search results, or to order catalog entries according to a specific attribute, such as price and using this we can modify search results and how they are displayed in the storefront.
          search rules are used to deliver customized search results and ordering. You can also define targets in search rules to specify which customers see your search rules. Creating search rules ensures that targeted search results are seen by the right customers.

5.1     What are search rules?

Search rules are a helpful search and marketing feature that allows you to influence the order of your search results on the storefront.  Search rules are created and set via Management Center. Have a look at the Search Rules document in the Knowledge Center, which explains in more detail on how you can work with them.
The important thing to keep in mind when working with Search Rules is that they are a component of both Search and Marketing. As such, the use of search rules relies on both the Commerce and Search servers to complete the request.
There are two parts to a search rule; the keyword and the action(s) to perform. When created in Management Center, the search rules are saved in marketing tables, such as:

  1. ·         DMELEMENT
  2. ·         DMACTIVITY
  3. ·         DMELEMENTNVP
  4. ·         EMSPOT

5.1.1 How do search rules work?

Now that a search rule has been setup, I have performed a search for coffee. Let's walk through what will happen. The first thing to keep in mind is that search rules require a certain expression provider to be enabled. The expression provider SolrRESTSearchBasedMerchandisingExpressionProvider must be included in the search profile for Commerce Search to look up search rules associated to our search terms. You can find this expression provider in your wc-search.xml. From the trace on the Search server, we can see the expression provider in question is being used.

[12/6/18 13:39:07:392 EST] 0000008c SolrRESTSearc 1 com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchExpressionProvider invoke(SearchCriteria) Search providers: com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchTypeExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchBasedMerchandisingExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchTermAssociationExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchByKeywordRelevancyExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchByCategoryExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchByManufacturerExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchByPriceExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchByFacetExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchByStorePathExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchByPublishedEntryOnlyExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchByCustomExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchFacetConditionExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchInventoryExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchProductEntitlementExpressionProvider com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchRelevancyByCategoryProvider

Continuing forward, we can see the expression provider being called:

[12/6/18 13:39:07:394 EST] 0000008c SolrRESTSearc 1 com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchExpressionProvider invoke(SearchCriteria) Calls into provider invoke() method of com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchBasedMerchandisingExpressionProvider

When a keyword search is carried out, this expression provider will check what search terms are associated to a search rule. If this list does not exist, then a REST request will be sent from the Search server to the Commerce server to create a list of all search terms that have a search rule associated with them. You can review the espot REST API doc on the Knowledge Center for more information about using this REST API. We can see this request occurring from the Commerce trace.log file:

[12/6/18 13:39:07:403 EST] 00000438 ServiceLogger >   REST <http://<hostname>/wcs/resources/store/715838084/espot> <user:-1002> <method:GET> <q=allSearchTerms>  ENTRY

This list of search terms that have search rules will then be cached so that we only have to check for this information once. Now that we have this data, if a match occurs, the Search server will send a REST request to the Commerce server asking for that search rule data, as seen here.

[12/6/18 13:39:07:454 EST] 00000438 ServiceLogger >   REST <http://<hostname>/wcs/resources/store/715838084/espot/coffee/type/search> <user:-1002> <method:GET> <_wcf.search.type=1000&DM_ReqCmd=AjaxCatalogSearchView&name=coffee&catalogId=3074457345616676719>  ENTRY

In turn, the Commerce server will respond by sending a REST response with the search rule data:

[12/6/18 13:39:07:619 EST] 00000438 JSONEntityPro 3 com.ibm.commerce.foundation.rest.providers.JSONEntityProvider writeTo(Map map, Class<?> objectClass, Type objectType, Annotation[] resourceAnnotations, MediaType responseMediaType, MultivaluedMap<String, Object> responseHttpHeaders, OutputStream responseOutputStream) outbound REST response: {"resourceId":"http:\/\/csx00840.canlab.ibm.com\/wcs\/resources\/lbs\/store\/715838084\/espot\/coffee\/type\/search?_wcf.search.type=1000&DM_ReqCmd=AjaxCatalogSearchView&name=coffee&catalogId=3074457345616676719","MarketingSpotData":[{"marketingSpotIdentifier":"715839384","previewReport":["SpotFound|715839384|715837984|SEARCH|coffee|true","ScheduledActivity|715838684|715838084|1| | |AromaStar_First","EvaluateActivitiesBegin","EvaluateActivity|715838684|715838084|1| | |AromaStar_First","TriggerCustomerSearches|true|SearchForExactlyOne|coffee","Action|orderSearchResultActionV7FEP6|715839286|715839286","EvaluateActivityEnd","EvaluateActivitiesEnd","ReturnRecommendation|SearchQuery|bq=mfName_ntk:\"AromaStar\"^100.0|0|","StaticMarketingSpotBehavior"],"eSpotName":"coffee","behavior":"0","nextTimeLimit":"-1","baseMarketingSpotActivityData":[{"baseMarketingSpotActivityName":"","baseMarketingSpotActivityID":"bq=mfName_ntk:\"AromaStar\"^100.0","baseMarketingSpotDataType":"SearchQuery"}]}],"resourceName":"espot"}

Now that Commerce Search has the search rule data, it can be used for the search query. This is showing the boost query used to ensure that the products with manufacturer name of AromaStar are boosted with a ranking factor of 100:

[12/6/18 13:39:07:626 EST] 0000008c SolrRESTSearc < com.ibm.commerce.foundation.server.services.rest.search.expression.solr.SolrRESTSearchBasedMerchandisingExpressionProvider runSearchActivities(String astrSearchTerm) RETURN bq=mfName_ntk:"AromaStar"^100.0

5.1.2 Using the final solr query for verification

The last step for confirming that the search rule is being used, the Final Solr Query should be looked at to confirm that the search query contains the search rule. For example, that we're boosting the relevancy score for AromaStar products:

[12/6/18 13:39:07:880 EST] 0000008c SolrRESTSearc 1 com.ibm.commerce.foundation.server.services.rest.search.processor.solr.SolrRESTSearchExpressionProcessor performSearch(SelectionCriteria) Final Solr query expression: debugQuery=true&fl=catentry_id,storeent_id,buyable,partNumber_ntk,name,shortDescription
.....
q=coffee&hl.fl=name&hl.fl=shortDescription&hl=true&hl.simple.pre=<strong><span class=font2>&hl.simple.post=</span></strong>&hl.requireFieldMatch=true&start=0&rows=12&timeAllowed=15000&facet=true&facet.field=mfName_ntk_cs&facet.field=parentCatgroup_id_search&f.mfName_ntk_cs.facet.limit=21&f.mfName_ntk_cs.facet.mincount=1&f.mfName_ntk_cs.facet.sort=count&f.parentCatgroup_id_search.facet.limit=21&f.parentCatgroup_id_search.facet.mincount=1&f.parentCatgroup_id_search.facet.prefix=3074457345616676719_&f.parentCatgroup_id_search.facet.sort=count&facet.query=price_USD:({* 100} 100)&facet.query=price_USD:({100 200} 200)&facet.query=price_USD:({200 300} 300)&facet.query=price_USD:({300 400} 400)&facet.query=price_USD:({400 500} 500)&facet.query=price_USD:({500 *})&f.price_USD.facet.limit=21&f.price_USD.facet.mincount=1&f.price_USD.facet.sort=count&defType=edismax&qf=name^10.0 defaultSearch^1.0 categoryname^100.0 shortDescription^5.0 partNumber_ntk^15.0 keyword^100.0&pf=name^10.0 defaultSearch^1.0 categoryname^100.0 shortDescription^5.0 partNumber_ntk^15.0 keyword^100.0&ps=100&bq=mfName_ntk:"AromaStar"^100.0&tie=0.1&wt=json&json.nl=map&q=coffee&fq=-(catenttype_id_ntk_cs:ItemBean AND parentCatentry_id:[* TO *])&fq=catalog_id:"3074457345616676719"&fq=storeent_id:("715838084" "715837934")&fq=published:1

5.2     Types Of Search Rules

          The below are the types of search rules available in WC.
1) Change Search Result Order
          Changes the position of certain results within the search results list. Catalog entries that meet certain criteria can be ranked higher or lower to promote specific catalog entries over others for a specific customer search.
2) Specify Top Search Results
          Elevates specific catalog entries to the top of the search results list.
3) Add or Replace Search Criteria
          Replaces search keywords submitted by the customer with alternative search keywords, or uses additional search criteria to narrow down search result.
          In Default OTB setup, Instead of Add or Replace rule the Search Term associations can be used and if you would like to use Add or Replace search instead of search term associations then the OTB search profile 'findProductsBySearchTerm' need to be extended or customized as per the requirement..
4) Search Criteria and Result
          Targets customers who have selected specific search filters, or whose search results include specific catalog entries.
          Similar to Web and Dialog activities, the option you choose in the Search Rule Builder is represented as an icon, known as an action, in the search rule flow. In the above example of a search rule, Specify Top Search Results is an action element.

5.3     Implementation Procedure

          There are different types of search rules and below examples describes some of the mostly used search rules.

5.3.1 Ranking Factors [Relevancy Score customization]

          Ranking factors are specified as a positive number, and promote or demote catalog entries in search results by increasing or decreasing their relevancy score. Assigning higher ranking factors typically corresponds to higher relevancy scores when catalog entries are promoted, or lower relevancy scores when catalog entries are demoted. As a result, catalog entries with adjusted ranking factors appear higher or lower in store search results.
          Ranking factors can be assigned for the following ranking criteria:
Property : The property to assign ranking factors and the following properties are available by default:
·         Code
·         Manufacturer Name
·         Manufacturer Part Number
·         Name
·         Short Description
Catalog entry type : The catalog entry type to assign ranking factors and the following catalog entry types are available by default:
·         Product
·         SKU
·         Bundle
·         Kit
·         Dynamic Kit
Attribute Dictionary Attributes : Attribute Dictionary Attributes with predefined values and marked as Use in merchandising to assign ranking factors.
Category : The category to assign ranking factors.

5.3.2 Adding Catalog Entry Properties To Search Rule Actions Or Targets

          In this scenario, we are assigning ranking factor to Property to promote catalog entries by adding new indexed catalog entry property.
          This Search rule actions and targets in the Management Center dynamically populate a list of catalog entry indexed properties. You must customize search when you are adding new indexed catalog entry properties to search rule actions or targets.
Step 1: Open Marketing tools in Management Center
Step 2: From the toolbar, click the arrow on the right side of  Create New; then select Search rule. The New Search rule template window opens.
Step 3: In the left pane, click the name of the folder containing the template you want to use. The Custom Templates folder contains any templates you have created.
          The Management Center includes the following standard search rule templates and select ' Change Search Result Order ' then click OK. The Search Rule Builder opens. The top half of the page is the work area. The bottom half of the page is the properties view.
Step 4: In the properties view, set the following properties for the search rule:

Property
Description
Name
Enter a meaningful name in the field. This name displays in the search rules list page, and identifies the search rule.
Description
Enter a meaningful description in the field. This description displays in the search rules list page, and it should explain what the search rule is intended to do. This description helps business users understand the search rule at a glance without having to open the Search Rule Builder.
Priority
Optionally, assign the search rule a priority using this list. The priority can be assigned using a number between zero and one thousand. The higher the number, the higher the priority. When multiple rules are scheduled, they are evaluated in priority sequence.
Start Date
Define a start date and time for the search rule. If you do not specify a start date, the rule will be applicable as soon as it is activated.
End Date
Define an end date and time for the search rule. If you do not specify an end date, the rule will run indefinitely.

Step 5: Create a default Property selector as mentioned in below screenshots
Step 6: Register the new indexed catalog entry property in the 'SRCHATTR' table:
Where '_cat. customerRanking' is the search index field name that you want to add. This field name must be prefixed with '_cat.' to identify the object as a search attribute and the field name customerRanking is used as the identifier for a sample catalog entry property. The customerRanking property is used as a sample catalog entry property to demonstrate the steps in this topic only; by default, this property does not exist for any catalog entry and there is no logic that is associated with this sample property.
Step 7: Specify the usage and data type of the property in the 'SRCHATTRPROP' table.
Depending on the catalog entry property data type and usage, different PROPERTYNAME values must be used. The usage results in populating the indexed catalog entry properties in different search rule action or target grids. The type results in populating different matching rules in each of the search rule action or target grids.
The following table shows the supported usage and data types for catalog entry properties:
Supported usage and data types for catalog entry properties:

Property
Data Type
Usage
merchandising-Filter-ExactText
Single words or phrases such as Manufacturer Name.
Catalog Entry properties with these usage-types are used in the Recommend Catalog Entry, and Add or Replace Search Criteria actions filter grid.
merchandising-Filter-AnyText
Sentences or multiple words. Such as name and short description.
merchandising-Filter-Numeric
Decimal numbers or whole numbers. Such as Customer ranking.
merchandising-Rank-ExactText
Single words or phrases such as Manufacturer Name.
Catalog Entry properties with these usage-types are used in the Change Search Result Order ranking grid.
merchandising-Rank-AnyText
Sentences or multiple words. Such as name and short description.
merchandising-Rank-Numeric
Decimal numbers or whole numbers. Such as Customer ranking.
merchandising-Facet-ExactText
Single words or phrases such as Manufacturer Name.
Catalog Entry properties with this usage-type are used in the Search Criteria and Result target, search criteria grid.
merchandising-Sort-Text
All text including single words, phrases, or multiple words such as Manufacturer Name.
Catalog Entry properties with this usage are used in the Recommend Catalog Entry, and Add or Replace Search Criteria actions sorting grid.
merchandising-Sort-Numeric
Decimal numbers or whole numbers. Such as Customer ranking, offer price.

to add a sample customerRanking catalog entry property to the Change Search Result Order action ranking grid, the usage is Rank and the data type is Numeric.
Step 7: Specify the display name of the added indexed catalog entry property in the 'SRCHATTRDESC' table:
Where 'Customer Ranking' is the search index field name you want to add.
While adding a property to the 'SRCHATTRPROP table, you can also add a language-specific name for the property to be displayed in the Management Center into the 'SRCHATTRDESC' table. This is for the search column that is registered in the 'SRCHATTR' table for which you are defining a new purpose in the 'SRCHATTRPROP' table. If no record is added to the 'SRCHATTRDESC' table, the IDENTIFIER is used from the 'SRCHATTR' table.
Step 8: Restart WC Server to reflect the changes.

5.4     Search Rule Evaluate

          You can schedule multiple search rules at the same time for a specific keyword, or for all keywords, or a combination of both. If so, the search rules are evaluated and run in a specific sequence.
1) First, search rules that target specific keywords or phrases are evaluated and run in order according to their Priority value.
2) Next, search rules that target all keywords are evaluated and run in order according to their Priority value.
          The following table summarizes the compatibility characteristics of the search rule actions. The actions listed in the first column of the table are run as part of a higher priority rule. Then, the actions in the first row are run as part of a lower priority rule:
Search rule action priorities


Action run in a higher priority rule
Action run in a lower priority rule
Change Search Result Order (sorting)
Change Search Result Order (ranking)
Specify Top Search Result
Add or Replace Search Criteria (add)
Add or Replace Search Criteria   (replace)
Change Search Result Order (sorting)
The result set is sorted according to the higher priority rule sorting criteria first, and lower priority rule sorting criteria second
The search result sorting takes priority over ranking
The search result sorting takes priority over the specified top search result
The search result scoped by the Add or replace search criteria action is sorted according to the sorting criteria specified in the Change Search Result Order action
The search results for the replaced keyword are sorted
Change Search Result Order (ranking)
The search result ranking takes priority over sorting
The ranking criteria from both actions are used. In case of a collision when both actions have the same ranking criteria, the one from the higher priority rule takes precedence
Search results are ordered, but the top catalog entries are still displayed at the top of the search result
The search result scoped by the Add or replace search criteria action is ordered according to the ranking criteria specified in the Change Search Result Order action
The search results for the replaced keyword are ordered according to the ranking criteria
Specify Top Search Result
The top search result takes priority, and the search results are not sorted
The search results are ranked, but top catalog entries are still displayed at the top of the search result
Either action's specified catalog entries are displayed first in search results, in order of their relevancy to the shopper's search terms, and in the order specified in the action (lower priority rule or higher priority rule)
Scoping the result set might remove the catalog entries from the Specify Top Search Result action
The search keyword is replaced, but the top catalog entries are still displayed at the top of the search result
Add or Replace Search Criteria (add)
The search result scoped by the Add or Replace Search Criteria action is sorted according to the sorting criteria specified in the Change Search Result Order action
The search result scoped by the Add or Replace Search Criteria action is ordered according to the ranking criteria specified in the Change Search Result Order action
The filter is applied which might result in removing the catalog entries from the Specify Top Search Result action
The search criteria from both actions are used. In case of a collision when both actions have the same search criteria, the one from the higher priority rule takes precedence
The search results for the replaced keyword are scoped
Add or Replace Search Criteria (replace)
The search results for the replaced keywords are sorted
The search results for the replaced keyword are ordered according to the ranking criteria
The search keyword is replaced, but top catalog entries are still displayed at the top of the search results
The search results for the replaced keyword are scoped
The action from the higher priority rule takes precedence


6           Definitions, Acronyms, and Abbreviations



Term
Description
OTB
Out of Box
WC
WebSphere Commerce
WCS
WebSphere Commerce Server

7           References


Name
Path
[1]  SRCHATTR
[2] SRCHATTRDESC
[3] SRCHATTRPROP








No comments:

Post a Comment

Java 7 Interview Question's

New Features introduced from  JAVA 7 : 1) Using strings in switch statements 2) Binary values with prefix 0B (Example: int n = 0b1101) 3) In...