All Posts
Headless Commerce July 7, 2026

Nosto vs Dynamic Yield vs Rebuy: Onsite Personalization for Headless Shopify Plus (2026)

Onsite personalization looks like a solved default until you go headless and discover the recommendation widgets lived inside the theme you just deleted. On a decoupled Shopify Plus build the question is not which vendor has the prettiest merchandising dashboard, it is where the recommendation logic runs, what API your storefront calls, and whether the personalized response arrives inside your render budget. We compared Nosto, Dynamic Yield, and Rebuy on API surface, where the model executes, and latency, because the tool with the best campaign UI is not always the one that survives decoupling.

Nosto vs Dynamic Yield vs Rebuy: Onsite Personalization for Headless Shopify Plus (2026)

On a hosted Shopify theme, onsite personalization is close to invisible. You install an app, it injects a "recommended for you" widget into the product page, the vendor's script watches the shopper's behavior client side, and nobody thinks about where the recommendation was computed. Go headless and the shape of the problem changes completely. The storefront is now a Hydrogen or Next application, the vendor's theme script has nowhere to inject, and every personalized block you want to render becomes an explicit API call your frontend has to make, secure, and fit inside a render budget. This post compares the three vendors enterprise Shopify Plus teams actually evaluate for onsite personalization, Nosto, Dynamic Yield, and Rebuy, on the axes that decide a headless fit.

Dimension Nosto Dynamic Yield Rebuy
Where recommendations run Nosto cloud, behavioral graph Dynamic Yield cloud, unified profiles Rebuy cloud, Shopify native data
Primary integration JS API + Recommendations REST API Experience APIs (server to server) Rebuy API + Shopify metafields
Headless delivery Server side API, some legacy JS Server side Experience API, headless first REST API, Shopify centric
Profile identity Nosto cookie + backend id Dynamic Yield user id, cross channel Shopify customer + session
Best fit Rich behavioral merchandising Enterprise cross channel experimentation Shopify native, fast to ship

The table already frames the decision. Nosto brings the deepest behavioral merchandising and a mature recommendations API, but parts of its stack still assume a client side script and want adaptation for a pure server rendered storefront. Dynamic Yield is the enterprise option built around server to server Experience APIs and cross channel profiles, which is the cleanest headless fit but the heaviest to operate. Rebuy is the Shopify native choice, fastest to ship because it speaks Shopify's data model directly, but its personalization is less sophisticated than the other two and its world is Shopify rather than cross channel.

Where the Recommendation Runs Is the Real Question

The mistake most teams make is evaluating these on the quality of the merchandising dashboard before asking where the recommendation is actually computed and how the storefront gets it. On a hosted theme that distinction is hidden because the vendor's script runs in the browser and mutates the DOM. On a headless build there is no vendor script in your render path unless you put one there, so you are choosing between calling a server side API during your own render and dropping a client side widget that fetches after hydration. That choice governs your latency, your SEO, and whether the personalized content is present in the initial HTML.

Dynamic Yield is designed for the server side path. Its Experience APIs are server to server calls your Hydrogen or Next backend makes during render, so the personalized block can be part of the initial HTML and there is no vendor JavaScript in the critical path. That is the architecture you want for a decoupled storefront, and it is why Dynamic Yield reads as headless first even though it is the most involved to configure. Nosto exposes a Recommendations REST API that supports the same server side pattern, but a meaningful part of its behavioral tracking and some of its merchandising features historically assumed the client side script, so a headless Nosto build means deciding which features you drive server side and which you accept as client side enhancements after hydration.

Latency Is the Constraint Nobody Budgets For

Every server side personalization call is time you are adding to your render, and on a product or category page that render is already competing with your commerce API, your CMS, and your search provider for the same latency budget. A personalization API that returns in 40 milliseconds is a rounding error; one that returns in 250 milliseconds under load is a decision you have to make about whether to block render on it or degrade gracefully to a non personalized default. This is the number to demand from every vendor in a proof of concept, measured at your traffic shape rather than from a marketing page, and it is the number that most often gets skipped until it shows up as a slow page in production.

The architectural pattern that survives is to treat the personalized block as an enhancement with a fast fallback rather than a hard dependency. Render a sensible non personalized default from data you already have, then either fill the personalized version server side within a tight timeout or hydrate it client side if the call is slow. That way a slow or failed personalization call degrades to a reasonable page instead of blocking the whole render, which matters because these vendors are third parties whose latency you do not control. The same fallback discipline applies to the recommendation logic itself; if you are considering building the ranking in house rather than buying it, we walk through the vector search and retrieval tradeoffs in the product recommendations with vector search and RAG breakdown.

Identity and the Profile That Follows the Shopper

