GCP Retail Search Onboarding : Best Practices for Integration and Search configs (Part 3/4)
This blog is part 3 of a 4 part blog series on GCP Retail Search Onboarding best practices. Highly recommend to start with Part 1
In part 3 we will cover the best practices in Integration/Design and Search configs in Retail Search for optimal performance.
(The basics of Retail Search configs and controls are not covered in this blog)
Compare search results with zero controls initially.
It is recommended to start using Retail Search with minimum to zero serving controls In place. Serving controls like Boost/Bury meddle with the ranking optimization that is originally done to improve the revenue and relevancy of the search result. The Serving controls should be added if there is a very strong business need to do so. For example, ABC .com is an online fashion marketplace, they have in-house brands “ABC-jeans” and “ABC-shirts” along with other brands. Now the business needs at ABC .com may choose to boost in-house brands “ABC-jeans” and “ABC-shirts” (i.e. bringing them to the top of search result) for a some search queries (like ‘womens tops’), the business use case justification for this could be that ABC .com has better margins with products of brand “ABC-jeans” and “ABC-shirts”, due to this it could be justified to add a Boost rule and “meddle” with the default ranking (i.e. without boost).
Another reason it is recommended to start out with minimum controls is because the backend AI model would continuously learn and adapt based on user buying patterns and trends (as the backend trains on a window of 30–90 days worth of user events). A good number of use cases around synonyms would be already taken care of by default as the backend AI model does query intent understanding. The basis for the decision to add serving controls should be backed by some strong revenue indicator or a strong business use case.
Attribute configuration.
The purpose of attributes is to extend the product info structure and add user defined product attributes. The attributes are not to be used as a store of information into Retail search catalog. Additionally it is recommended to set true/false flags for the attributes that will make it searchable, indexable etc via the attribute configuration. It is highly recommended to set at least one of the configuration flags to true for the attributes.
Exact search attribute config.
The exact searchable attribute config flag is used for attributes like “model name” or “part number” which tend to be unique alphanumeric characters which by itself doesn't have any meaning. Example: a washing machine may have an attribute like model number with value “WA2300AH3000”. In this case it is recommended to set the “model number” attribute config for exact searchable to “true”. When customers search by model name as the search query, it is usually expected to bring back one product exactly. So by NOT setting model name as exact match, you are NOT making the product very strongly be associated with the alpha numeric model name string, which otherwise might lead to zero search result when someone searches by model name. Product id is by default exact searchable set to “true” always.
A word of caution is to not use commonly used words or brands in attributes and have exact searchable set to true. This will highly restrict the search result when those commonly used words are in the search query. This will lead to low product recall for commonly used search query, and affects the CTR, CVR metrics
Retail Search is a ranking service only.
The value proposition of Retail Search service is that it is used to discover products from your catalog based on query relevance and rank them in a revenue optimized manner (along with auxiliary functionalities like Boost/Bury/Filter etc). Basically retail search service returns a revenue + relevance optimized ranked list of products to be displayed to the end user. Retail search is not a replacement for the Product/catalog database.
Therefore it is recommended to not “connect/integrate” the search response from Retail Search to the UI components directly. It is highly recommended to build an enrichment layer that enriches the Retail Search response with additional data that may not be returned as part of the search response but are needed for the UI/UX.
The product get / list apis can be used to get the complete product info as part of the enrichment layer if needed. One possible advantage of the enrichment layer is that it allows you to add caching to handle non-logged in users or bot traffic to optimise on search api costs / reduce latency etc
In conclusion search controls and configs along with the right integration design is paramount for optimal search performance and better end user experience.
