Nosto is an onsite personalization engine: it learns from what shoppers browse and buy, then renders product recommendations into your pages. The Nosto Tag destination loads Nosto in the browser and keeps each visitor's Nosto session up to date from your Chord events.

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 behaviour 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.

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.

The Nosto destination sends the same information server-side, over Nosto's GraphQL API. Both can run together, and they write to the same visitor session as long as both use the same Nosto account — this destination owns Nosto's session cookie, and Chord forwards it so the server-side half updates that session rather than creating another.

One exception, and it matters: do not report orders from both. Nosto publishes no deduplication rule for order submission — no dedup key, and no documented behaviour when the same order arrives twice. Running both destinations therefore reports each order twice. Pick one surface for orders:

Chord sends your order's own reference as external_order_ref, so it is the value to deduplicate against if you also send orders to Nosto from another system. As above, Nosto does not document what it does with a repeat, so treat "send each order once" as the rule rather than relying on Nosto to sort it out.

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 is the one that 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 — a blog post, 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.

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.

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.

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, so 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.

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.

Both directives are required. script-src lets the library load; connect-src lets it report — and a policy that allows only the first fails in a way that looks like it worked, because 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 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 rather than something Chord can pass through.

Refunds need the server-side destination. 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 the Nosto destination 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, so 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 — Product Clicked, Product List Filtered, Coupon Applied and similar — 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-side destination has no session to update until then.

Updated 1 September 2026