> 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/nosto-server.md). # Nosto server Nosto is an onsite personalization engine: it learns from what shoppers browse and buy, then renders product recommendations into your pages. This destination sends that behavior to Nosto from Chord's servers, over Nosto's GraphQL API. It is unaffected by ad blockers, and it can report an order even when checkout happens on a domain your storefront does not control. See [Nosto](/activate/event-streaming/destinations/personalization/nosto.md) for how it fits with the [Nosto Tag](/activate/event-streaming/destinations/personalization/nosto/nosto-tag.md) version, and for how to report orders from only one of them. ## Getting started You need a Nosto **Apps token**, created in Nosto under **Settings > Authentication Tokens**. The token is scoped to one Nosto account. If you also use the [Nosto Tag](/activate/event-streaming/destinations/personalization/nosto/nosto-tag.md) version, the token must come from the **same account** as the Account ID configured there. That is what lets both write to a single visitor session instead of two. ## Settings * **Destination Name** (required): a name to tell this destination apart. * **API Token** (required): your Nosto Apps token. * **Consent Requirements** (optional): the consent categories a visitor must accept before Chord sends data to this destination. See [Consent](/activate/event-streaming/consent.md). ## Connect Add **Nosto** from the destination catalog, using the settings above. See [Connect a destination](/activate/event-streaming/connect-a-destination.md) for the full steps. {% hint style="warning" %} Connecting this alongside Nosto Tag reports each order twice. Nosto publishes no deduplication rule for orders, so choose one version to report them. See [Nosto](/activate/event-streaming/destinations/personalization/nosto.md). {% endhint %} ## Event mapping | Chord event | Nosto event | Notes | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | ----- | | `Page Viewed` (home page) | Session update: front page view | | | `Page Viewed` (any other page) | Not sent. The specific view event covers it | | | [`Product Viewed`](/collect-data/tracking-plan/product-viewed.md) | Session update: product view | | | [`Product List Viewed`](/collect-data/tracking-plan/product-list-viewed.md) | Session update: category view | | | [`Products Searched`](/collect-data/tracking-plan/products-searched.md) | Session update: search | | | [`Cart Viewed`](/collect-data/tracking-plan/cart-viewed.md) | Session update: cart page view | | | [`Product Added`](/collect-data/tracking-plan/product-added.md), [`Product Removed`](/collect-data/tracking-plan/product-removed.md), [`Checkout Started`](/collect-data/tracking-plan/checkout-started.md) | Session update: cart contents, without counting a page view | | | `identify`, `group`, [`Signed Up`](/collect-data/tracking-plan/signed-up.md), [`Email Captured`](/collect-data/tracking-plan/email-captured.md) | Session update: customer details | | | [`Order Completed`](/collect-data/tracking-plan/order-completed.md) | Order placement, with line items | | | [`Order Refunded`](/collect-data/tracking-plan/order-refunded.md) | Order status update | | **One view is recorded per navigation.** Your storefront fires `Page Viewed` and a specific event like `Product Viewed` on the same page load. Recording both would report every product page to Nosto twice. The specific event records the view. The generic `Page Viewed` carries nothing else Nosto can store, so no call is made at all. The home page is the exception. It has no specific event of its own, so there `Page Viewed` records the front-page view. This matches the Nosto Tag exactly, so running both does not reintroduce the double count for views. Browsing and cart events need the visitor's Nosto session, so they are only sent when the Nosto Tag is also running and has established one. Orders do not. ## Order values Line items send the product ID, variant ID, name, unit price, quantity and currency. Values are sent as decimal amounts in the order's own currency. A $22.43 line is sent as `22.43`, not in cents. Chord does not send an `Order Completed` that has no line items. Currency is sent when your event carries one and omitted otherwise, so Nosto applies your account's default rather than Chord guessing. Order status and payment provider are likewise sent only when your event includes them. ## Identity Nosto receives email address, first and last name, and your customer reference **in plaintext**, deliberately. Nosto resolves a shopper to a stored profile and addresses them by name in the experiences it renders. Unlike an advertising API, it accepts no hashed identifier. Hashing would break the product rather than protect it. If your security review needs to know exactly what is transmitted, that is the list. Marketing permission is sent only when your event carries one. Chord assumes no default. ## Gotchas **Refunds are this destination's job.** Nosto exposes order-status transitions only through its GraphQL API, so the Nosto Tag cannot report them. If refunds matter to your reporting, this destination is the only way to send them. **Emptying a cart does not clear it in Nosto.** Chord's `Product Removed` carries the removed line, not the cart that remains. Chord cannot tell "the cart is now empty" apart from "this event had no products". Rather than risk clearing real carts, Nosto's cart is left alone in that case and updates on the next cart-bearing event. **Nosto's event set is fixed.** There is no arbitrary custom event. Chord events with no Nosto equivalent are not sent, and the reason is recorded in the destination's logs. **Sessions expire after 30 minutes** of inactivity. An event arriving after that has no live session to update. Orders are unaffected, since they identify the customer directly. **Consent gating applies.** Nosto's session cookie is only set after consent, so before a visitor consents there is no session for this destination to update. Orders identified by customer reference are unaffected. --- # 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/nosto-server.md?ask=&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.