LinkedIn
Twitter
Retail Search is a service provided by Google Cloud for retailers to use similar Google Search type capabilities, but with the retailers' own products.
When onboarding onto Retail Search, the primary driver for quality search results and performance is the data. Retail Search performance (relevancy, ranking, and revenue optimization) is extremely sensitive to the data that's uploaded.
To help ensure retailers are utilizing Retail Search effectively, we've put together a list of best practices when onboarding data to Retail Search. In this blog, we cover user events best practices. Click the below links to jump to the other articles in this series covering best practices for product catalog, integrations and configurations, and A/B experiments.
- Product catalog best practices
- User events best practices
- Integration and configuration best practices (you're here!)
- A/B experiments best practices
Integration and configuration best practices
1. Start with no controls
More on serving controls here and here. It's 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's originally done to improve the revenue and relevancy of the search result.
The Serving controls should be added if there's a very strong business need to do so. For example, ABC.com is an online fashion marketplace. They have in-house brands “pqr” and “xyz,” along with other brands. Now, ABC.com may choose to boost in-house brands “pqr” and “xyz” (i.e. bringing them to the top of search results) for a few particular search queries (like ‘women’s tops’). The business use case for this could be that ABC.com has better margins with products of brand “pqr” and “xyz," which provides the justification to “meddle” with the default ranking (i.e. without boost).
Another reason it's recommended to start out with minimal controls is because the backend AI model will continuously learn and adapt based on user buying patterns and trends (as the backend trains on 30-90 days window worth of events). A good number of use cases around synonyms would be already taken care of.
In summary, the decision to add serving controls should be backed by some strong revenue indicator or business use case.
2. Attribute configuration
See prerequisites on attribute configuration here. 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. Additionally it's recommended to set true/false flags for the attributes that will make it searchable, indexable, etc. It's highly recommended to set at least one of the configuration flags to true for the attributes.
3. Exact match attribute config
The exact match config flag is used for attributes like “model_name” or “part_number” which tend to be unique alphanumeric characters. For example, a washing machine model may have a model number like “WA2300AH3000”. In this case, it's recommended to set the attribute as “model_name” and set the config for exact match to “true” so that when the search query matches the “model_name” attribute string, only this product is returned in the search result.
A word of caution is to not use commonly-used words or brands in attributes and have exact match set to true. This will highly restrict the search result when those commonly-used words are in the search query, resulting in low product recall for commonly-used search queries, and affect the CTR / CVR metrics.
4. Retail Search is a ranking service only
The value proposition of the 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.).
Essentially, Retail Search service returns a revenue- and relevance-optimized ranked list of products to be displayed to the end user. Retail Search is not a replacement for the catalog database.
Therefore, it's recommended to not “connect/integrate” the search response from Retail Search to the UI components directly. It's better to build an enrichment layer that enriches the search response with additional data that may not be returned as part of the search response, but are needed for the UI/UX.
If needed, the product get / list APIs can be used to get the complete product info as part of the enrichment layer. One possible advantage of the enrichment layer is that you can develop a caching logic to handle non-logged in users or bot traffic to optimize on search API call costs and to reduce latency.
In this blog, we covered integration and configuration best practices for high performance with Retail Search. Click the below links to jump to the other articles in this series covering best practices for product catalog, user events, and A/B experiments.
- Product catalog best practices
- User events best practices
- Integration and configuration best practices (you're here!)
- A/B experiments best practices