March 30th, 2020
It's been almost a year since we first unveiled our fancy new Elasticsearch-powered Premium Search for products. In that time we've transitioned everyone gradually (in order to deal with potentially breaking behavioral differences), seen some great implementations of new features like facets, made lots of tweaks to improve performance and scalability, and gotten a lot of good feedback. We've also been moving forward on some new features in this area, which I'll highlight here.
Premium Search is no longer just for "me". Bad jokes aside, this means that the same "engine" that powers
v1/me/products (for building the buyer experience) will also serve
v1/products so that the product admin experience can take advantage of the same features. Detailing these features point by point would be a bit redundant with the original blog post on Premium Search, so instead I'd encourage you to review that post carefully to understand what this means for the admin side.
Like we did with the "me" endpoint, we're rolling out the admin side gradually, but on a more aggressive schedule, since the engine itself is already battle-hardened and proven to scale well. Here is our rollout plan:
* With Premium Search, all xp fields are searchable/sortable/filterable automaticlaly, so there is no need for explicit indexes.
As with the "me" endpoints, there are no breaking changes from an API specification standpoint. But if there's one behavioral aspect you need to be particularly aware of and proactive about, it's this:
GETs will be serving cached data, which by its nature has the potential of being stale. If you do any sort of write operation (
PATCH), the model returned in the response is guaranteed to be fresh and consistent. But if you immediately follow a write with a
GET, you may get back stale data. Hopefully understanding the nature of this will help you avoid potential bugs, but we encourage everyone to proactively check their code to determine if this might affect them. (Recall that all orgs created after 2/12/2020 are already enabled, so nothing to do in this case.)
One piece of critical feedback we're heard a few times (okay, I'll call it a complaint) is that searches are simply returning too many results in many cases. We have certainly erred on that side intentionally, and we've found ranking of search results, which we consider much more important, to be working extremely well. Still, we understand the desire to tighten the reins on the sheer volume of results in some cases, and we're rolling out the new
searchType query parameter to help achieve this. Here are the possible values:
AnyTerm- Default. Any word in the search phrase must appear in any of the fields being searched on.
AllTermsAnyField- All words in the search phrase must appear somewhere in any of the fields being searched on.
AllTermsSameField- All words in the search phrase must appear in the same field, of those being searched on.
ExactPhrase- The phrase must appear exactly as typed (case insensitive) in any field being searched on.
ExactPhrase, except the last word in the search phrase can be incomplete. This is ideal for powering type-ahead lookups.
searchType parameter is available on
v1/me/products today. In the coming days we'll be releasing updates to our SDKs with direct support for the new parameter.
Although we encourage you to use these features when appropriate, we'd still caution you to err on the side of too many results. Remember that ranking works the same in all cases. That is, exact phrase matches will rank ahead of individual terms, more term matches will rank ahead of fewer, matches on
Name will rank ahead of matches on
Description, etc. Think about searching for something on Google or Amazon: are you likely to go to page 20 of the results if you found what you're looking for on page 1? The flip side of too many results is too few, and you don't want to unintentionally prevent users from finding what they're looking for.