Oracle® Retail Science Cloud Services Implementation Guide Release 19.1.003.2 F40917-01 |
|
![]() Previous |
![]() Next |
This chapter contains frequently asked questions and their answers.
Here are some answers to typical questions of a general nature.
What delimiters are used in the data files?
The inbound data files must be pipe-delimited, while the outbound files are comma-delimited. The delimiters are not configurable.
When are W_RTL_RECLASS_DP_GP_TMP and W_RTL_RECLASS_IT_SC_CL_TMP interfaces used?
These are generally used for implementations that also use RI's data warehouse reporting.
If CREATED_BY_ID and CHANGED_BY_ID columns in every table are set to -1, will it have negative impacts on the functionality?
The value of -1 is the normally expected/used value. The value used will not affect functionality.
CREATED_ON_DT and CHANGED_ON_DT and SRC_EFF_FROM_DT are given values for every table, but since the value is not used functionally, can it be set to a value of NOW?
The only interface where this approach is not appropriate is W_RTL_PROMO_DS. For this interface, the SRC_EFF dates must indicate when the promotion was in effect. (If sales transaction data is not provided, W_RTL_PROMO_DS.dat interface becomes pointless, and therefore defaulting to NOW will be fine everywhere else.)
Here are some answers to typical questions related to demand transference.
Demand transference can make use of similarities derived from customer-linked transactions data. What is the advantage of using this type of similarity, instead of attribute-based similarities?
The benefit to using customer-linked transactions is that the similarities are not dependent on good construction of attributes and attribute values; in addition, the similarities will agree with the CDT if the customer has also implemented CDT. However, keep in mind that to handle the case of new items, attributes are required anyway, so even when using transaction-based similarities, it is still necessary to construct attributes.
What are the disadvantages of using similarities derived from customer-linked transactions data?
Two key disadvantages are:
Retailers want the similarities to be intuitive to their business users, and attribute-based similarities are much better for this because they are more transparent, particularly when the attributes provided by the business users themselves are used.
The requirement for frequent repeat purchases is a high requirement for a category to meet. Many grocery and drug store categories can meet this, but even at grocery or drug stores, there are categories, such as small electronics, that cannot meet this requirement. There are also categories such as batteries or toothbrushes that do have repeat purchases, but the length between purchases is quite long. For such categories, it is probably better to use attribute-based similarities.
Is it possible to use transactions-based similarities for categories where repeat purchases occur but are very infrequent?
It is recommended that you use attributes for such categories, but if there is sufficient data for the category, it is still possible to use transactions-based similarities. You must have either (or both):
A longer period of history for the category (for example, three years instead of one year) so that there is more chance of catching repeat purchases. Note that this does not necessarily mean that the actual data volume is higher. For example, for batteries, the data volume for three years might be equal to the data volume for six months of dairy, since battery sales have a much lower rate than dairy.
A large number of customers (at least 100,000) for each segment of the category, if you are implementing segments, or just a large number of customers (at least 100,000) for the entire category, if you are not implementing segments. Having such a large number of customers increases the probability that a significant fraction of them will have made repeat purchases in the category in your historical data, even if each customer did not make many repeat purchases. For example, you could have 100,000 customers, each of whom made only one repeat purchase.
How can grouped attributes be used in the Retail Science platform?
Grouped attributes are recommended only for CDT, not DT. For CDT, the guideline is that attributes must have no more than seven values. Grouping is a way to achieve this goal, as it groups together many attribute values into a single value. Having attributes with a large number of attribute values can result in very large CDTs, especially if the attribute occurs at the top of the tree. This general guideline of seven values is a way to keep CDTs to a reasonable size. Note that retailers seem to prefer having large CDTs with ungrouped attributes.
What attributes are typically good candidates for grouping?
The most common attributes are Brand, Flavor, and Color, because these attributes typically have a large number (that is, more than 50) of values. Keep in mind, that retailers typically do not want grouped attributes.
How can the Brand attribute be grouped?
Brands can, for example, be grouped into High End, Mainstream, and Budget. The grouping must be driven by how the retailer thinks of the category and thinks of brands in the category.
Does the software automatically determine which attributes are functional fit? Can the software help me determine which attributes are functional fit ones?
There is no way to automatically detect functional-fit attributes, or close-to-functional fit attributes. The determination is done today using business users' intuition, not science.
Are there other uses of functional-fit attributes besides the obvious examples like size in wiper blades and clothing? What about functional-fit attributes for food items?
Functional-fit attributes are useful for items such as food for expressing strong customer preferences. For example, caffeinated can be set as a functional-fit attribute for the Coffee category to eliminate transference between caffeinated and de-caffeinated coffee. While it is possible that a small minority of people might transfer purchases of one to the other, it is unlikely enough that, when planning an assortment, transference should simply be eliminated. Note that this is based on the business user's intuition, since there is no automatic way to detect these situations.
What are the special considerations for categories containing very few items, such as 20 or fewer?
Such categories are very rare; typically, categories have hundreds to thousands of items. Small categories may cause a problem in determining demand transference because their historical data may contain very few assortment changes. The more items a category has, the more likely assortment changes will have occurred; conversely, small categories may have very few historical assortment changes, which makes determining transference in the category difficult. One solution is to merge the small category into a bigger category that has similar items. For example, merge a specialty bacon category containing 20 items with the regular bacon category (since both are bacon). This amounts to applying the assortment elasticity of the larger bacon category to the specialty bacon, and if the specialty bacon by itself has very few assortment changes, this is a reasonable solution.
How is new-item introduction handled by demand transference? Which cases of new items are handled?
The case the application handles is introducing new items at an existing store for an existing category that already has attributes. For this case, all that is required for the new item are its attribute values. No sales history is required for the new item. From the attribute values assigned to the new item, the similarity of the new item to existing items is calculated. This similarity is used to forecast a base rate of sale for the new item based on the sales rates of existing similar items. This base rate of sale is then used in demand-transference calculations.
How is W_RTL_PRODUCT_BRAND_DS interface used by DT?
Brand can be provided as an ITEMUDA, or it can be provided via W_RTL_ITEM_GRP1_DS with a PROD_GRP_TYPE=BRAND. If it is done as a PROD_GRP_TYPE=BRAND, then this interface receives the master list of Brands, which the W_RTL_ITEM_GRP1_DS refers to. If Brand is just provided as an ITEMUDA, then there is no need for this file.
How is W_RTL_PRODUCT_COLOR_DS interface used by DT?
In the same way as the W_RTL_PRODUCT_BRAND_DS interface, only the PROD_GRP_TYPE is COLOR in this case.
Here are some answers to typical questions related to ASO.
An item cannot meet the service level with the defined facings. Should the solver give more facings to meet the minimum service level restriction?
Not necessarily. This depends on the feed from the sales and inventory model, which indicates what the possible service level is for a given number of facings. If it indicates that adding any number of facings will not necessarily help, then the solver drops that item if it is not mandatory or returns no solution if it is mandatory. It would be worthwhile for the user to review the replenishment data provided for the item.
Why are empty spaces present in the planogram?
The goal of the optimization is never to fill up the entire space. Empty spaces can arise for a variety of reasons. This can occur if more than sufficient space is available for all the products. In this case, the solver places the products in more than one elevation and location. Alternatively, many constraints may be in play at the same time and one of them can cause some products to be dropped.
The solution generated does not seem optimal, since I can generate a better solution. Why?
Such a situation does not arise normally. It can sometimes happen because the optimization searches for the best possible solution within an allocated time. The allocated time can vary, depending on how many jobs are running and how much processing power is available for this job. To negate such uncertainty, user can increase the time allocated for the optimization from the default value of 180 seconds.
Why are items not sorted across the shelves?
The sorting functionality sorts items within a particular shelf. It does not sort across shelves as this negates the optimal placement determined by the optimization and can sometimes result in infeasibility. For these reasons, sorting is not allowed across shelves. The user is advised to examine the visual guidelines to obtain the desired structure.
Why are the horizontal blocks arranged in a zigzag pattern instead of being truly horizontal?
This can arise for the shelf fixture type. If the bays are actually identical, then the optimization can generate horizontal blocks. However, most often, the shelves are not aligned perfectly across bays and so the optimization is asked to look for almost horizontal blocks. In the case of the pegboard fixture type, the optimization can generate actual horizontal blocks, as it is not limited by shelf elevations.
Why is an assortment not ready for optimization?
An assortment may stop at the pre-optimization stage and not be ready for optimization because errors were found either in the assortment data during data loading, during the checking of integration with other data sets (such as missing replenishment, display style, and so on), or during the mapping process and requiring user review. Mapping errors can be examined in the Assortment Mapping UI. In addition, assortments that are ready for SO may not be available for optimization if the POG set to which they are mapped has multiple assortments mapped to it and at least one of those assortments is not ready for optimization due to mapping errors. In such cases, the POG set is meant to optimize multiple assortments; having errors in at least one of them prevents the whole POG set from becoming available for optimization.
Can I copy an old run from an assortment for the same category rather than a new assortment and use it against the new assortment (most of the products/stores should be the same)?
No, a run's scope is limited to the POG set and specific assortments used in that run. Once the assortments from that run are exported and finalized, there is nothing more to do with it. The user can still copy the run and perform some test scenarios, but the data used in the run corresponds to the old assortment and there is no relationship with newest data from more recent assortments.
I just sent some POG and mapping data to fix some of the errors in an assortment. However, the assortment still shows that mapping results require review. Why wasn't the newest data used to fix the mapping errors?
The assortment to POG mapping process runs every time an assortment is loaded into ASO and every time the direct assortment data is updated. In this case, the data that was delivered is not part of the assortment, so there is not an automatic mapping process for the assortment. An authorized user must use the Assortment Mapping UI and manually request the Re-map action from the drop-down menu. The mapping process will then run again. It will use the latest data available within the application, and, if all the data elements provided fix the old mapping errors, the assortment will map correctly and will be upgraded to the ready for optimization status.
When ASO exports data to APO, will the core and optional items that have been marked as 'Must Keep' in ASO be sent as mandatory items in APO?
APO data is used to initialize the run in ASO as follows: Product Priority=1 becomes Must Keep, Product Priority=2 or 3 become Can Keep and Product Priority=-1 becomes Do Not Include. The user has the option of changing the inclusion constraint in the UI. This inclusion information (Must Keep or Can Keep or Do Not Include) specified in the optimization is not sent out in the ASO Export interface.
What kind of mixed fixture type layouts are supported in ASO?
There are three fixture types that are supported in ASO: Shelf, Pegboard, and Freezer. ASO does allow the user to input a mixed fixture bay layout; however, it provides support when there is at most one transition from a fixture type to another fixture type. For example, it supports a layout that goes from Shelf to Pegboard or vice-versa. However, it does not support a transition such as shelf to pegboard and then back to shelf again.
How do Visual Guidelines work when there are multiple fixture types?
Visual Guidelines are defined per fixture type, and the blocking is carried over from one bay to another for each fixture type. There might be physical separation between the fixtures, but it is ignored for Visual Guidelines. However, when outputting the final position of the items, the actual bay/fixture layouts are respected.
What is the difference between using Gross Profit vs. Gross Profit Return on Investment (GMROI) as objectives?
When the user optimizes with GMROI, the optimization tries to achieve as much of Gross Profit as possible but with the least inventory cost. For example, to maximize gross profit, one could theoretically have lots of inventory. On the other hand, to keep inventory cost low, one could carry very low inventory. So the goal is to analyze the trade-offs between carrying too much inventory and achieving too much gross profit. The GMROI objective balances between these two competing metrics.
What is the difference between the Generic and the Non-Generic version of GMROI?
In the Generic version, the user does not have to provide store level inventory; in the non-generic version, the user is expected to provide store level inventory. Optimization uses the store level inventory for calculating the inventory cost.
I have selected primary as vertical, and used the merge sequence for some of the primary vertical blocks. What does it do?
When a primary blocking strategy is vertical, and if the user specifies the merge sequence for a vertical block, then it automatically creates secondary horizontal blocks for this vertical block. This functionality is reversed when the primary is horizontal.
Here are some answers to typical questions related to attribute processing.
Is it allowed for RSE_PROD_ATTR_VALUE_XREF_STG to have attribute values which is not linked to items in W_RTL_ITEM_GRP1_DS? For example, given that in a certain season W_RTL_ITEM_GRP1_DS has following item/attributes: Item A Attribute 1, Item B Attribute 2, Item C Attribute 3, and Item D Attribute 4. RSE_PROD_ATTR_VALUE_XREF_STG should have Attribute 1,2,3,4. In the next season, Item C is dropped: Item A Attribute 1, Item B Attribute 2, and Item D Attribute 4. In this case, RSE_PROD_ATTR_VALUE_XREF_STG should be rebuilt to have only Attribute 1,2,4?
Yes it is allowed. The load will not fail if there is no data found, so it is not a data validation rule that requires there to be a matching attribute in W_RTL_ITEM_GRP1_DS. If there are no products associated with the attribute value, then the attribute value will not be used.
Can you have records with NULL for all the following five "VALUE" columns in RSE_PROD_ATTR_VALUE_XREF_STG? So, records will have value only for PROD_ATTR_VALUE_KEY and ATTR_VALUE_EXT_CODE columns: MIN_ATTR_NUM_VALUE, MAX_ATTR_NUM_VALUE, ATTR_STRING_VALUE, MIN_ATTR_DATE_VALUE, and MAX_ATTR_DATE_VALUE.
The interface provides multiple choices for identifying the attribute value. You must pick the one approach that works for the specific attribute and the remaining values are NULL. So for attributes that relate to data in W_RTL_ITEM_GRP1_DS, you provide a value for ATTR_VALUE_EXT_CODE and leave the other five indicated Attribute Value columns as NULL.
Here are some answers to typical questions that you may encounter.
In a price-zone, there are stores with different inventory levels. Some stores have very high inventory levels, and others have low inventory levels. Does OO recommend different recommendations for the zone and such stores separately?
This is not possible in the current release. You can configure Offer Optimization to run either at the price-zone level or at the store-level. If the price-zone level is selected, then all the stores within that price-zone will receive the same price recommendations. If you want to have store-level recommendations then you must configure the run-level to be at the store-level and let the algorithm dictate the recommendations. If the stores share very similar customer behavior, then it may be possible that they will receive similar recommendations.
I am not interested in the promotions; can the product handle only markdowns?
Yes, the product can handle only markdowns. You can define all the periods to allow markdowns, and no period should have promotions allowed.
I have a planned promotion and I know when the promotion should occur, but I do not know the items and the depth. Can the product recommend items and the depth?
No, the product requires planned promotion to specify the items, depth, and when the promotion should occur. However, if the retailer wants the product to recommend items and depth, then you can specify the promotion and markdown calendar using the interface provided and specify when the promotions and markdowns can be provided. Offer Optimization will determine which items should be promoted or the markdown among the set of periods provided. Note that you can also use the relative calendar option through the UI to specify the calendar.
Should I use Absolute Calendar or Relative Calendar?
The two calendars are provided for flexibility in handling two use cases. When all the items are introduced at almost the same time and exit at almost the same time, then it makes sense to use the absolute calendar. You can also use the relative calendar in such a use case. When the items are introduced at periodic intervals (for example, summer merchandise is introduced in May, June, and July) then it makes sense to use relative calendar. For example, the absolute calendar in such a scenario would probably say May, June as Regular and July as Clearance. This means that items that were introduced in July are going directly into a Clearance season. However, the relative calendar begins after the item is introduced. It is defined as the percentage of regular season and the percentage of the markdown season, based on the total length of the season available for the item.
Is the Style, Color needed as part of Merchandise Hierarchy?
Since the product supports fashion apparel, it is expected that the style and color be provided as part of merchandise hierarchy. If the retailer carries non-apparel items, then the retailer can specify some generic value for style and color, such as not applicable.
How does Offer Optimization handle the online channel?
The retailer can specify the online channel as a separate price zone. This means that the price recommendations for brick-and-mortar stores and online-stores will be different. If the retailer does not wish to have different price recommendations, then it is suggested that you combine the online channel into a brick-and-mortar store.
Can Offer Optimization handle complex promotions?
Offer Optimization handles only simple promotions (for example, percentage off). It does not handle complex promotions like BOGO.
Can Offer Optimization come up with bundles for complex promotions? How can this be handled?
Offer Optimization cannot come up with bundles for a promotion. A bundle can be specified using Product Groups under Business Rules.
Is budget constraint over the effective week or over the entire life of the item?
Budget is assumed to be for the entire remaining life of the item. The user can specify either different budgets for Promotions and Markdowns or a combined budget. Note that a planned promotions can be excluded or included from this budget.
What happens when a user accepts or rejects a recommendation? Do the numbers change for that week? Does it optimize the entire life again?
In the current release, the metrics in the Results or Manage Recommendations do not reflect the accept, reject, or override price recommendations. However, when the user selects the Recalculate button, then all the metrics are recalculated taking into account the price modifications done by the user. But, when the user selects Reoptimize, then the price modifications are ignored.
Can Offer Optimization handle any type of price-zone?
Yes. In the current release, Offer Optimization can accept price-zones that are defined as any combination of locations and merchandise.
How does Offer Optimization handle multi-currency support?
Offer Optimization accepts the historical sales data in the local currency provided. Further, the location in the application can be specified a country locale. Each application run has a location, which is used to tie the price and price-related metrics (for example, revenue) to the specified currency. However, if you want to configure the run to be at a level that spans multiple currencies, then you must specify one currency.
How does Offer Optimization support dynamic clustering?
Any time you change the price-zone or re-cluster the customer segments, the change must be re-loaded as part of new hierarchies to Offer Optimization. It is considered a major change to the application as it affects the core data elements. The application will be re-calculating the demand parameters and other relevant optimization inputs, based on the new hierarchies. Further, the UI does not offer support to re-group stores within a price-zone based on certain attributes, for example, group stores by sell-through.
How are product images loaded?
Product images can be loaded via the interface provided. Offer Optimization expects that the images will be loaded on an image server, which can be a local server. An URL is provided with the image name that can be accessed by the application. The application searches for the image and populates the UI with the relevant image for that item in the Targeted Offer screen.