Understanding BrowseNode Results When Drilling Down

BrowseNodes are related in a hierarchy where one BrowseNode can have zero or more ancestor and child BrowseNodes, as shown in the following figure.

This diagram shows five BrowseNodes and their hierarchy. Node A might be, for example, Women. Node B might be Shoes. Node C, a child of BrowseNodes A and B, might be Women’s Shoes.

The number inside each node represents the number of items in the BrowseNode when ItemSearch is called on Node A. BrowseNode C is a subset of BrowseNode A and a subset of BrowseNode B. Perhaps fifty of the items in BrowseNode C are also in BrowseNode A. When ItemSearch was run on BrowseNode A, the operation returned that BrowseNode A has 200 items. When ItemSearch is repeated using a BinParameter Name value that was returned in the first ItemSearch request, it is the same as running ItemSearch on a child of BrowseNode A, which, in this case, is BrowseNode C. By narrowing the search to only those values found in BrowseNode C, ItemSearch returns only those items in BrowseNode A that are also in BrowseNode C. As shown in the following figure, the number of common items is 35.

As a result, ItemSearch returns that BrowseNode A now contains only 35 items. While the change in the item count in BrowseNode A might, at first, be confusing, understanding that ItemSearch is returning only the intersection of BrowseNodes A and C explains why the number of items in BrowseNode A changes. Notice that the item counts in other BrowseNodes can also change.

Because the number of items in surrounding BrowseNodes can change with each new drill-down using ItemSearch, the BrowseNodes that contain the greatest number of items can change dramatically. In the previous discussion, for example, the number of items in BrowseNode A changed from 200 to 35 on successive ItemSearch requests. Because ItemSearch returns only the top ten BrowseNodes that contain the most items, the identity of the top ten BrowseNodes can change with each ItemSearch.