How Spectare works

Reading the visitor

On the client-side path, spectare.js runs on every page load. It reads the referrer, UTM parameters, landing page URL, and any page visit history stored in localStorage from earlier in the session or from previous visits. These signals are sent to /api/qualify/your-org, where Claude classifies them into an audience, funnel stage, and confidence score. The result is a signed context token: not a user profile, not a cookie, not a segment. On the Next.js SSR path, signals come from the HTTP request headers and query string instead. The SSR qualify result is also cached by signal pattern for 7 days, and flushed the moment you change your audience segments or other settings, so repeat visitors with the same page, referrer, and UTM signature skip the Claude call entirely and receive a classification in under 50ms.

Building the experience

On the client-side path, the context token is passed to /api/assemble/components. On the Next.js SSR path, /api/assemble/ssr handles qualify and assemble in a single server call with no token exchange needed. Either way, the core assembly logic runs: vector search, conversion history, and image selection in parallel, then Claude selecting from a registry of 9 component types. Claude sees which atoms have converted most for this audience and stage, and which atoms have appeared together in past converting sessions. Semantic similarity finds the candidates. Past performance decides between them. The result is a component list that renders in the browser (client path) or arrives pre-rendered in the HTML (SSR path).

Two-tier caching

Personalisation runs through two caches, checked in turn, so most visits never call Claude at all. The first reuses the visitor’s classification (signals to audience, stage, and intent); the second reuses the assembled page for that intent. Both are pre-warmed for common patterns and kept for seven days, so even a first visitor usually lands on a warm result and the page is served in about 200ms. The image bandit still runs on every request, even on a hit, so image optimisation never stalls.

The image bandit

Spectare selects a hero image for each assembled experience. It uses a multi-armed bandit: 90% of requests exploit the image with the highest observed conversion rate for the current audience and stage combination; 10% explore a random image to gather data on untested combinations. Every impression is recorded, and conversions update the conversion rate in real time. No manual A/B test setup required.

The co-conversion graph

Every conversion event records which atoms appeared together in that session. A graph tracks how often every pair of atoms appears together in converting sessions. When the assembly pipeline picks a primary atom, it reads the graph to surface supporting atoms that have actually worked alongside that primary, not just ones that are semantically similar. Claude also receives the top-converting atom IDs for the visitor's specific audience and stage combination, drawn from the last 30 days of conversions. Both signals are passed directly to Claude during assembly, on every path: client-side, SSR, and script tag. The graph is rebuilt nightly from all conversion data.

Testing what works, not just what fits

Vector search finds the right atoms. The co-conversion graph finds the right supporting atoms. But which component order converts best? A StatGrid before an AtomCard, or after? Spectare tests this automatically. Set an exploration rate in Settings and a configurable share of visitors see an experimental arrangement. The arrangement is labelled with a strategy tag: data-led, outcome-led, question-led, social-proof-led, or technical-led. Every arrangement is recorded with its impressions and conversions, on every path: client-side, SSR, and script tag, on cache hits as well as fresh assemblies.

Then the loop closes. Once an arrangement clears your signal threshold, Claude is told which arrangements convert best for this visitor’s audience and stage, with the rates that earned them. It prefers a proven arrangement when the atoms support one, and ignores it when they do not: a winning shape built from the wrong content converts worse than an honest one. Exploration runs blind to this, on purpose, so it keeps finding arrangements the data has not seen yet. The atom content never changes. Only the presentation is tested.

There is a discipline to when a winner counts. Ahead is not the same as winning: a 12% rate beating a 10% rate across a hundred visits each sits well inside the noise. So Spectare holds every arrangement’s rate as a confidence interval, not a single number, and only names a winner once that interval clears the runner-up, once its worst case still beats the other’s best case. Until then the honest verdict is that it is still gathering data, and that is exactly what your analytics show, per audience and stage: a statistically real winner, or a clear not-yet, never a coin toss dressed up as a result.

Everything above just happened for you

This block was assembled by the exact pipeline described above: your signals were classified into an intent, atoms were selected from the library, and the layout was composed and cached, before the page reached you. Here is what it produced for this visit.

The same content, read by machines

More of your buyers research through AI, and the visitor is often an agent. The same atom library that personalises pages for people is also published as machine-readable data, so an assistant can read what you offer, accurately and current, without scraping a rendered page.

• →Discovery: your site serves an llms.txt describing what you offer and where to find it.
• →Content: every published atom is available as clean JSON at /api/content, with a stable slug per item.
• →Hand-off: an assistant can call the qualify endpoint with what its user wants and get back a link to a page personalised for that person, so the referral lands on a tailored experience, not a generic one.