> 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-tag.md). # Nosto Tag Nosto is an onsite personalization engine: it learns from what shoppers browse and buy, then renders product recommendations into your pages. This destination loads Nosto in the browser and keeps each visitor's Nosto session up to date from your Chord events. See [Nosto](/activate/event-streaming/destinations/personalization/nosto.md) for how it fits with the [Nosto server](/activate/event-streaming/destinations/personalization/nosto/nosto-server.md) version, and for how to report orders from only one of them. ## Getting started You need one value, and one thing removed. **Your Nosto account ID** is shown in the top-right corner of the Nosto dashboard, under your shop name. **Remove any Nosto script you installed yourself**, including the Nosto app if you installed one through your commerce platform. This is not a preference. Nosto honours only the first session initialized on a page, so two scripts produce two sessions, double your page views, and split one shopper's behavior across both. This destination replaces that installation rather than complementing it. Your existing shopper profiles carry over. Nosto identifies returning visitors by its own first-party cookie, which this destination leaves Nosto to manage, so the history behind your recommendations survives the switch. ## Settings * **Destination Name** (required): a name to tell this destination apart. * **Account ID** (required): your Nosto account ID. Chord uses it to load Nosto's script, so recommendations will not render if it is wrong. * **Load Recommendations** (optional): requests and renders Nosto recommendations into the placements already on your pages. Nosto finds those placements from your own markup, so there is nothing to configure. On by default. Turn it off only if you want Nosto to receive behavioral data without displaying anything. Browsing, cart and order data is sent either way. * **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 Tag** from the destination catalog, using the settings above. See [Connect a destination](/activate/event-streaming/connect-a-destination.md) for the full steps. Nothing else is configured. In particular there is no placement setup: Nosto finds the placement elements already in your page markup and injects into them, which is why the switch is a drop-in. Remember to remove your own Nosto script. {% hint style="warning" %} Use the same Nosto account as the Nosto server version, and report orders from only one of them. See [Nosto](/activate/event-streaming/destinations/personalization/nosto.md). {% endhint %} ## Event mapping | Chord event | Nosto event | Notes | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ----- | | `Page Viewed` (home page) | Front page view | | | `Page Viewed` (any other page) | Session refresh. No view recorded, see below | | | [`Product Viewed`](/collect-data/tracking-plan/product-viewed.md) | Product view, with the product ID | | | [`Product List Viewed`](/collect-data/tracking-plan/product-list-viewed.md) | Category view, with the category path | | | [`Products Searched`](/collect-data/tracking-plan/products-searched.md) | Search, with the search term | | | [`Cart Viewed`](/collect-data/tracking-plan/cart-viewed.md) | 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) | Cart contents update | | | `identify`, `group`, [`Signed Up`](/collect-data/tracking-plan/signed-up.md), [`Email Captured`](/collect-data/tracking-plan/email-captured.md) | Customer details | | | [`Order Completed`](/collect-data/tracking-plan/order-completed.md) | Order, with line items | | | [`Order Refunded`](/collect-data/tracking-plan/order-refunded.md) | Not supported in the browser. See [Gotchas](#gotchas) | | **One view is recorded per navigation, not two.** 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 and inflate the page counts it merchandises on. So the specific event records the view, and `Page Viewed` only keeps the session alive. The home page is the exception. It has no specific event of its own, so there `Page Viewed` records the front-page view. The trade-off is that a page with no specific Chord event, such as a blog post or an about page, is not recorded as a view in Nosto. It still refreshes the shopper's session, so their browsing continuity and recommendations are unaffected. ## Product and category data Each order and cart line sends the product ID, variant ID, name, unit price, quantity and currency. A line with no resolvable product ID is dropped rather than sent blank, because Nosto keys recommendations off the product ID and a blank one is unusable. Chord skips an `Order Completed` with an empty cart, or with no resolvable line items, and logs a message to the browser console. Category views send a slash-delimited path, which is the form Nosto expects. Chord's tracking plan carries a single category label, so `Dresses` is sent as `/Dresses` and `Womens > Dresses` as `/Womens/Dresses`. If your recommendations depend on a deeper hierarchy, send the full path in the event's `category` property, using `>` between levels. ## Identity Nosto receives email address, first and last name, and your customer reference **in plaintext**, and this is deliberate. Nosto has to resolve a shopper to a stored profile and address them by name in the experiences it renders. Unlike an advertising pixel, it accepts no hashed identifier. Hashing would break the product rather than protect it. If your security review needs to know exactly what leaves the page, that is the list. Marketing permission is sent only when your event carries one. Chord does not assume a default in either direction. ## Content Security Policy If your storefront sets a Content Security Policy, Nosto will not load until its hosts are allowed. The symptom is silence: no recommendations, no data, and a `Refused to load` message in the browser console. | Directive | Host | | ------------- | --------------------------- | | `script-src` | `https://connect.nosto.com` | | `connect-src` | `https://*.nosto.com` | Both directives are required. `script-src` lets the library load. `connect-src` lets it report. A policy that allows only the first fails in a way that looks like it worked: the script runs, recommendations render, and nothing reaches Nosto. This list is what a Chord reference storefront needs to deliver product views, cart updates and orders. Nosto also loads recommendation images from wherever your product images are hosted, and may request further hosts depending on the features your account has enabled. Those are not published, so read them off your own browser console during setup. Load a page with the destination active, fire a product view and an order, and add any host named in a violation. ## Custom properties **Custom property mappings are not forwarded to Nosto, and cannot be.** Nosto's browser API has no general-purpose property bag. Each call takes a fixed set of fields, and the cart, customer and order objects are closed shapes with nowhere for an extra key to go. A mapping you configure on this destination will not reach Nosto. If you need Nosto to act on something outside the fields above, that is a conversation with Nosto about their catalog or segment data. Chord cannot pass it through. ## Gotchas **Refunds need the server version.** Nosto models a refund as a status change on an existing order, and it exposes order-status updates only through its GraphQL API. `Order Refunded` is skipped here with a console message. Connect [Nosto server](/activate/event-streaming/destinations/personalization/nosto/nosto-server.md) to report refunds. **Emptying a cart does not clear it in Nosto.** Chord's `Product Removed` carries the line that was removed, 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, Chord leaves Nosto's cart alone in that case, and it updates on the shopper's next cart-bearing event. **Nosto's event set is fixed.** Nosto accepts the page types above plus cart, customer and order updates, and has no arbitrary custom event. Chord events with no Nosto equivalent, such as `Product Clicked`, `Product List Filtered` and `Coupon Applied`, are skipped, and the reason is logged to the browser console. **Sessions expire after 30 minutes** of inactivity. A shopper who returns later starts a new session. Their profile and history persist, but that visit's browsing begins fresh. **Consent gating applies.** If the destination is configured with required consent categories, no Nosto call is made for visitors who have not accepted them. Nosto's own session cookie is only set after consent, which also means the server version has no session to update until then. --- # 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-tag.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.