Spryker Search

Objective

Search is an integral part of product discovery in e-commerce shops. Quick, relevant, and intuitive e-commerce search is an entry point for
the rest of the customers' experience. It drives such KPIs as conversion, order value, bounce rate, and brand loyalty.

At Spryker, Search is shipped with Elasticsearch as the default search solution. Elasticsearch provides all the basic search functionalities.

Search Types & Functionalities

Spryker Search indexes products and sources the data to bring us various types of search: full-site, multi-language and textual.

Search & Types

1. Full-Site Search includes a few functionalities that make a customer search experience more efficient, e.g. it can predict the ending of
the search phrase, it can suggest products and related pages and other options:

a. Fuzzy Search: Suggests search results that do not precisely match the search request.

 
 Fuzzy Search

A - Search Term

B - Showing products of that actual search

C - Showing products that do not precisely match the search term but could be relevant

b. Auto Completion & Search Suggestions: Helps customers by predicting the rest of a search string and offers a list of matching
options and offers on-the-fly page suggestions for products, categories, or CMS pages.

 Autocomplete

Everything above the search suggestions and the products are part of the “Search Suggestions” and “Auto-complete”
functionality.

c. Did-you-mean Search: Offers typo corrections for the search string.

did-you-mean
  

A - Search Term

B - Did you mean typo correction link

d. Mimic a Dynamic Category Search: It leverages the search URL and uses it as a link within your navigation. It looks like a category
to a user but enables to create more sophisticated categories.

dynamic category

2. In a Multi-Language store the search function automatically checks and adjusts the language a customer has selected. All search
functions, such as auto-complete or suggestions are then applied to the selected language.
3. By default, all content on CMS and Product Pages such as product name, description text, or allocated attributes, is searchable.
Additionally, Product Attributes and can be boosted in the search results.

Also, Synonyms are another way to help users find relevant results. By setting up synonyms, we can expand our users' queries with
variations of a search term. For example, we can define "i-phone" as a synonym for "Iphone". When a user searches for "i-phone" with the
search engine, they will also receive results for "Iphone". This functionality is available in Elasticsearch under project extension
conditions in Spryker.

The search bar drop-down menu consists of suggested products and pages that match a search string.

The Search Data Feed

Search functionality is backed up with a few sources of data. The more structured and ordered data is, the easier it is to manipulate the
search results page. To show matches for a customer's search, the engine indexes and compares the following sources of data: attributes,
products, CMS pages, product reviews, and merchant info. In the Back Office, we can configure only details; the rest is already set up in the
out-of-the-box solution.

The map below represents all the data sources about the products that search engine uses.
 Search Data feed Map

Attributes are one of the primary sources for search. Elasticsearch uses the value of the abstract attribute to find a match which is part
of creating the relative scoring, be it a partial match or a full-text match. The more structured and clean your values are, the better the
search can work. When creating attributes for your products, you need to ensure that the attribute's value (the data) is relevant and precise.

Let’s say we have a product in the store, a Digital Camera, and we have an attribute called DSLR with potential values of either “yes” or
“no”. If someone searches for a "DSLR camera", the site won’t return anything as the values are yes or no. Elasticsearch doesn't know the
attribute name or what it means, so therefore, we probably want to create an attribute of Camera Type with potential values of “DSLR”,
“Compact”, “Film”, etc.

Also, anything from the Product Detail Page that matches the search query can be used in the search functionality. Product Detail
Page (PDP) is a page on a website that describes a particular product or service, including:

Product title and description

Photo gallery
SKU
CTA button
Social proof, including review and ratings

Similar product suggestions

Product brand

Manufacturer
Color
And whatever else we define
To enable all the products details to be searchable, we need to make sure that:

Data and descriptions that we have on our Product Details Pages are relevant and clean.

Keywords that users may use for searching products are presented in product descriptions and titles.
Titles and descriptions are enriched with relevant information that a user may search. For example, instead of having the title of Asus
Laptop, have Asus Laptop with 16GB Ram and 3.5ghz Processor.

