We recently completed an overhaul of our product search functionality (used primarily in our ProductSearch API module, but also as an accessory to some of our other tools like the Product Display Builder). As anyone who has tried to implement a keyword search of large amounts of data will tell you, the problem is not a simple one, and our solution is by no means perfect. But, having gathered feedback from our affiliates since the launch of our ProductSearch API over a year ago, we think we’ve made great strides toward improving the accuracy and performance of our offering.

To highlight a few of the key changes that were implemented in this revision:

• A complete ground-up rewrite of our keyword parsing and searching algorithm, resulting in performance gains of 200-300%.
• Improved handling of “exact” vs. “inexact” matches. Our original search algorithm differentiated between “exact” matches (where the keywords were all found in the product name) and “inexact” matches, and restricted search results to just the former if possible. While accurate, that behavior resulted in a lot of under-populated searches. The new algorithm scores matches differently and allows for a much broader (though still accurate) range of results for the same keywords.
• Simpler methods of specifying lists of merchant datafeeds to search. By default, the ProductSearch API will search through the datafeeds of all merchants for whom you are an active affiliate. If you have a large active merchant listing that’s a lot of data to search through which is undesirable for two reasons: (1) it results in a slower search, and (2) the chance of spurious search results is increased (for instance, by searching a wedding favors merchant for “backpacks”). To alleviate this, the API module has always supported specifying lists of merchants or lists of datafeeds to restrict the search to. As additional alternatives, it’s now possible to specify:
  • a list of custom merchant group ids (see the “Account” -> “Merchant Tagging/Group Administration” page in your affiliate interface if you’ve never used custom merchant tags), or
  • a list of merchant category ids (these ids correspond to the groupings like “Apparel” and “Outdoor/Recreation” that you see in our merchant directory).
• Better support for “interleaving” of merchant results. Interleaving is used when multiple merchants’ datafeeds are searched, to spread the results out evenly between the various merchants. In other words, if you searched merchants A, B, and C, the search results would probably be randomly ordered between the different merchants (e.g. C, C, B, A, A, C, B, B, etc.). Using the “interleave” option coerces the results into a more predictable order so that your results would alternate between each available merchant (e.g. A, B, C, A, B, C, etc.).
• Wildcard searching for small datasets. It’s now possible to specify a search term of % to indicate a wildcard search. This allows you to use the API to retrieve listings of products using all of the other filter criteria available in the module (e.g. department, category, pricing, etc.) in specialized circumstances. The number of products returned from such a search is capped (at 1500 records); if you want full product listings (and better performance) you really should configure a full datafeed subscription that you can download periodically and process locally.

According to some of the feedback we’ve seen already, these changes have made it possible to solve some problems that couldn’t be handled with the ProductSearch API previously. As always we welcome feedback from our affiliates on these changes – it’s that kind of input that helps us drive our offerings forward!

David & AvantLink