Evolving Search for Product Availability

From Location-based to Customer-based Shopping

At Empathy we have brought our APIs closer to the real needs of shoppers during exceptional situations, providing tools that help customers find exactly what they are looking for, with versatility under circumstances both myriad and whimsical.

One of the consequences of the current “situation” is the need to make purchasing options as flexible as possible during a global pandemic. To this end, we have evolved our product search service for different places and multiple delivery options.


Before the pandemic, online shopping was a growing but optional part of many people’s lives. The effect of Covid-19 and its restrictions has been centripetal: like a whirlpool, attracting an influx of shoppers.

Quarantine, shop closures and fear of contracting the coronavirus have prevented consumers from shopping in stores. This has prompted retailers to seek different, centrifugal forms of outbound delivery that reduce or eliminate customer contact:

  • Purchase in a brick-and-mortar shop
  • Pickup with reduced store contact
  • Home delivery from warehouse
  • Home delivery from shop

Empathy’s search service already supports these different types of purchase, however, we can further refine that search experience.

Current situation

Until now, in the case where the customer explicitly provided his address, the search service fixed him by means of this location at a specific shop and offered them the products available. But certain products might not be available at that time, or they might be available in-store but not for pickup or local delivery. In this context, the user might then have to search for the product by manually selecting a different store location.

This is a real-world limitation that confronted us, and we wanted to overcome it.

Improving the service

What if we provided the user with the ability to purchase products in multiple shop locations at the same time?

Instead of offering only the products available from one pre-selected shop, we would make products available from several stores near the customer.

Let’s imagine a user who wants to buy a toy for Christmas. He is remotely working at home, so he is interested in having it sent to him, either from a shop or a warehouse. Perhaps it is available in the nearest store — but only by buying it on site, in person. By enabling search in several shops at the same time, we offer this user the product they want for home delivery from another nearby shop, without having to search again.

In order to offer this improvement in service, we had to make some changes.

On the one hand, we modified the way in which the search engine product information is indexed. Until now, we separated the products into different ElasticSearch indexes according to the shop where they were available:


Each of the products contained information about the types of purchases available in that shop:

      "id": "1",
      "name": "Star Wars The Child Animatronic"
      "description": "Star Wars Baby Yoda The Child Animatronic toy",
	  "image": "www.toystore.com/8602561387129",
      "inStore": "true",
      "pickup": "true",
      "homeDelivery": "true",
      "shipToHome": "false",
      "store": "storeA"

To facilitate searching in multiple locations simultaneously, we need to have a single index, in which each product will contain all the locations in which it is available.


In this index we must index each product only once, and specify for which shop each of the purchase modes is available:

      "id": "1",
      "name": "Star Wars The Child Animatronic"
      "image": "www.toystore.com/8602561387129",
      "description": "Star Wars Baby Yoda The Child Animatronic toy",
      "inStore": ["storeA","storeB","storeC"],
      "pickup": ["storeA","storeB","storeC"],
      "homeDelivery": ["storeA"],
      "shipToHome": ["storeA","storeB"],
      "store": "storeA"

On the other hand, we also need to make changes to the search API.

Until now, the service used a single shop location passed as a parameter to make the search request.

curl http://localhost:8080/query/toystore/search?query=baby%20yoda&lang=en&store=storeA&rows=4&start=0

By means of the “store” parameter, the service identified the index in which to make the query and returned the results for that query.

However, what we want is to be able to search in several locations at the same time on the new unique index. Therefore, we have modified this service to be able to accept a list of locations in the header, and use each and every one of them to filter the results.

curl -H 'location-object:[{"modality":{"type":"IN_STORE"},"sources":[{"storeId":"storeA"}]},{"modality":{"type":"SHIP"},"sources":[{"storeId":"storeA"},{"storeId":"storeB"}]},{"modality":{"type":"DELIVERY"},"sources":[{"storeId":"storeB"}]},{"modality":{"type":"PICKUP"},"sources":[{"storeId":"storeC"}]}]' http://localhost:8080/query/toystore/search?query=baby%20yoda&lang=en&rows=4&start=0

What are the benefits of these changes?

  • Reduced duplication: Several locations share the same product, not redundant copies of that product.
  • Reduced customer search time
  • Easier regional product search, filtered for the desired delivery mode


The multi-location search service provides a faster and smoother customer experience, making available different purchase methods to suit customer needs and the circumstances of the moment. By empathizing with the customer, the difficulties of shopping under exceptional conditions today are transformed into breezy shopping both now and in the future.