If a customer is pasting a specific SKU into a search bar, the better idea is to get them directly to the PDP (Product Detail Page) instead
of a search result page with one product card that they need to click once more.

product detail page

Another text that can appear in the Search is Product Review. Product reviews consist of a summary and description of a customer’s
feedback. If any of the phrases from either summary or description matches the search query, the product will show up on a search
result page.
 product review description & summary

CMS page is an extra HTML page of your Spryker shop. The examples of CMS pages are About Us, Impressum, Terms and Conditions
pages, Blog articles. Similar to Product Detail Pages and Product Reviews, if there is any match with what is written on any CMS pages, it
will pop up in search bar column pages.

Search Preferences in respect to Attributes

As we have stated different sources of data to power the search engine previously, we will now look into the efficient ways to use Attributes
for Search. Attributes are the only configurable data source for Search as others (Product pages, CMS pages, etc.) are already configured
for Search.
 attribute wise search

Holistic View on Product Catalog

It is necessary to keep in mind a comprehensive picture of the catalog, products and interrelations of their Attributes before starting to
decide which ones to activate for search and boosting purposes.

Only knowing exactly what characteristics of specific products are used by customers for finding them and how these characteristics are
similar to other products characteristics will enable us to make the right decisions about manipulating attributes for search.

Since Attributes are shared across the products, we need to be very careful and think about which ones to choose and how this will
affect the search result page of our customer.

Activating all of the Attributes for search is not a solution. It bloats out the search preferences and we could start showing the customer's
wrong products on their searches.

Staying selective to the Attributes for search and understanding the relations of Attributes to different products in our catalog is the first
step to successful manipulating of Attributes for a search engine.

To help make our search more powerful, try capturing the customers' on-site searches to find out what is important to them. This data
will help us enrich our product pages or other searchable content (Attributes as well) to include those essential search terms.

This is where our analytics strategy will come in to collect that data and push it into your analytics tool of choice so we can build and pull reports of our site search performance.

This can be done in multiple ways on a project level (by developers) to integrate our current standing analytics tool or implement the Elasticsearch reporting tool. All of this will help build our search strategy as you
will be able to see our site searches, analyze their performance and shape the search strategy.

Defining Abstract & Concrete Product Attributes

As a recap from the PIM document, a product consists of an Abstract Product and the variants are known as Concrete Products.
Abstract products contain a common set of Attributes for all the variants. The rule of thumb for both Abstract and Concrete Products is to
add only relevant Attributes and enrich them with as descriptive data as possible. Abstract Product Attributes are common for various
products of the same kind.

 abstract & concrete

 
The example below shows that MacBook Pro 13" Abstract Product has Processor, Processor Cores and Display common Attributes for
all the variants that differ only in Internal storage. No matter the variant the Abstract Attributes and their values will constantly stay the
same. The Concrete Product contains more specific Attributes than the Abstract one.

macbook abstract product vs concrete macbook products

 
Now the question arises as to what this means to the search engine and search experience of our customers?

Concrete products do not appear in search, only the Abstract Product Attributes do. However, the Attributes in the concrete
products are still searchable. When any part of the search query matches the value of an Attribute in a concrete product it will still be
returned in the searches but as the Abstract product.

Let's say the customer is looking for a MacBook Pro 512 GB SSD or MacBook Pro black. What do they expect to see on the search
result page? Right, the product card with a black MacBook Pro or the one with 512 GB SSD so they don't need to choose it on a
Product Detail Page. But since both options are Concrete, they will not be shown. There can be one product card for Abstract
MacBook Pro product with, for example, the default silver color or with the setting of 256 GB SSD. How to make it in such a way so
customers get what they expect?

The way around would be to set up different color variants as Abstract products in the Back Office. The other option would be to group
different concrete products which is available under the project extension.

Choosing the Right Attributes for Searches