Personalization is only as good as the identity it attaches behavior to, and on a headless build identity resolution is harder because you have decoupled the storefront from Shopify's session. Rebuy has the simplest story here because it lives inside Shopify's data model: it keys off the Shopify customer and session, so identity is whatever Shopify already knows, which is both its strength (no extra plumbing) and its ceiling (it does not see the shopper anywhere Shopify does not). Nosto maintains its own cookie and behavioral graph and can stitch a backend identifier to it, which gives richer onsite behavior but keeps the profile mostly onsite. Dynamic Yield is built around a cross channel user id designed to unify web, app, email, and other touchpoints into one profile, which is the reason enterprises pick it and also the reason it is the most work to implement correctly.

That difference decides how far your personalization reaches beyond the storefront. If your program is purely onsite merchandising, Rebuy's Shopify native identity or Nosto's behavioral graph is enough and simpler. If you want the same profile to drive the site, the app, and lifecycle messaging from one source of truth, Dynamic Yield's cross channel identity is the point of paying for it, though at that scope you are also making decisions about how it coexists with your messaging stack, which we compared in the Klaviyo versus Bloomreach versus Attentive personalization breakdown.

// Server side personalized block with a fast, non-personalized fallback (Hydrogen/Next)
async function getRecommendations(context, productId) {
  const fallback = await getPopularProducts(productId); // cheap, cacheable default
  try {
    const res = await fetchWithTimeout(
      `${PERSONALIZATION_API}/recommendations`,
      { userId: context.userId, productId, slot: "pdp-related" },
      120, // ms budget; beyond this we ship the fallback and hydrate later
    );
    return res.items?.length ? res.items : fallback;
  } catch {
    return fallback; // slow or failed vendor call must not block the render
  }
}

Migration and Operational Weight

The three vendors also differ sharply in how much operation they demand, and that cost is easy to underestimate when the demo makes everything look automatic. Rebuy is the lightest to run because it inherits Shopify's data and its surface area is small, which is exactly why teams reach for it when they want personalized upsells and post purchase offers shipping this quarter rather than next. Nosto sits in the middle; its merchandising and segmentation are powerful, but a headless deployment means deliberately mapping which features run server side and staffing someone to run the merchandising program. Dynamic Yield is the heaviest, an enterprise platform that rewards a dedicated experimentation and personalization team and punishes a part time owner, so it only pays off if you actually staff the cross channel program it is built for.

The honest framing is to match the vendor to the ambition and the staffing, not to the feature checklist. A team that wants Shopify native upsells fast should not buy the enterprise cross channel platform it will never fully operate, and a team building a serious cross channel personalization program should not cap itself on a Shopify centric tool because it shipped faster in the proof of concept. The same "buy the sophistication you will actually operate" rule shows up in the reviews and UGC space, where the richest platform is wasted on a team that will not run it, a tradeoff we covered in the Yotpo versus Okendo versus Junip comparison.

When This Applies to Your Stack

Choose Rebuy when you want Shopify native personalization and upsells shipping fast, when your program is onsite and post purchase rather than cross channel, and when a small team owns it, because it inherits Shopify's identity and keeps the operational surface small. Choose Nosto when you want deep behavioral merchandising and segmentation and can invest in mapping its features to a server side render, because its recommendations API and behavioral graph are strong but a headless deployment is deliberate work. Choose Dynamic Yield when you are building a serious cross channel personalization and experimentation program with a team to run it, because its server to server Experience APIs are the cleanest headless fit and its unified profile is the reason to pay the operational cost, which is wasted if you will not staff it. In every case, budget the personalization call into your render latency and build a fast fallback, because these vendors are third parties whose response time you do not control.

If your team is building onsite personalization on a headless Shopify Plus storefront and needs the API latency, identity resolution, and render integration measured against your own traffic and your own render budget rather than a vendor demo, Contra Collective architects and implements these headless commerce integrations end to end. The dashboard always demos well; the question is what the personalized block does to your product page under real load.

FAQ

Which personalization vendor is the best headless fit for Shopify Plus? Dynamic Yield, architecturally, because its Experience APIs are server to server calls your storefront backend makes during render, so personalized content lands in the initial HTML with no vendor script in the critical path. Nosto supports the same server side pattern through its Recommendations API but retains some client side assumptions, and Rebuy is Shopify native and simplest but less sophisticated.

Can I run these without a client side vendor script on a headless build? Mostly yes for Dynamic Yield and for the API driven parts of Nosto and Rebuy. Dynamic Yield is designed for server to server calls. Nosto exposes a server side recommendations API but some behavioral tracking and merchandising features historically assumed the client script, so plan which features you drive server side. Rebuy is API driven and Shopify centric.

