How true SSR personalisation works in a Next.js app

The Spectare SSR path for Next.js has two layers: a server-side data fetch and a conditional render that switches between true SSR and a client fallback. Start by calling getServerAssembly in your async page component, passing a plain-English page hint and the incoming searchParams. The function returns an ssrData object containing the assembly, the resolved intent, and a variantId, or null if the cache is cold.

When ssrData is present, render ServerAssemblyRenderer with the assembly and place VariantTracker anywhere in the tree with your orgSlug and variantId. ServerAssemblyRenderer is a pure server component, so nothing in the personalised section ships JavaScript to the browser. VariantTracker is a thin client component whose only job is to record conversion events for attribution. When ssrData is null, render PersonalisedSection with the same pageHint string as your fallback; it will display the client shimmer while a fresh assembly is generated and cached.

The conditional pattern looks like this in practice: if ssrData is truthy, return ServerAssemblyRenderer and VariantTracker side by side inside a fragment; otherwise return PersonalisedSection alone. Both branches share the same pageHint string so the intent classification stays consistent between warm and cold paths.

This pattern is now the standard across all Spectare marketing pages including the homepage, features overview, AI, analytics, and integration sub-pages, compare, use-cases, and how-it-works. If you are migrating an existing page that used PersonalisedSection with initialAssembly props, replace that block with the conditional described above and remove the initialAssembly, initialIntent, and initialVariantId props.