Hi Igor, Amol,
I took a fresh look at this today, and I think I finally understand the issues here. To rephrase Igor's explanation, it seems that the issues are:
1. The Product Partition Report does not contain sufficient information to reconstruct the ProductPartition tree (without product detail).
2. It's difficult to tie the data in Shopping Performance Report back to specific products.
Possible solution: Include the MerchantId, StoreId and OfferId columns in your report request. This will allow you to tie the report data back to the product-specific information you get via the Content API.
3. How can we determine the product partition for a specific product?
Possible solution: Similar to item #2, you could run a Shopping Performance Report that includes:
- The key fields for the different types of
caseValue, e.g., Brand (for ProductBrand), CategoryL1/CategoryL2/CategoryL3/CategoryL4/CategoryL5 for ProductBiddingCategory, ProductCondition for ProductCanonicalCondition, ProductTypeL1/ProductTypeL2/ProductTypeL3/ProductTypeL4/ProductTypeL5 for ProductType, etc.
- MerchantId, StoreId and OfferId fields
Here's an example using AWQL (to optimize report performance you should only bring in the fields you actually need):
SELECT CampaignId, AdGroupId, Brand, CategoryL1, CategoryL2, CategoryL3, CategoryL4, CategoryL5, ProductCondition, ProductTypeL1, ProductTypeL2, ProductTypeL3, ProductTypeL4, ProductTypeL5, CustomAttribute0, CustomAttribute1, CustomAttribute2, CustomAttribute3, CustomAttribute4, StoreId, OfferId, Cost, Impressions
FROM SHOPPING_PERFORMANCE_REPORT
WHERE CampaignId = xxx AND AdGroupId = yyy
DURING THIS_MONTH
The combination of all of the various case values + the StoreId and OfferId fields would give you the partition for each product.
Do the above suggestions help?