SCC FeedbackWe value your input! Tell us what you think about our Sana Commerce Cloud roadmap initiatives and the direction we're taking. If there's something specific you'd like to see, don't hesitate to share it with us below. Vote for ideas on the page to let us know what you find important. You can vote by clicking on an idea and then click thumbs up, down or neutral.
Improvement to PIM indexing in Multishop situation
During an analysis of product index problems for a customer, I had a brainstorm with the team with some ideas that I had which I felt would be useful for the improvements list on PIM. Following is an extract from that (customer had InRiver but this applies to PIM in general IMO).
A single product indexing draws data from: 
ERP – Will be different per shop even for the same product. 
Main product infoAnonymous PriceSpecificationsVisibility rulesRelated itemsUoMsOther controlling data flags (e.g.: custom fields like made to order etc.)
InRiver PIM – Will be the same for all shops for the same product ID (check this).
NameTranslationsImagesAttachmentsSpecifications
Each product indexing task calls InRiver every time for all shops even if the product information is the same on all responses. Does the product image indexing task also run individually for all shops even if it is the same product: 
Is there any reason why a get product image response would return different values for different web shops for the same product?
If not can we cache the response in Sana on the scheduled run on the first shop and then use it in the subsequent shop index runs? In theory the opportunities that I see are as below:
Cache the InRiver data separately prior to Enriching:
Currently what happens is if a product info is modified (either in InRiver or ERP), we get ERP data from GetProduct call, get inRiver data from an InRiver product call, enrich the GetProduct response from this combined data. But if the InRiver response is the same for the same product regardless of which web shop is calling it, then it is not necessary to again fetch that InRiver data. 
On the task runs from the framework (from any shop), we can cache the fetched InRiver data against the product ID and store it in a temp table. When the Index of another shop is trying to fetch that same product ID data, the task can first check this cache table and if there is already cached product InRiver response, use the data from the Sana DB rather than fetch from InRiverFrom what I remember each InRiver call takes around at least 3 seconds per product).
If the fetch from DB is waaaay faster than fetch from InRiver (assume 1 second) then this should give us roughly 3-5 times performance gain. If product images are also fetched again and again, then the same theory can be applied to that. The customer can then do some checks and evaluation of the shops that get the most amount of daily modifications on products and set the schedules in descending order. This way most of the data from InRiver is cached already, and the shops further down in the indexing schedule in the same framework can benefit from the cached data resulting in faster processing.
Personalised AI-driven product descriptions
Personalised AI-driven product descriptions

The idea is to expand the capabilities of the existing AI product description add-on by including user profile data to generate more accurate product descriptions. By considering both the product attributes and the specific user segment, such as medical, food, or tech professionals, it aims to provide descriptions that are relevant and understandable for each user group. The configuration allows for the inclusion of existing customer segments to fine-tune the description outputs.

4
0
0