Nosto Tag

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 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 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 connecting to the nosto cdp destination in chord, add the nosto tag destination enter your account id leave load recommendations on unless you want nosto to receive behavioural data without displaying anything connect it to your front end site remove your own nosto script 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 using alongside the nosto destination 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 this destination is the natural choice if you are replacing a nosto tag, because it behaves like the installation you already had the nosto destination is more reliable — server side reporting is unaffected by ad blockers, and it still works when checkout happens on a domain your storefront does not control deduplication 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 event mapping chord event nosto page viewed (home page) front page view page viewed (any other page) session refresh — no view recorded, see below product viewed product view, with the product id product list viewed category view, with the category path products searched search, with the search term cart viewed cart page view product added , product removed , checkout started cart contents update identify , signed up , email captured customer details order completed order, with line items order refunded not supported in the browser — see 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 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 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 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, 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 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 — 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 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 rather than something chord can pass through gotchas 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