Having clearly defined abstract and concrete attributes, we move to the step of choosing which attributes to prioritize for search, in other
words what product characteristics matter for customers during their search experience.

Obviously we don't want to choose every attribute for search, this will make every attribute searchable and could bloat out the results
page, we want to be selective. Meaning we could be showing customers products or pages that are not relevant and then could hurt our
core KPIs. Think about what users will actually search for, use data to help come to those conclusions in-order to implement a strong
strategy.

Let’s look at the example of a PlayStation 5. The product can have all this data as Attributes but do all of them need to be included for
Search?

PlayStation 5 with all attributes

Think of potential searches the customers may try to get to the product. For example:

Sony Playstation 5 = contain the Brand and Model Attributes

Sony Playstation 5 with 2 Controllers = contain the Brand, the Model, and the Controllers

Eventually, you can observe further product characteristics in search strings as colors and different hard drive sizes which prompts to
activate Attributes Color and Hard Drive Size to activate.

It is these attributes that are important to the product that will be able to be matched with customer searches that we will want to add to
your search strategy.
We are only looking at one product, but when we do search preferences for the whole site, we have to think on a broader scale of what customers will search for and what will be relevant for them. We have to think
more holistically of the store and what is important across the board

If the weight and physical size may be important for the majority of the products, we would want that to be added to the search.

Play Station 5 with selected attributes

Only those Attributes that are highly likely to pop up in most of the customers' search strings should be included for Search
configuration. We always need ask whether the values of a particular Attribute will help customers to find the product they are looking
for or not.

Playstation 5 is not likely to have a lot of search terms including its weight or physical size. We won't see a search term for “Playstation
5 1.2kg” but would see a search term for “Playstation 5 White” so we want to choose the right attributes to be used in the search
strategy.

Elasticsearch’s ability to weigh in Attribute Values over Attributes themselves

Elasticsearch indexes Attribute Values, not the names of the Attributes themselves. To be more precise it does not make a connection
between the Attributes and the values they contain. So how to make sure that the values of the Attributes fuel the search engine
functionality efficiently?

First, let's recap what are the types of values. Each Attribute contains Value(s), for example, the Attribute Color contains values Blue,
Red, Green, etc. An Attribute can contain different types of values:
Text Value (e.g. Attribute: Color = Values: Blue, Red, Green, etc.; Attribute: Memory Card Slot = Values: Yes, No);
Numerical Value (e.g Attribute: Number of Drawers = Values: 2, 4, 6)
 When it comes to search, best not to choose for Search Preferences those Attributes containing numerical or Yes/No Values. A
search engine does not make a connection between an Attribute and its values. Why is this important and how does it work?

Let’s say you run a camera store and you may have an attribute that is called “batteries included”. It could have a value of Yes / No or it
could have a numerical value of the number of batteries that are included.

A customer searches for "Canon Camera with 2 batteries" but the search engine does not make a connection between the attribute
name and its value.

It can't determine that Value “2” refers to batteries of a particular product, not something else like a number of memory slots.

So the Attribute would be, batteries included:

Attribute: batteries included: Yes

Attribute: batteries included: No

Attribute: batteries included: 2
The solution would be to always aim at matching the values the search terms customers may look for, in other words making them
more descriptive so the search engine can connect them with the product without a correlation with an Attribute.

For example, in our case, we have the number 2 as the Value, but it still could match an Attribute that is completely unrelated to what
they actually want to search for, as a number of memory card slots.

A solution to our example would be to assign to an attribute called “batteries included” a value of “2 batteries”, this means that it would
have a more specific match to what the numerical value refers to. This is why Numerical and Yes/No Values do not work too well for
search engine.
So the idea is to make the values of the Attributes you use for Search more descriptive and precise so they may match the potential
search terms of your customers. As well as choosing the right Attributes for Search Preferences, the other important part is the values
themselves. Therefore, an attribute can have many values, for example, Attribute Color can have Values: blue, red, green, etc, But the
most efficient value's format when it comes to search is going to be the text value.

