Product aggregation and “master” products
Many e-shops sell “product groups”, such as one model of shoes in many sizes. Product group is usually represented by one virtual product called Master. The product detail page then exists for this Master, and only there the visitor selects the variant, before putting it in the basket.
This means that we need to show theses Master variants in the recommendations too. We also need to calculate statistics for them, links to other products etc.
Product variants are useful in a limited number of scenarios, such as in the Abandoned basket, where it is suitable to show the right color/size variant, that was selected.
The product feed includes these items:
- itemID – which corresponds to an individual product, that can be bought. Is has a specific size, color, etc.
- itemGroupID – which indicates belonging to a certain product group
- isMaster – to distinguish, which product should be considered as Master (for example, sometimes the variant also contains it’s Size in the Title, which is not logical for a Master)
The e-shop can specify, what the values of itemID and itemGroupID look like. They are often pulled from internal e-shop’s DB. The only important thing is that they match the right product groups.
The goal of product aggregation is to:
- Get a single Master ID, for Persoo can calculate statistics
- Get a list of all possible properties for a given Master ID (colors, prices, sizes…)
MasterID: If the product belongs to a product group, it’s masterID is the itemGroupID. If it does not belong to any group, it’s masterID is by default it’s itemID. It’s important not to have collisions between itemID and itemGroupID.
How does the aggregation work
Tbhe following table has two sides. The left side contains data as they were imported into Persoo. Each itemID has it’s URL, price, image etc. The right side has data that Persoo stores, where the recommendID is the itemID of the product, that is returned in the recommendations.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
input data || data returned by Persoo itemID | itemGroupID | size | color || itemGroupID | itemID in reommendations ----------------------------------------------------------------------------- // simple item 1 | | | || 1 | 1 // item group 2 | g1 | S | || g1 | 2 3 | g1 | M | || g1 | 2 // item group with selected master product 4 | g2 | S | || g2 | 5 5 (M) | g2 | M | || g2 | 5 // item group with more colors (to be implemented soon ...) 6 | g3 | S | red || g3_red | 7 7 (M) | g3 | M | red || g3_red | 7 8 | g3 | S | blue || g3_blue | 8 9 | g3 | M | blue || g3_blue | 8 // item group with virtual master product 10 (M)| g4 | - | || g4 | 10 11 | g4 | S | || g4 | 10 12 | g4 | M | || g4 | 10 |
(M) next to the itemID means the isMaster field is “true”.
Persoo uses two tables internally:
- productVariants – which contains data from the input, as they were imported, and
- products – which contains aggregated product (according to the masterID)
Note: if there is a possibility of collision of itemID and itemGroupID, their values should be preceded by a differentiating string, such as “i” and “g”.
The master has to contain all necessary data you want to work with (e.g. price, image link etc.).
It inherits and aggregates data from variants only for fields “prices”, “colors”, “sizes” and few others!
Examples of itemID and itemGroupID mapping
Left side of the example tables show data as they are in the e-shop DB, the right side shows how they should be given to the Persoo feed.
Magento
ID of the product has it’s own SKU. That corresponds to either a simple product (1 SKU), configurable product (Nx SKU) or grouped product, which contains multiple simple products.
There is a separate table in the DB, that contains relations between products:
|
1 2 3 4 5 6 7 8 9 10 |
id | productType | size || itemID | itemGroupID --------------------------------------------- 1 | simple | || 1 | 1 2 | conf (3,4) | || 2 | 2 3 | simple | S || 3 | 2 4 | simple | M || 4 | 2 5 | group (6,7,8)| || 5 | 5 6 | simple | M || 6 | 5 7 | simple | L || 7 | 5 8 | simple | XL || 8 | 5 |
PrestaShop
Uses id_product, which corresponds to items, that can be displayed as variants on the product detail page. If you want e.g. a different color variant, then the eid_product looks into a table with variants (id_product_attribute).
|
1 2 3 4 5 6 7 8 9 10 |
id_product | id_product_attribute || itemID | itemGroupID --------------------------------------------------------- 1 | || 1 | 1 2 (M) | 1 || 2_1 | 2 | || 2 (M) | 2 2 | 2 || 2_2 | 2 2 | 3 || 2_3 | 2 3 (M) | 4 || 3_4 | 3 | || 3 (M) | 3 3 | 5 || 3_5 | 3 |
We will import each variant as a separate itemID. The products, that have variants will be imported as Master variants.
Second advantage is, that the recommendations is, that they will return only itemID, which corresponds solely to id_product, so PrestaShop will not have to do any backwards translation (even though separating everything after the underscore should not be a problem).
WooCommerce
Since it’s derived from WordPress, the products are realized through posts with unique postType values. This means the relations are done through the same parent-child dependency as with regular posts. It helps that all the IDs are different.
WooCommerce supports these product types: simple product, variable product (can have variants), grouped product (group of other products), external produkt (is sold at a different shop). Variable product contains productVariants as children.
|
1 2 3 4 5 6 |
postType | post_id | parent_id || itemID | itemGroupID simpleProdut | 1 | || 1 | variableProduct | 2 | || 2 | 2 productVariation | 3 | 2 || 3 | 2 productVariation | 4 | 2 || 4 | 2 productVariation | 5 | 2 || 5 | 2 |