How much latency does a personalization call add to a page? It varies by vendor, payload, and load, which is exactly why you should measure it in a proof of concept at your traffic shape rather than trust a marketing figure. Treat the call as an enhancement with a tight timeout and a non personalized fallback so a slow response degrades gracefully instead of blocking your render.

Which vendor is fastest to ship on Shopify Plus? Rebuy, because it inherits Shopify's customer and session data and has a small surface area, which makes it the common pick for personalized upsells and post purchase offers a team wants live this quarter. Nosto and Dynamic Yield deliver more sophistication at the cost of more integration and operational work.

Do I need a separate tool for cross channel personalization? If you want one profile to drive the site, app, and lifecycle messaging, Dynamic Yield's cross channel identity is built for that and is the reason to choose it over the other two. If your program is purely onsite, Rebuy's Shopify native identity or Nosto's behavioral graph is sufficient and simpler, and you can coordinate messaging separately in your lifecycle stack.

[ 02 ] — Keep Reading

More from the lab.

Aug 2, 2026 Headless Commerce

Segment vs RudderStack vs mParticle: Customer Data Platform for Headless Commerce (2026)

A customer data platform is the least visible and most load-bearing piece of a headless commerce stack. It is the layer that captures every event from the storefront, the mobile app, and the backend, resolves those events into a single view of the customer, and fans them out to analytics, email, ads, and the warehouse. Because it sits in the middle of everything, the CDP choice quietly decides three things that are expensive to change later: whether you own your customer data or rent access to it, how much of your compliance and consent surface lives inside a vendor versus your own infrastructure, and how your bill scales as event volume grows, which in commerce it always does. Segment, RudderStack, and mParticle are the three platforms most enterprise commerce teams shortlist, and they embody genuinely different philosophies rather than being feature-for-feature clones. Segment is the managed incumbent optimized for time to value. RudderStack is the warehouse-first, self-hostable challenger built for teams that want to own the pipeline. mParticle is the mobile-heavy enterprise option with the deepest identity and audience tooling. For a headless architecture, where the storefront is decoupled and events originate from several surfaces at once, the differences in how each handles server-side collection, identity resolution, and pricing at volume are what separate a clean integration from a costly one. This post lays out those differences and the decision framework that follows from them.

Jul 30, 2026 Headless Commerce

Multi Currency and Cross Border Pricing in Headless Commerce: Duties, Rounding, and the Presentment Problem (2026)

Selling internationally on a packaged storefront is mostly a settings screen: turn on the currencies, let the platform convert, and the theme shows the right number. Go headless and the convenience disappears, because now your own frontend is responsible for asking the API for a price in the customer's currency, displaying it with the correct rounding, carrying that currency all the way through the cart and into checkout, and reconciling what the customer paid against what the store settles in. Each of those steps has a way to go wrong that a themed store never exposed you to, and the most common one is subtle: the storefront requests a presentment currency and the API quietly returns the amount in the store's base currency anyway, so the customer sees a euro sign in front of a dollar number. Add duties and import taxes on a cross border order and the surface expands again, because now the total the customer sees at checkout has to include or exclude a duty depending on whether you sell delivered duty paid or delivered duty unpaid, and getting that wrong means either a surprised customer or a margin you did not plan to give away. This post is about the architecture that keeps a headless international store honest: which system owns the converted price, how presentment currency actually flows through the Storefront API, why rounding is a real rule and not a rounding error, and how duties change the checkout total.

Jul 29, 2026 Headless Commerce

Migrating from Salesforce Commerce Cloud to Headless Shopify Plus: A Replatforming Playbook (2026)

The decision to leave Salesforce Commerce Cloud is usually made on cost and velocity, and by the time it reaches engineering it has hardened into a deadline. That is where replatforming projects go wrong, because moving from SFCC to a headless Shopify Plus stack is not a migration in the copy the data and flip the switch sense; it is a rebuild of the parts of your commerce logic that lived inside SFCC cartridges and pipelines, wrapped around a data migration that is the easy part by comparison. SFCC gave you a monolith where the storefront, the business logic, and the platform were fused, and headless Shopify Plus deliberately unfuses them: Shopify becomes the commerce engine behind an API, and the storefront becomes your own application. Everything that made SFCC feel complete, the cartridge ecosystem, the pipeline customizations, the server side rendering baked in, becomes something you now own explicitly. This playbook walks the migration in the order that actually de-risks it: what maps cleanly from the SFCC data model to Shopify, what has to be rebuilt rather than ported, how to protect the SEO equity that a careless cutover destroys, and the sequencing that lets you move without a big bang launch. The projects that fail treat this as a data problem. The ones that succeed treat it as a rebuild with a data migration attached.

Ready when you are

Want to discuss this topic?

Start a Conversation