Returns the products that are most likely to drive conversion for the given user. Depending on the conversion
metrics you choose when training your Miso Engines in Dojo, this API returns products that are most likely to
optimize those metrics (such as add_to_cart, checkout, or read).
This API considers both user’s interests and the conversion probability. The user’s interests are determined from their past interactions on the site and the context of their current browsing session, including recent trending products, time of the day, recent search behaviors, etc.
The User to Products API is usually used in homepage recommendations, such as “Inspired by your shopping trends” on Amazon, or “Recommended videos” on Youtube. It can also be used to run an email marketing campaign such as a newsletter from Medium with recent articles you might like. These kind of recommendations are particularly powerful in driving product discovery.
For basic usage of this API, you just need to let Miso knows the id of the current user or visitor via user_id
or anonymous_id field. For example, for a currently logged-in user, your request may look like the following:
POST /v1/recommendation/user_to_products
{"user_id": "user-123"}
For a un-signed visitor, your request may look like the following:
POST /v1/recommendation/user_to_products
{"anonymous_id": "visitor-123"}
This API will respond with the recommended products for the specified user or visitor:
{
"message": "success",
"data": {
"took": 37,
"miso_id": "517452b0-0ccf-11eb-948d-66359cf29022",
"products": [
{
"product_id": "tmdb-475557",
"_personalization_score": 0.91
},
{
"product_id": "tmdb-299534",
"_personalization_score": 0.89
},
...
]
}
}
product_id
of the Product is returned. You can ask Miso to return additional fields by using the fl request argument (see example below)You can use the fl request argument to ask Miso to return more product fields. For example, the following request
asks Miso to additionally return the title and category fields of every recommended product:
POST /v1/recommendation/user_to_products
{
"user_id": "user-123",
"fl": ["title", "categories"]
}
The response will be like:
{
"message": "success",
"data": {
"took": 37,
"miso_id": "517452b0-0ccf-11eb-948d-66359cf29022",
"products": [
{
"product_id": "tmdb-475557",
"categories": [
[
"Crime"
],
[
"Thriller"
],
[
"Drama"
]
],
"title": "Joker (2019)",
"_personalization_score": 0.91
},
{
"product_id": "tmdb-299534",
"categories": [
[
"Adventure"
],
[
"Science Fiction"
],
[
"Action"
]
],
"title": "Avengers: Endgame (2019)",
"_personalization_score": 0.89
},
...
]
}
}
Like every other Miso API, User To Products API supports filter query (fq) and boost query (boost_fq) to
generate recommendations that meet your business needs.
You can use filter query to filter recommendation results against
arbitrary criteria, and Miso will guarantee to return sufficient number of recommendation results that meet the
criteria. For example, the following requests will limit the recommendations to only Drama films:
POST /v1/recommendation/user_to_products
{
"user_id": "user-123",
"fl": ["title", "categories"],
"fq": "categories:Drama"
}
For another example with custom_attributes, the following requests will limit the recommendations to
only Drama films after 2010:
POST /v1/recommendation/user_to_products
{
"user_id": "user-123",
"fl": ["title", "categories"],
"fq": "categories:Drama AND custom_attributes.year:[2010 to *]"
}
Miso achieves instant recommendations by pre-computing a large pool of candidates (N>1,000) for each user with the products they are mostly likely to be interested in. However, when the given filter query do not match a sufficient number of candidates, Miso will fall back to Search API to find additional matches to fill in the remaining slots. While falling back to Search API will increase the latency, the latency increase is usually minimum if the same filter query is being used repeatedly due to Miso’s caching mechanism.
You can use boost_fq to boost Products with arbitrary criteria. The relevant Products that match the boost_fq
will be ranked at the top of the recommendations or at the positions specified in the
boost_positions parameter. Boosting is particularly useful for product promotions (e.g. sponsored products) to
highlight the Products you want more impression.
For example, the following request will boost the Sci-Fi films directed by Ridley Scott:
POST /v1/recommendation/user_to_products
{
"user_id": "user-123",
"fl": ["title", "categories"],
"boost_fq": "categories:\"Sci-Fi\" AND custom_attributes.director:\"Ridley Scott\""
}
The response will be like:
{
"message": "success",
"data": {
"took": 83,
"miso_id": "54bf6d9a-dd32-11eb-99d6-a62d401473b5",
"products": [
{
"product_id": "tmdb-286217",
"title": "The Martian (2015)",
"_personalization_score": 0.5364759309088403,
"_boosted": true,
"categories": [
[
"Drama"
],
[
"Adventure"
],
[
"Science Fiction"
]
]
},
...
]
}
}
The additional field products[ ].boosted is a boolean that indicates whether the Product matches the boost_fq.
You can also use boost_positions to specify the positions in the recommendation list you want the
boosted Products to be placed. For example, the following request will place the boosted Product at the second place,
and the third place (the boost_positions are 0-based):
POST /v1/recommendation/user_to_products
{
"user_id": "user-123",
"fl": ["title", "categories"],
"boost_fq": "categories:\"Sci-Fi\" AND custom_attributes.director:\"Ridley Scott\"",
"boost_positions": [1, 2]
}
Typically, the User to Products API is used to let users discover new products they might be interested in. Therefore,
it is important not to recommend products users have already interacted with recently. By default, the User to Products
API filters out the most recent 50 products users have had interactions with (except for impression interactions)
Your secret API key is used to access every Miso API endpoint. You should secure this key and only use it on a backend server. Never leave this key in your client-side JavaScript code. If the private key is compromised, you can revoke it in Dojo and get a new one.
Specify your secret key in the api_key query parameter. For example:
POST /v1/users?api_key=039c501ac8dfcac91c6f05601cee876e1cc07e17Attributes for recommendation boosting
The engine you want to get results from. When you have more than one engine, you can use this parameter to specify the specific engine you want to get results from. If not specified, the default engine will be used.
The user who made the query and for whom Miso will personalize the results. For an anonymous visitor, use anonymous_id instead.
The anonymous visitor who made the query and for whom Miso will personalize the results. Either
user_id or anonymous_id needs to be specified for personalization to work.
The hash of user_id (or anonymous_id) encrypted by your Secret API Key.
user_hash is required to prevent unauthorized API access if you are
making API calls with a Publishable API Key.
You should generate the user_hash via HMAC scheme: you encrypt the desired user_id (or anonymous_id) with your Secret API Key on your backend server, and then let the front-end code send the generated user_hash to Miso APIs to verify the identity of the API caller.
As long as the Secret API Key is kept secret, the user_hash prevents a malicious attacker from making unauthorized API calls or impersonating any of your users.
Miso APIs accept the case-incentive "hex digest" of user hash, a sample Python 3 code to generate it on your backend server is as follow:
import hashlib
import hmac
YOUR_MISO_SECRET_API_KEY = "039c501ac8dfcac91"
key_bytes = YOUR_MISO_SECRET_API_KEY.encode()
user_id = "USER_123" # or anonymous_id
user_id_bytes = user_id.encode()
user_hash = hmac.new(
key_bytes,
user_id_bytes,
hashlib.sha256).hexdigest()
# user_hash is "7eb04da5e..."You can find more examples for other languages in this Github Gist
The user cohort you want to cold-start the recommendation with. For example, the following query will make
recommendations based on the preferences of the users whose country="United States", and gender="Female"
in the User Profile dataset.
{
"user_cohort": {
"country": "United States",
"gender": "Female"
}
}Number of product recommendations to return
The type of products to return. Use this parameter to make the API return only a certain type of products (see Product APIs).
This is particularly useful for sites that have multiple types of products: For example, on a marketplace site, YOu may model merchandise and store as two types of products. You can then use type parameter to limit the recommendation or search results to return only one kind of them.
For instance, the following query will return only store products:
{"type": "store"}For another example, on a travel website, you might have: hotel, thing to do, and restaurant,
three kinds
of products. You can use type parameter to limit results to one kind of them. For instance, the following
query will limit the results to only hotels product:
{"type": "hotel"}Whether to dedupe product based on product_group_id. If dedupe_product_group_id=true,
Miso will prevent products with the same product_group_id from showing multiple
times in the search or recommendation results.
This is particular useful when one product has multiple variants (for example, different sizes, colors, or materials), and you only want to show this product only once in the search or recommendation results. Miso will then return the variant that is most likely to be of the user's interest.
A list of additional interaction records. You can use this fields to simulate user interactions without actually writing them to the interaction dataset.
List of fields to retrieve. For example, the following request retrieves only the title field of each product along
with the product_id, which is always returned.
{"fl": ["title"]}You can also match field names by using * as a wildcard. For example, the query below retrieves the title
and any custom attributes under the attributes dictionary.
{"fl": ["title", "attributes.*"]}The following retrieves all the available fields:
{"fl": ["*"]}For the lowest latency, use an empty array to retrieve just the product_id field (which is the default).
{"fl": []}An array of product_ids of products you want to exclude from search results.
Dictionary of custom context variables for the current browsing session. You can specify context variables
specific to your websites or apps in a {"KEY":VALUE} format, where KEY must be a string, and VALUE can be:
boolstring or an array of stringnumber or an array of numbersarray of objectsnullIn certain cases, Miso will take these variables into account when generating results.
{
"session_variable_1": ["value_1", "value_2"]
}When boosting_tags is given, and there are pre-defined boost rules have the same tag(s),
those boost rules will be matched, regardless if the criteria is met or not.
Useful when want to force trigger specific boost campaign.
["tag-1", "quetag-2"]Defines a query in Solr syntax that can be used to restrict the superset of
products to return, without influencing the overall ranking. fq can enable users to drill down to products
with specific features based on different product attributes
For example, the query below limits the search results to only show products whose size is either M or S and
brand is Nike:
{"fq": "size:(\"M\" OR \"S\") AND brand:\"Nike\""}You can use fq to apply filters against your custom attributes as well. For example, the query below limits the
search results to only products whose designer attribute is Calvin Klein
{"fq": "attributes.designer:\"Calvin Klein\""}fq can also limit search results by numerical range. For example, the following query limits the results to
products that have rating >= 4.
{"fq": "rating:[4 TO *]"}Defines a query in Solr syntax that can be used to boost a subset of products to the top of the ranking, or to
specific boost positions (See boost_positions parameter below.)
For example, the query below will promote all the relevant products whose brand is Nike to the top of
recommendation list:
{
"boost_fq": "brand:\"Nike\""
}For a slightly more complex example, the query below will promote the Nike products which have also been tagged
as ON SALE to the top of the ranking:
{
"boost_fq": "brand:\"Nike\" AND tags:\"ON SALE\""
}It is worth mentioning that, Miso will only boost products that are relevant and have high likelihood to convert, and will not boost a low performance product only because it matches the boosting query.
Depending on your boosting rules, in certain cases, you would like to prevent recommendation results from being too monotone due to boosting. With Miso, you have two tools to do so.
First, you can specify boost_positions to place promoted products at specific positions in the ranking. For
example, the query below will place boosted products only at the first and fourth places in the ranking
(positions are 0-based), and place the remaining products in their original ranking, skipping these two positions.
{
"boost_fq": "brand:\"Nike\" AND tags:\"ON SALE\"",
"boost_positions": [0, 3]
}The second tool is diversification. diversification parameter, on a best-effort basis, will try to
maintain a minimum distance between products that have the same attributes. For example, the following query
will place products made by the same brand apart from each other.
{
"boost_fq": "brand:\"Nike\" AND tags:\"ON SALE\"",
"diversification": {
"brand": {"minimum_distance": 1}
}
}Defines a list of 0-based positions you want to place the boosted products at.
For example, the query below will promote products whose brand is Nike as the top and second recommendations:
{
"boost_fq": "brand:\"Nike\"",
"boost_positions": [0, 1]
}If boost_positions is not specified (which is the default behavior), all the boosted products will be ranked
higher than the rest of the products.
Name of the boosting rule. Use this to identify a boosting rule in _boosted_rules in the response
Define a list of boosting rules that will be applied to the search or recommendation results simultaneously. boost_rules
parameter is particularly useful when you want to boost more than one sets of products, and promote each of them to different
positions. For example, the query below will promote products whose brand is Nike to the top
and second results, and products whose brand is Adidas to the third and fourth results:
{
"boost_rules": [
{
"boost_fq": "brand:\"Nike\"",
"boost_positions": [0, 1]
},
{
"boost_fq": "brand:\"Adidas\"",
"boost_positions": [2, 3]
}
]
}When set, filter result to include only products within certain geographic range from given point will be returned, or to boost product within the same range.
Product should have a field that holds the location of the product, location is used by default,
but other field can also be used.
Distance can be in miles or kilometers. If distance_unit is not set, mile will be used.
For example, to limit results to products within 100 miles of New York city:
{
"geo": {
"filter": [{
"lat": 40.73061,
"lon": -73.93524,
"distance": 100
}]
}
}To boost products within 2 kilometers around Alcatraz Island according to loc field:
{
"geo": {
"boost": [{
"field": "loc",
"lat": 37.82667,
"lon": -122.42278,
"distance": 2,
"distance_unit": "km"
}]
}
}Defines diversification rules to prevent products with the same attributes (e.g. sneakers made by the same brand or books from the same authors) from showing up too close to each other in the results.
For instance, customers who have purchased many of sneakers from Nike may happen to have recommendations or search results where all top-5 entries are sneakers made by Nike. Purely considering accuracy, these recommendations appear excellent since the user clearly appreciates Nike sneakers. However, such results might be considered too "plain" by the user, owing to its lack of diversity.
diversification parameter allows you to avoid this problem by enforcing a desired minimum distance between
products. For example, consider a list of four products whose brand are Nike, Nike, Adidas, and PUMA
respectively. The query below will make sure there are at least one different product between two Nike
products, e.g. the diversified ranking may become Nike, Adidas, Nike, and PUMA :
{
"diversification": {"brand": {"minimum_distance": 1}}
}You can also increase the minimum_distance to place products further apart. For example, the following query will make sure, for the two Nike products, there are at least two other products between them. As a result, the diversified ranking may become Nike, Adidas, PUMA, and Nike.:
{
"diversification": {"brand": {"minimum_distance": 2}}
}The diversification algorithm reranks the products on a best-effort basis. For example, for the product list
described earlier, it is not possible to place two Nike product three places apart from each other. Therefore,
the diversified ranking will still remain Nike, Adidas, PUMA, and Nike* even if we set minimum_distance=3.
Dithering is an optional parameter (>= 1.0, and typically <= 5.0) in the recommendation APIs that introduces randomness to the order of recommended items. By adding noise to the original ranking, it shuffles the list, surfacing lower-ranked items to enhance list freshness and potentially boost user engagement. However, excessive dithering may reduce the accuracy of item ordering. See this blog post for more information.
x >= 1A unique identifier to enable pagination in Recommendation APIs. By default, Recommendation APIs do not support
pagination because the results from Miso, by its natural, will change in real-time with new user interactions.
pagination_id allows you to implement pagination more easily by memorize what products we have
returned to the current user with the same pagination_id.
To enable pagination, you generate a pagination_id and set it in the first and subsequent requests in the same browsing session
where you want to enable pagination. With pagination_id set, you can access recommendations
in different pages using the combination of start and rows parameters, and Miso will ensure that no duplicated
recommendation will be returned in different pages.
For example, assuming you are implementing an infinite scroll with Miso Recommendation APIs. Before you make the first request,
you generate a pagination_id using the current datetime or uuid like the following:
// current datetime
var my_pagination_id = Date.now().toString()
// OR uuid
const uuidv4 = require("uuid/v4")
var my_pagination_id = uuidv4()You can then request the first page of results with my_pagination_id like the following:
{
"pagination_id": my_pagination_id,
"start": 0,
"rows": 10
}Then, you can request the next page of results with the same my_pagination_id, and Miso will ensure
that no duplicated result is returned:
{
"pagination_id": my_pagination_id,
"start": 10,
"rows": 10
}Note that, a pagination_id will timeout if there is no further request associated with it for 30 minutes.
Also, pagination_id is scoped by individual users: i.e. different users' results will not be affected
even if they use the same pagination_id.
512The start of the page you want to access. Combine this with rows to implement pagination. You can only set it when pagination_id is given.