Commercial Parameters
Commercial parameters configure how Ecommerce Search uses product data when performing commercial sorting of products and suggestions. Commercial parameters are used in conjunction with context partitions on a context to calculate the commercial boost of products.
Commercial parameters are managed through the user interface.
A commercial parameter consists of:
- Parameter id is used to uniquely identify the parameter,
- Name assigns an easy-to-read name to the parameter.
- Parameter type specifies the type of the parameter.
- Partitions which divide a parameter into one or more groupings, based on the parameter type.
Ingestion
The Ingest API is used to register commercial parameters in Ecommerce Search.
Parameter source
Commercial parameters can be configured with either an external source or a field source.
- External sources are recommended for ingesting commercial data from ERP systems and other sources of analytics.
- Field sources are recommended for data that is inherent to the item itself. Examples include brand or color.
Parameter types
The parameter type is used to determine how to normalize and partition the ingested values. See normalization for a more detailed description of normalization for each type.
An ingested value can only be mapped to one partition, not multiple partitions. If an item has data that does not fit into any of a parameter's partitions, it is ignored and therefore has no commercial value.
| Parameter Type | Partitioning strategy |
|---|---|
| Range | Numerical ranges e.g. 10%-25% |
| Term | Explicit terms for each partition |
| Rank | No partitions necessary |
| Cluster Rank | No partitions necessary |
| Proxy | No partitions necessary |
Range
The range parameter should be used when you have data that can easily be divided into intervals or ranges. Two decimal number fields, From and To, are used to define the range of a partition.
Note
The From and To define the range. From is inclusive and To is exclusive. This means that for the partition "7 days" the range would be [0.0 -> 7.99999...].
Boosting newer products
As an example consider how to model that an item is new. If you know how many days an item has been available then you could create the following partitions:
| Partition Name | From | To |
|---|---|---|
| 7 days | 0 | 8 |
| 14 days | 8 | 15 |
| 21 days | 15 | 21 |
By assigning descending weights to the partitions, we are then able to boost newer items more.
Note: If an item has been available for 22 days, then it does not fit into any partition and is therefore ignored.
Term
The term parameter should be used when you have data that is already aggregated into some partitions or you have some business logic that cannot be modeled by commercial sorting.
Boosting products in stock
A store might have some complex business logic that maps the stock level of an item as LOW, PLENTY, and SOLDOUT. For example, two dishwashers in stock would be PLENTY, but two soaps in stock would be LOW.
A term parameter with the following partitions could therefore be created to model the stock level:
| Partition Name | Value |
|---|---|
| Few In Stock | LOW |
| Sold out | SOLDOUT |
| Plenty in Stock | PLENTY |
Note If an item has the stock term HIGH, it will not fit into any partition and will be ignored.
Rank
Rank sorts the items numerically so that a rank can be calculated for each item. Each item is given a unique consecutive rank.
Rank is useful with event data, such as "clicks on item," as rank ensures that the item with the most clicks gets the highest score.
Cluster rank
Cluster rank is similar to rank, but items with similar numerical values will be grouped and get the same normalized value.
Proxy
In some cases, you may have your own first-party service or a third-party service that has already calculated a normalized value, and you just want to map that value directly to the item. In this case, you should use the proxy parameter.
Note
Proxy parameters should have values between [0.0 -> 1.0] to match how other parameters are normalized.