- <PrimaryCategoryName>Clothing, Shoes & Accessories:Men's Clothing:Blazers & Sport Coats</PrimaryCategoryName>
- <SecondaryCategoryName>Clothing, Shoes & Accessories:Men's Clothing:Coats & Jackets</SecondaryCategoryName><SecondaryCategoryIDPath>11450:1059:57988</SecondaryCategoryIDPath>
- I again find myself in need of this feature.
- Using the example above, say for example I have a user that wants to view "boots" from the clothing category, but wants to exclude Men's Clothing. While a negative search term is possible, the problems with that come when sellers list in a category such as 11498 (Mens Shoes->Boots) and don't include "men's" or "boots" in the title, instead relying on the category name.
- I can set up a search for "boots" in 11450 to get all boots.
- Items in Men's clothing would have :1059: in the category ID path, regardless of the subcategory they are in.
- So I can exclude these items by simply testing the category id path against ":1059:"
- The category path name can also be used to do some keyword matching or exclusion.
- Take this item for example:
- Item: 181600108975
- Title: Iron Man 254 Marvel 1990 Santa Claus Christmas Cover Bob Layton Taskmaster
- Descr: Taskmaster is one of the baddies here. Sign up for the store newsletter!!!
- Say I want to get all Iron Man collectibles and then I want to group them in a database by item type. I search collectibles for "iron man" then based on various keywords I group them together. This item belongs in the comics section, but there's nothing in the title or description to indicate that. Finding API only returns the listing category "Iron Man" 165411.
- The category histogram is of no use here because it isn't linked to the item and 165411 isn't included. Only the first two levels are supported.
- With PrimaryCategoryName/IDPath in the Finding response, I could detect that the item is a comic and include it in that section.
- Here's how it looking in Shopping API:
- <PrimaryCategoryName>Collectibles:Comics:Copper Age (1984-1991):Superhero:Iron Man</PrimaryCategoryName>
- While I can do some exception processing here to limit the calls to GetMultipleItems, it would be much easier to implement this sort of thing (and breadcrumbs and other category hierarchies) at the individual item level with these fields and the complete category hierarchy included in the response at the item level.
- An alternate summary format would work too: these two fields (for both primary and secondary listing categories) as needed for each leaf category returned in the results