This content has been marked as final. Show 5 replies
Sorry dude, you lost me at this line
We are trying to display the products aggregated based on product groups inside which the products are basically a set of SKUs aggregated based on product level (using product ids).Can you please elaborate with an example. Say this is what your catalog is (or use your own example):
Product Group: Shirts
-- Product: Golf Polo Shirt, Beach Shirt
---- SKU: Golf Polo Shirt-Pink, Golf Polo Shirt-Green, Golf Polo Shirt-Blue, Beach Shirt-White, Beach Shirt-Blue
What is your current record structure and what do you want to display?
Sorry for the confusion as the problem statement was little fuzzy.
With the above example, I would display only Shirts as a single product in the grid with multiple types of shirts as swatches where each swatch indicate a single product (golf or beach). Inside each swatch would be the skus for multiple colors of golf shirt or beach shirt.
Then, there is a two-level aggregation being done - one at product group level and and the other at product level.
Let me know, if this clarifies and helps you to understand the problem.
I don't think multi level aggregation is possible. You can aggregate at product group and get all sku within it. To get all skus withing a product either you need to iterate within aggregation or have property populated for product & sku association during indexing.
I think you could define two rollup keys -- Product Group & Product Id -- and produce the desired drill down experience in the application logic.
For example, initially, you could allow the end user to search and navigate and only display product groups (rollup=p_product_group_id). If the user clicked on shirts for example, you could apply a refinement of product_group_id=<shirts id> (i.e. N=<shirts_id>) and then rollup by product_id.
Personally, I think this is an awkward hierarchy (if your data is in fact retail data) as users likely won't want to search for product groups first -- they're too high level and not information goals in and of themselves. Typically, in retail, we just see product_id setup as the single rollup key.
Dan and Pankaj,
Thanks for your suggestions. I had the same idea too and looks like we concur at the same point - aggregate the records with the rollup key higher in the hierarchy and then use the other rollup key and achieve the second level of aggregation programmatically in the application logic when we process the result from the index using the presentation api.
@ Dan - My answer with the example was using the data set provided by Pankaj; so it might be little confusing and off the standard scenarios. So, let me provide a more accurate scenario.
In practice, in the retail data we generally group multiple product ids with various colors into a single group during rollup. If the SKUs are attributed to multiple colors then it becomes obvious that we can use the product id as the rollup and aggregate multiple SKUs each coming with a different color.
However, in our case the pricing and and sizing information and the sequence attribution inside a leaf of the catalog hierarchy is done at the SKU level. So, a product-id-color-size gives me a unique record in the data feed i.e. we are creating unique records at the SKU level here. Also, we are creating groups of SKUs with different colors but same product id in the grid wall. That is where we are trying to aggregate at two levels
1. at a product group level
2. at a product id level inside the group where all the skus with same color are grouped together
That way we are able to render multiple and unique color swatches inside each product group.
It looks like aggregating at product group level in the index and programmatically aggregating at productid-colorcode in the application logic gives me the intended solution.
Let me know if you guys think the same way or have different ideas.
Thanks in advance!
Edited by: 950423 on Jan 7, 2013 3:08 PM