Using the JavaScript Library
Last updated
Was this helpful?
Last updated
Was this helpful?
For client-side/frontend integrations, Nosto's JavaScript library can be used to simplify the integration. It provides a programming interface to access the Search & Categories API.
For the most basic search the fields
parameter should be provided to specify what product/keyword fields should be returned. Both products
and keywords
can be used separately and together, depending on the use case. For all parameters, see the .
The api.search
function also accepts the following options:
redirect
false
Automatically redirect if search returns a redirect
track
null
Track search query by provided type
The function automatically loads session parameters required for personalization & segments in the background.
In order to request custom fields, add the entries "customFields.key"
and "customFields.value"
to the requested product fields. This changes the example above like this
For a search page in most cases the facets
parameter should be provided.
Also redirect
& track
should be enabled to automatically track searches to Nosto analytics & redirect if API returns a redirect request.
isKeyword
should be set to true
if search is submitted by clicking a keyword, suggested in the autocomplete.
track
should be enabled to automatically track searches to Nosto analytics.
Furthermore redirect
& track
should be enabled to automatically track searches to Nosto analytics & redirect if API returns a redirect request.
For some of the search features to work properly, such as personalised results and segments, the search function needs to be able to access information about the user's session from the front-end.
To get all session data the following snippet can be used:
The function accepts the following options:
maxWait
2000
Maximum execution time in MS
cacheRefreshInterval
60000
Maximum cache time
Tracking search events to analytics can be divided into three parts: search
, search submit
, search product click
. These are user behaviours that should be tracked:
search submit (type = serp
)
faceting, paginating, sorting (type = serp
) or (type = category
)
autocomplete input (type = autocomplete
)
search results product click (type = serp
), (type = autocomplete
) or (type = category
)
autocomplete keyword click (type = autocomplete
)
category merchandising results (type = category
)
JS API library provides tracking helpers for all of these cases.
User actions that lead to search results should be tracked with api.recordSearch()
after search request is done:
search submit (type = serp
) - user submits search query in autocomplete component and is landed to SERP
faceting, paginating, sorting (type = serp
) or (type = category
) - user adjusts current search results by filtering (e.g. brand), selecting search page, sorting results
autocomplete input (type = autocomplete
) - user sees partial results while typing in search input
category merchandising results (type = category
) - user sees specific category results when category is selected (category merchandising must be implemented)
You don't need to execute api.recordSearch()
if you call api.search(query, { track: 'serp'|'autocomplete'|'category'})
function from JS API, becauseapi.search()
already calls api.recordSearch()
when track
option is provided.
type
Search type: serp
, autocomplete
, category
request
result
options (optional)
Record search options. Currently is accepts:
isKeyword: boolean
- should be set when keyword in autocomplete is clicked (search is submitted via keyword)
Example:
Example:
Example:
Search queries are categorised into two groups: organic and non-organic searches.
In order to mark a search query as an organic search you need to call api.recordSearchSubmit(query: string)
. You should call it on search input submit only, before search request is sent.
Product clicks should be tracked in autocomplete component, SERP, category page with api.recordSearchClick()
by providing component (type), where click occurred, and clicked product data:
type
Search type: serp
, autocomplete
, category
hit
Object containing productId
and url
, collected from clicked product
Example:
When shopping cart additions happen directly as part of the search or autocomplete results without a navigation to the product page, the api.recordSearchAddToCart()
method should be called with the component (type), where addition occurred and the product data:
type
Search type: serp
, autocomplete
, category
hit
Object containing productId
and url
, collected from product
Example:
When tracking events, adherence to the following criteria is essential for capturing detailed and valid data:
query
parameter:
The query
string is an essential component for event tracking.
If present, include products.sort
to track sorting behavior.
If applicable, incorporate products.filter
.
searchResults
parameter:
products.hits
array containing objects with a productId
is mandatory.
products.total
number to identify if the search has results.
For accurate pagination tracking, products.from
and product.size
must be included.
For identifying if the request was autocorrected include products.fuzzy
.
For category requests, either products.categoryId
or products.categoryPath
is mandatory.
Bear in mind that search queries are split between organic and non-organic searches. To classify a search as organic, it is crucial to invoke api.recordSearchSubmit()
upon the search input submission, before the actual search request is dispatched. This step is pivotal in ensuring the seamless tracking of organic searches through to the SERP.
Tracking product clicks is fundamental for understanding user interaction. Use api.recordSearchClick()
to monitor this actions correctly, specifying the type
and relevant hit data.
In case of an SPA based integration the api.recordSearchClick
calls should be complemented with Session API or api.createRecommendationRequest()
usage to couple the search analytics events to generic Nosto events for accurate attribution.
For category pages in most cases the facets
parameter should be provided. Additionally (for Shopify) and should be also provided.
The results of this function should be passed to search query parameter. In case search is called from backend, it should pass this data to backend (e.g. using ).
On errors from api.search
calls the error object contains a status field that has the HTTP response status which can be used to determine the cause of the error in addition to the error message. The ranges of the status codes used for errors are 400-499 and 500-599. For details on these error codes, go to
The tracking metadata is primarily taken from the third parameter. The and objects must be provided in the api.recordSearch
call instead of partials.
Tip: In case of API integration, use this example GraphQL partial query to integrate with the API and retrieve the necessary response data for precise event tracking.