When you need to explicitly send an event to Nosto to tell it that the user has viewed a certain product, you must do so manually. A need for something like this arises when your website has a quick-view function on the category or search pages that enables the customer to preview the product in an overlay without actually navigating to the product page.
Note: The example above creates a new request, adds view product event for product-id-101 and sends the event to Nosto. Since the request did not specify any recommendation slots, this request only submits view event to Nosto.
You can either create an empty request as in the above example and add only the wanted parts to it, or you can create a request based on the tagging on the page by using the includeTagging field and then modify it. Here is an example that creates a request using the tagging on the page and then overrides the current tag to be custom colour to update the recommendation with id productpage-nosto-2 to show only products with the same colour:
In addition to the filtering by product tags, you're also able to filter using product attributes. Here is an example that creates a request using the tagging on the page and then overrides the current tag to be custom colour red, to update the recommendation with id productpage-nosto-3 and to show only cotton material products for men of the same colour (red):
In many cases leveraging the existing tagging on the page and then overriding the specific parts is simpler and more robust.
In case the request is built completely manually, it needs to include also the attribution information for click tracking. Below is an example which shows how that can be done for product views that result from clicking on a Nosto recommendation slot.
In the event that the product was viewed due to a click on a Nosto recommendation slot, you must send an additional parameter that denotes the identifier of the recommendation slot that was clicked. If this is done inside of recommendation template identifier of recommendation slot can be get from property $!product.attributionKey
Note: Failure to do will result in incorrect attribution statistics.
Optional event that can be sent to signal that a specific product variant (SKU in Nosto terms) is being viewed. Typical use case for sending this event would be from product detail page when the user selects a product variant, such as some specific color and/or size. The recommendations can then be configured to update and give preference for products that have similar variants available. For example "Other products also available in the same size".
When you need to reload the recommendations on the page, you can use this call to reload the recommendations:
The call accepts an optional parameter, but in most cases, that parameter is not required. Add the optional parameter only if the reason to reload new recommendations is the result of clicking an existing recommendation and some new product was loaded. A typical use case where this would be the case is when a recommendation has a quick view button that dynamically loads a new product into a CSS overlay with ajax.
Conditional loading
By default, Nosto loads the recommendations as soon as the site’s DOM is loaded. In some use cases, Nosto needs to be loaded manually. This is done by disabling autoload directly after the nosto script:
and conditionally later to trigger loading
This pattern should not be used to load Nosto faster, but as a pattern to conditionally load Nosto. If api.load() is called before this site's DOM is loaded tagging data won't be fully available and Nosto will not function correctly.
In this article, you will learn to use certain tags and fields to dynamically filter and facet your recommendation results.
You can use any combination of the different filtering mechanisms outlined below. For example, you can use category and the tag filtering to constrain the recommendation results.
Note: In order to leverage dynamic filtering please read our guide on configuring the filtering behaviour.
All category pages already leverage dynamic filtering. As documented in our guide to tagging categories, the nosto_category tagging constraints Nosto to show recommendations from only the current category.
Tagging the current category is often for most retailers to add personalization to the category pages. If your store uses faceting and you would like Nosto to respect the faceting constraints, you may need to use either the attribute or tag filtering mechanisms to achieve the desired result.
You can filter by categories to narrow down the recommendation results to only show products from the specified category or categories. If multiple categories are specified, the products must be in each of those categories.
You can even use multiple
Note: Remember to tag the categories exactly as they are tagged in your product pages. If you've omitted the leading /Home from your category tagging on the product pages, you'll need to tag them in a similar format here.
You can filter by tags to narrow down the recommendation results to only show products containing the specified tag or tags. If multiple tags are specified, the products must contain all the specified tags.
You can even use multiple
You can filter by attributes to narrow down the recommendation results to only show products containing the specified attributes. If multiple attributes are specified, the products must contain all the attributes.
You can even use multiple
These colon separated values are then parsed into an object with format { "key1":"value1,value2", "key2":"value1" }.
The above method will receive references to all the "nosto_custom_field" elements. It extracts the colon separated strings and parses them to an object. For e.g. the above gender and material custom fields will be parsed to
If you want to refresh the recommendations with new facet constraints, the simplest way would be to update the value of the filters in the page and then reload the recommendations.
The following example illustrates a simple way of modifying the current category tagging and then using the JS API to reload the recommendations.
Usually adding an Add to cart button directly into the recommendation which lists multiple products is fairly straightforward, the website just needs to have an appropriate javascript function to do the operation. Nosto provides ready-made functions for multiple platforms so check the Nosto documentation specific to your e-commerce platform or if needed look into your e-commerce platform's documentation and support on how to create such a function.
Once the Add to cart button is pressed it should call that function to add the products to the cart, but it should also additionally let Nosto know that the button was pressed so Nosto can track the sales from the recommendation. When using the JS API this attribution can be done with the recommendedProductsAddedToCart-function as follows:
⚠️ The api call is only for informing Nosto about the attribution (that the product was added from the recommendation), normal cart tagging should be used to tell Nosto the user’s cart contents.
The JS API can be used to register callbacks to hook into the recommendation events. To register a listener for a callback, use api.listen(callbackId, callbackFunction) function.
Called when Nosto has responded and finished recommendation placement.
filledElements
Array
Contains a list of recommendation slots that contain recommendations
unFilledElements
Array
Contains a list of recommendations slots that did not have get recommendations.
Called when Nosto has responded but not yet rendered content. The event contains information about the visitor's preferences.
affinityScores
Object
Describes visitor's most preferred brands and categories, the object has two attributes top_brands and top_categories which are arrays that contain maximum 5 most preferred brands/categories for the visitor. Example content:
{
top_brands:[
{name:"Acme", score:0.8},
{name:"Universal", score:0.3}
]
}
segments
Object
{
active_segments:[
{id:"5a497a000000000000000004"},
{id:"5aa12b8960b2352d326d77f1"}
]
}
Information about which segments the visitor falls into. active_segments field contains a list of segment identifiers that were active on the latest request to Nosto. Segment identifiers can be retrieved from the Nosto backend, or queried from the . Example content: