> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/activate/event-streaming/destinations/personalization/nosto.md).

# Nosto

Nosto is an onsite personalization engine. It learns from what shoppers browse and buy, then renders product recommendations into your pages. Chord sends your events to Nosto from the browser and from the server.

## What each version does

* [**Nosto Tag**](/activate/event-streaming/destinations/personalization/nosto/nosto-tag.md) loads Nosto in the shopper's browser and keeps each visitor's Nosto session up to date with page views, cart contents and identity. It also renders Nosto's recommendations into the placements already on your pages. In Chord, you add it as **Nosto Tag**.
* [**Nosto server**](/activate/event-streaming/destinations/personalization/nosto/nosto-server.md) sends the same information from Chord's servers over Nosto's GraphQL API. It is the only version that can report refunds, and it can report an order even when checkout happens on a domain your storefront does not control. In Chord, you add it as **Nosto**.

## Why use both

The two versions are designed to run together. The browser version catches on-page behavior and renders recommendations. The server version survives ad blockers and closed tabs, and it reports refunds.

The Nosto Tag sets up Nosto's visitor session. Chord forwards that session identifier, so the server version updates **the same** session instead of creating a second one. Both versions must use the same Nosto account. Browsing, cart and identity updates are safe to send from both, because writing the same cart twice leaves one cart.

Without the Nosto Tag, the server version still reports orders. It identifies the customer by your own customer reference. It cannot send browsing behavior, because there is no browser session for it to attach to.

{% hint style="warning" %}
**Do not report orders from both versions.** Nosto publishes no deduplication rule for order submission. It has no dedup key and no documented behavior when the same order arrives twice. Running both versions reports each order twice. Choose one version for orders.
{% endhint %}

Choose the server version for orders if reliability matters most. It is the more reliable of the two. Choose the Nosto Tag if you are replacing an existing Nosto installation, because it behaves like the one you had.

## How they deduplicate

Views do not double count. Your storefront fires `Page Viewed` and a specific event such as `Product Viewed` on the same page load. Both versions record one view for each navigation. The specific event records the view. `Page Viewed` records a view only on the home page.

Orders carry your own order reference, so that is the value to deduplicate against if another system also sends orders to Nosto. The Nosto Tag sends it as `external_order_ref`. The Nosto server version sends it as the order `ref`. Nosto does not document what it does with a repeat order, so treat "send each order once" as the rule.

## Set up

* [Nosto Tag](/activate/event-streaming/destinations/personalization/nosto/nosto-tag.md)
* [Nosto server](/activate/event-streaming/destinations/personalization/nosto/nosto-server.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chord.co/activate/event-streaming/destinations/personalization/nosto.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.