Boosting Search Preferences

Boosting a search attribute is a very favorable method to influence Product Relevancy Score. Here we will discover what boosting is and
what factors influence the product scoring. We will also define the way Attributes can be boosted in Spryker.

The map below explains how all the parts of Boosting is interrelated.

Boosting Attributes for Search

Once you have set up Search Preferences, you may need some terms or Attributes to become more important than others when searched
for. For example, if you are running a Camera Shop and a customer searches “Canon Camera,” you as a company may deem that the
brand Canon is the most critical aspect of this search. You don’t want to show customers other brands because they are specifically
searching for Canon as the brand. This is where something called Boosting comes into play.

Boosting influences the order of products in a search result by increasing a relevance score for some attributes. Boosting is a way to
define an attribute to be of high importance to us and therefore increase the relevance for the selected product to boost its relevance score.
In Spryker, we can boost specific Attributes of an Abstract Product but not products directly.

Calculating & Setting Relevance Score is the actual way for Products to have priority over others. If a product has an attribute that is
boosted and the value of that attribute matches the search term, then the attribute's score on the relevancy is multiplied, thus providing a
boost to the score. For example, if we have a search term of "Sony Red Digital Camera", it consists of the following Attribute values, as
shown in the picture to the right.

search defined attributes

We may deem as a company that the brand is essential for us too when customers are searching any product under "Sony" search string,
they have Sony products first. Without Boosting Brand Attribute value Sony has 1 point, on the other hand while being chosen for boosting,
the Attribute value gets a multiplier on the relevancy, which by default is by 3 in Spryker. Read the case below to see how the Products
get relevancy scores under different conditions.

Brand and Camera Type Attributes are boosted

Let's take the Sony Red Digital Camera search string, but with the condition of brand and camera type being boosted search
preferences:

1. Sony = 1pt x 3 = 3 points

2. Red = 1 pt = 1 point
3. Digital Camera = 1pt x 3 = 3 points
4. Total = 7 points altogether for a product that has Sony, red and Digital Camera in the search string

Products with relevant Attributes being Boosted

If products had the following in the relevant attributes:

1. Sony, Red, Digital Camera = 7 Points

2. Sony Digital Camera = 6 points

3. Sony Digital Camera = 4 points

4. Sony = 3 points
5. Red = 1 point

6. etc.

Boosting Strategy

We need to be smart with which Attributes should be boosted, because boosting all Attributes will only create noise. Therefore we need to
make a strategy and get the most out of boosting by;

1. Only boost Attributes that will be relevant for users searching. The strategy is based on the big picture of the entire store.
 2. So if managing a camera store, Brand will be an important Attribute, along with Lens Type or Camera Type attributes as these will be
things what the customers are searching for, etc.

3. It is a bad practice to boost all the Attributes.

4. Don't think about individual products. Think more about the broader picture of the catalog. We have been talking about individual
products and how they work, but a Merchant will not have products in isolation to work with.
5. If there is an Attribute assigned to a magnitude of products across the entire store, for example, Weight, boosting this will affect a lot of
products and products that may not be relative. However, weight may be essential if Merchant is a baking supplier, e.g., 4 kg of icing,
etc.
6. All the products that have the same Attribute will be boosted.

7. There is no separation or understanding that this Size Attribute is related to a t-shirt, but this Size Attribute is for a camera. Both
products share the same Attribute.

8. Customers may not need all sizes for a camera or TV, but the Size Attribute becomes relevant for a t-shirt. Think about how boosting
specific Attributes will influence the other products.

In eCommerce, the Search functionality can alone build or break the entire Customer base of a Store, and due to this cruciality, it is very
much required to make the Search, ever so responsive and Customer Oriented. I hope these insights will benefit Upstart Commerce in
making the right choices in improving our search engine that we extend to our Merchants.