Unbxd FAQ
If you have ever shopped on Express, Ashley, or WorldofBooks, you might have already used Unbxd. Anytime you reach out to eCommerce stores to buy your favorite dress or electronics, you go through an intricate search process running behind. The search process is designed well to let you hover the products in milliseconds. Unbxd is the backbone that runs behind the site to ensure relevant and quick display of products.
We have integrated our search functionalities for small-scale companies as well as the large ones.
Unbxd also offers a platform-agnostic approach to integrate search using any of the available platforms like Shopify, Hybris, or Magento.
Check out our customer stories to know more about us.
The CCPA guidelines applied to businesses that collect a consumer’s personal data. The CCPA policy doesn’t apply to our products as our products do not collect personal data (email ID, username, phone number etc.) of the consumers.
The CCPA will not apply if the all the following conditions are true:
– User credentials for your website are not available to Unbxd products
– Unbxd products have no way of obtaining any personal information (e.g. username, email, etc.) while the user is searching/browsing the customer websites
– Unbxd doesn’t have a way of correlating the cookie id or IP address with user personal information (e.g. username, email, etc.)
Yes, Unbxd supports TLS 1.3 which uses 256-bit keys. The TLS support should be enforced by the customers on their browsers.
Unbxd products support omni-channel use cases where the price and availability of the product varies depending upon the location.
There are two approaches to handle price/availability information depending upon region :
- Option 1 : Suitable when the number of regions are less than 50 (cases where the price/availability varies by states or country)
- The price/availability information for each region can be passed as separate fields in the catalog
- At the time of query time, use the location of the user to filter the price/availability
- Option 2 : Suitable when the number of regions are more than 50 (cases where price varies with zip-codes)
- The recommended approach in these cases is to use Unbxd APIs to get the list of product IDs, then request price/availability of the products using another function while rendering the UI
Catalog
Unbxd supports catalog in CSV, JSON and XML formats.
The schema should be uploaded separately in JSON format prior to uploading the catalog in CSV or XML format. The uploads in CSV and XML via SFTP are converted to JSON format by Unbxd and then uploaded via the feed API.
Unbxd systems are designed to handle extremely large catalog sizes. However, large catalogs require certain custom optimizations to offer the best results.
Unbxd feed system has supported feed files meeting following specifications in the past:
- File size : 50GB+
- Product SKUs : 150Mn+
- Fields per product : 25000+
- Variants per product : 5000+
Schema file uploads are handled on Unbxd end in the following manner :
- If the new schema file has fields that already existed in the schema but values corresponding to them are modified, then the schema is updated with the modified values of the field
- If the new schema file has new fields, then the new fields are added to the previously existing schema
No, currently there is no mechanism to delete a field from the schema. However, presence of deprecated fields in the schema doesn’t affect the search results anyway.
Deletion of a field from the schema can lead to corruption of the search & category index resulting in downtimes. Unbxd team can delete the deprecated fields from the schema from the backend if it’s extremely necessary. However, these requests can take some time.
Yes. The Autosuggest parameter is marked as ‘Required’. It is mandatory to specify the Autosuggest parameter in the schema file for all the fields. These are the mandatory and optional parameters:
- fieldname (required)
- datatype (required)
- multiValue (required)
- Autosuggest (required)
- isVariant (Optional)
- id (Optional)
Unbxd supports three types of feed uploads:
- Full Feed Upload: When you upload your entire catalog. *(Recommended frequency is once a day)
- Delta Upload: When you want to upload only a few modified fields (like price changes, or color additions) of your catalog, use delta feed upload.
- Single Feed Upload: When you want to update a single attribute of your feed, use single feed upload.
Yes. We only support JSON via feed API. Also, XML and CSV via SFTP won’t be self serve. Unbxd will anyway need to transform these files to JSON, and then call our feed API internally. Eventually, everything needs to pass via the feed API.
Variants are properties of a product with different values. Suppose, a product is available in five different colors then that means the product has five different variants.
To integrate variant functionality we have to set variants=true (to enable variants).
Our Search API returns parent products with variants, and never just the variants. Some of the variant properties are:
- By using variants.count, we can define how many variants of a product need to be returned.
- We also have a predefined attribute (relevantDoc) in our API response that informs the customer if the parent product should be displayed or variant – given we send both back in the response.
Ranking
Unbxd offers different types of query suggestions in autosuggest. The ranking logic for the query suggestions of different type is mentioned below :
- Keyword suggestion : These suggestions are ranked based on click through rates (CTR observed on the suggestion in the last one month), frequency of suggestion in catalog and the length of the suggestion.
- In-field suggestion (scope suggestion) : These suggestions are ranked based on click through rates (CTR observed on the suggestion in the last one month), frequency of suggestion in catalog and the length of the suggestion.
- Popular products : The ranking for popular products based on popularity scores that is generated based on the clicks, cart addition and orders data received for all products in the last 30 days. The popularity scores are refreshed once a day.
- Promoted suggestion : Promoted suggestions relevant to the query are shown without any specific ranking criteria
- Top query : The ranking of top query is based on number of clicks received on the query suggestion in last 15 days
The ranking of in-field suggestions is based on the analytics data received by Unbxd. Unbxd doesn’t allow the customer to define customer ranking logic for autosuggest. However, our team is working on exposing controls for the autosuggest ranking.
Yes, you can remove query suggestions from auto-suggest by adding them in Blacklisted suggestions.
Check the process of defining blacklisted selection here.
In order to support selection of more than one values in facets the following changes should be made :
- Filter parameter changes : The filter parameter in the search API supports more than one value separated by an OR operator. If the shopper selects more than one value in a facet then the payload for the filter parameter should be specified in the following manner : filter=:”” OR :”:”.
- Add Facet.multiselect parameter : Set facet.multiselect=true in the search request to ensure that the remaining values in the facet are retained along with the product count associated with them. By default, facet.multiselect is false, which leads to removal of remaining values from the facet once one value is selected.
The option to select multiple values in a facet is available only for ‘Range’ and ‘Text’ facets. Multi-level facets do not support selection of more than one value.
- First step is adding facet to the global facet pool – It can be done in the console by browsing to
Manage > Configure site > Configure Facet
- Second step is enabling the facets from site-rule – This can be done in the console by going to
Merchandising > Commerce search > Site Rule
. In site rule, click onView Site Rule
, then clickNext
to reach the facets screen. Enable the facet that you want to display on the site and click onSave
.Publish
the site rule to store the changes.
You can build a hierarchy in your facet values to enable multi-level navigation and filtering. This pattern is great for very long lists of values and to improve discoverability: your users will be able to browse up and down in the levels to refine their searches. Using multilevel faceting, we can view number of products present in each category and apply these filter directly to narrow down our search.
To enable, the dataType of these fields should be set as “path”. Hierarchical facets can be configured only on “path” fields.
A sample request to check: https://search.unbxd.io/API Key/Site Key/search?&q=*&rows=40&start=0&version=V2&format=json&variants=true&filter=category_path:%22Apparel%22&filter=color:%22Black%22&facet.multiselect=true
Returning a higher number of facets hurts performance of your search and adds a few extra milliseconds to your response time. In general, it is recommended to show 10-15 most relevant facets on a search results page (SRP) to help shoppers discover and use filters effectively without too much cognitive load on the shoppers. However, if your business demands showing a higher number of facets on the SRP and you don’t want to sacrifice on the performance then we have a solution for you.
Solution 1 : Using Multi-valued field
Step 1: Combine individual facet fields into a single multi-valued fields. Let us assume that you want to create facets on the following fields :
- Availability which has value “Yes” & “No”
- Gender which has value “Male” & “Female”
- Size which has the unique values “S” , “M” , “L” , “XL”
- Add a new multi-valued field in the catalog called Facet_group_1 where the key & value pair of the fields are stored.
Sample feed before transformation :{"add": [{"Availability": "Yes","Gender": "Male","Size": "L","UniqueId" : "1"},{"Availability": "No","Gender": "Female","Size": "S","UniqueId" : "2"}]}{ "add": [ { "Availability": "Yes", "Gender": "Male", "Size": "L", "UniqueId" : "1" }, { "Availability": "No", "Gender": "Female", "Size": "S", "UniqueId" : "2" } ] }{ "add": [ { "Availability": "Yes", "Gender": "Male", "Size": "L", "UniqueId" : "1" }, { "Availability": "No", "Gender": "Female", "Size": "S", "UniqueId" : "2" } ] }
Sample feed after transformation{"add": [{"Availability": "Yes","Gender": "Male","Size": "L","UniqueId" : "1","Facet_group_1" : ["Availability|Yes","Gender|Male", "Size|L"]},{"Availability": "No","Gender": "Female","Size": "S","UniqueId" : "2","Facet_group_1" : ["Availability|No","Gender|Female", "Size|S"]}]}{ "add": [ { "Availability": "Yes", "Gender": "Male", "Size": "L", "UniqueId" : "1", "Facet_group_1" : ["Availability|Yes","Gender|Male", "Size|L"] }, { "Availability": "No", "Gender": "Female", "Size": "S", "UniqueId" : "2", "Facet_group_1" : ["Availability|No","Gender|Female", "Size|S"] } ] }{ "add": [ { "Availability": "Yes", "Gender": "Male", "Size": "L", "UniqueId" : "1", "Facet_group_1" : ["Availability|Yes","Gender|Male", "Size|L"] }, { "Availability": "No", "Gender": "Female", "Size": "S", "UniqueId" : "2", "Facet_group_1" : ["Availability|No","Gender|Female", "Size|S"] } ] }
- Step 2: Create a facet on the field Facet_group_1 instead of creating a facet on individual attributes Availability, Gender, and Size. The facet response for Facet_group_1 is going to have the following format :
{"facetName": "Facet_group_1","filterField": "Facet_group_1","values": ["Availability|Yes", 50,"Availability|No", 50,"Gender|Male", 40,"Gender|Female", 60,"Size|L", 20,"Size|S", 30,"Size|XL", 40,"Size|M", 10,],"displayName": "Facet Group 1","position": 1}{ "facetName": "Facet_group_1", "filterField": "Facet_group_1", "values": [ "Availability|Yes", 50, "Availability|No", 50, "Gender|Male", 40, "Gender|Female", 60, "Size|L", 20, "Size|S", 30, "Size|XL", 40, "Size|M", 10, ], "displayName": "Facet Group 1", "position": 1 }
{ "facetName": "Facet_group_1", "filterField": "Facet_group_1", "values": [ "Availability|Yes", 50, "Availability|No", 50, "Gender|Male", 40, "Gender|Female", 60, "Size|L", 20, "Size|S", 30, "Size|XL", 40, "Size|M", 10, ], "displayName": "Facet Group 1", "position": 1 }
- Step 3: Parse the facet response to get back values for the individual facet on the front end.
Iterate through the values returned for Facet_group_1 to separate the key-value pairs and group the pairs having the same name to generate facets for the original attributes- Availability
- Yes – 50
- No – 50
- Gender
- Female – 60
- Male – 40
- Size
- XL – 40
- S – 30
- M – 10
- L – 20
- Availability
Note :
- The display name for facets has to be decided at the time of the feed change step (i.e. step 1).
- The position, display name, and sorting of facet values cannot be configured from the console.
This approach is not recommended for Range facets (e.g. facets created on price).
Solution 2: Using Multi-level facets for grouping facets
There are occasions where you may have different ways of classifying a product based on the same property.
For example, the Size of a fashion product can be defined in the following ways :
- Size_1: “Regular” or “Petite” or “Plus”
- Size_2: “S” or “M” or “L”
In these situations, you can use multilevel facets to help shoppers narrow down to the right product quickly without introducing a lot of facets. You can achieve this by following the following steps.
- Step 1: Combine the individual facet fields into a single path type field called Size_group
Feed before transformation{"add": [{"Size_1": "Regular","Size_2": "L","UniqueId" : "1"},{"Size_1": "Petite","Size_2": "S","UniqueId" : "2"}]}{ "add": [ { "Size_1": "Regular", "Size_2": "L", "UniqueId" : "1" }, { "Size_1": "Petite", "Size_2": "S", "UniqueId" : "2" } ] }{ "add": [ { "Size_1": "Regular", "Size_2": "L", "UniqueId" : "1" }, { "Size_1": "Petite", "Size_2": "S", "UniqueId" : "2" } ] }
Feed after transformation{"add": [{"Size_1": "Regular","Size_2": "L","UniqueId" : "1","Size_group" : "Regular > L"},{"Size_1": "Petite","Size_2": "S","UniqueId" : "2","Size_group" : "Petite > S"}]}{ "add": [ { "Size_1": "Regular", "Size_2": "L", "UniqueId" : "1", "Size_group" : "Regular > L" }, { "Size_1": "Petite", "Size_2": "S", "UniqueId" : "2", "Size_group" : "Petite > S" } ] }{ "add": [ { "Size_1": "Regular", "Size_2": "L", "UniqueId" : "1", "Size_group" : "Regular > L" }, { "Size_1": "Petite", "Size_2": "S", "UniqueId" : "2", "Size_group" : "Petite > S" } ] }
- Step 2: Create a facet on the field Size_group instead of creating a facet on individual attributes Size_1 and Size_2. Handle the response of the Size_group multilevel facet to display the facet. The facet response will look like:
"facets": {"multilevel": {"bucket": [{"values": ["Regular",30,"Petite",50,"Plus",20],"position": 0,"filterParam": "Size_group1_fq","level": 1,"multiLevelField": "Size_group"}],"breadcrumb": {}}}"facets": { "multilevel": { "bucket": [ { "values": [ "Regular", 30, "Petite", 50, "Plus", 20 ], "position": 0, "filterParam": "Size_group1_fq", "level": 1, "multiLevelField": "Size_group" } ], "breadcrumb": {} } }
"facets": { "multilevel": { "bucket": [ { "values": [ "Regular", 30, "Petite", 50, "Plus", 20 ], "position": 0, "filterParam": "Size_group1_fq", "level": 1, "multiLevelField": "Size_group" } ], "breadcrumb": {} } }
- Once the shopper selects the “Regular” option, then they will get an option to select amongst the options in Size_2.
facets": {"multilevel": {"bucket": [{"values": ["S",10,"M",10 ,"L",5,"XL",5],"position": 0,"displayName": "Size_group","filterParam": "Size_group2_fq","level": 2,"multiLevelField": "Size_group"}],"breadcrumb": {"filterField": "Size_group","values": [{"value": "Regular"}],"level": 1}facets": { "multilevel": { "bucket": [ { "values": ["S",10,"M",10 ,"L",5,"XL",5], "position": 0, "displayName": "Size_group", "filterParam": "Size_group2_fq", "level": 2, "multiLevelField": "Size_group" } ], "breadcrumb": { "filterField": "Size_group", "values": [ { "value": "Regular" } ], "level": 1 }
facets": { "multilevel": { "bucket": [ { "values": ["S",10,"M",10 ,"L",5,"XL",5], "position": 0, "displayName": "Size_group", "filterParam": "Size_group2_fq", "level": 2, "multiLevelField": "Size_group" } ], "breadcrumb": { "filterField": "Size_group", "values": [ { "value": "Regular" } ], "level": 1 }
Note: The shopper will get an option to select only 1 value at each level.
‘Did you mean’ gets fired when ‘Spellcheck’ is triggered.
For e.g. if the search query is ‘ret dress’ with this API call: http://search.unbxd.io/8c1bc6cc0fa47076d417690a1e5e1120/test-childrensplace-com702771523873394/search?q=ret%20dress
then the result set has 456 products. There is a ‘didyoumean’ suggestion ‘set dress’, as there was a spell-check triggered for token ‘ret’ based on the nearest match found from the catalog.
Process is to first check for exact match results. In case no results are found, then spellcheck is triggered and ‘did you mean’ suggestion is given (if found, also note that ‘didyoumean’ suggestion is not automatically fired). Product results are for alternate.mm=0, in this case for dress. This happens mostly in case of multi token queries where one or more words may have been incorrectly spelled.
Synonyms tell the engine which words or expressions should be treated equal. Just like ‘slippers’ can also be called ‘Flip-slops’. For such queries, we create synonyms to avoid any zero results.
But when queries have anything other than that, like a misspelled query or a special character in the query, then it is handled differently.
For misspelled queries, ‘Did you Mean’ is triggered while for special characters ‘stemming’ is triggered. Stemming allows to cut that character and search the catalog for products without it in the query.
No, we don’t support slotting on site rules. You have to specify slots for every query rule/page rule.
Yes, we can.
First is if a customer wants to boost products using the variant fields: As in, boost the products but the logic will be coming from a variant field. For e.g., if the price is a variant field, and the customer wants all products with price>$50 to be boosted. Then all products (which have any variant with price>$50) will be boosted.
Second is if a customer wants to boost variants within a product, and the image of the variant becomes the face of the product: In this case, for e.g., if a customer applies a boost on color field = red then, all products in the result set which have a red color variant – that image will become the face for them.
The redirect feature in Unbxd search API supports both the relative and absolute paths. However, if a relative URL is specified in a redirect rule then the customers must take care of adding the prefix for the URL before requesting the page pointed by the URL.
Customers can also create some redirect rules with relative URLs and some redirect rules with absolute path, as long as they have logic in place to handle the response of both types.
If it’s Ajax implementation by Unbxd, then we handle the redirects in our JS code after verifying the logic with the customer.
In the Merchandising section, you can configure various product settings. You can boost a set of products or arrange them in a specific order on the site.
You can apply merchandising rules for delivering personalized results to your shoppers.
But whenever there is any Pin or Slot configured in merchandising for a given query then, the personalization algorithm is not used.
Redirect will not get triggered for miss-spelled queries (i.e. if the query does not match with the one specified in the rule). Summarizing the behavior in case of fallback
A – Correct query -> Redirect gets triggered. http://search.unbxd.io/c28b3b5ae91e7b48bf78825e7b63b483/globalindustrial-com702401520254089/search?q=gloves&rows=0&variants=true&analytics=false&facet=false
Case B – Miss-spelled query -> Redirect is not triggered. DYM received. http://search.unbxd.io/c28b3b5ae91e7b48bf78825e7b63b483/globalindustrial-com702401520254089/search?q=glovas&rows=0&variants=true&analytics=false&facet=false
Case C – Miss-spelled query -> Fallback is set as true here so it automatically falls back to DYM which invokes the redirect. http://search.unbxd.io/c28b3b5ae91e7b48bf78825e7b63b483/globalindustrial-com702401520254089/search?q=glovas&rows=0&variants=true&analytics=false&facet=false&fallback=true (edited)
Unbxd Analytics captures every site activity under different sections like Views (the number of time shoppers viewed a product), clicks (the number of time shoppers clicked a product), carts (the number of time shoppers added a product to the cart), and orders (the number of time shoppers ordered a product).
But capturing a few events like Orders depends on others. So, if the analytics does not integrate clicks or carts event then we would not be able to capture orders, hence the orders shown in the Unbxd console may not match other analytics sources or could account for zero.
Pinning and Slotting cannot happen beyond the 50th Position. A customer can pin up to 50 products.
The max limit to add filter groups in the console is 50.
- Did this answer your question?