Spectare reads referrer, UTM and page signals, then assembles each page from your atom library.
What you are looking at
This is a server component. The headline, subheading, and CTA above are not static strings or client-side injections. They were fetched from POST /api/assemble/ssr at render time, and the slot values were mapped directly to the existing HTML elements before the page was sent to the browser.
The pattern
const heroSlots = assembly.find(c => c.component === 'HeroStatement')?.slots ?? {};
const ctaSlots = assembly.find(c => c.component === 'CtaStrip')?.slots ?? {};
const headline = heroSlots.headline as string ?? 'Default headline';
const ctaLabel = (ctaSlots.primary as { label: string })?.label ?? 'Get started';
// These render as plain HTML: no script, no attribute, no DOM swap.
<h1>{headline}</h1>
<a href={...}>{ctaLabel}</a>Try it
Add UTM params and reload to see the intent change:
[
{
"component": "HeroStatement",
"slots": {
"headline": "Your visitors' intent, read the moment they arrive",
"subheading": "Spectare reads referrer, UTM and page signals, then assembles each page from your atom library."
}
},
{
"component": "AtomCard",
"slots": {
"atomId": 413,
"variant": "full",
"_atomId": 413,
"_role": "mechanism",
"title": "Silent intent detection plus explicit visitor input",
"summary": "Spectare works out who each visitor is the moment they arrive, without asking anything.",
"content": "Spectare works out who each visitor is the moment they arrive, without asking anything. It reads the referrer, UTM parameters, the page they landed on, and any prior visit patterns stored locally to build a signal picture and classify intent. That classification drives which atoms are selected and how the page is assembled.\n\nWhen a visitor types a question through the ask surface, a different signal path activates. The question is explicit demand in the visitor's own words, and Spectare records it alongside the best atom similarity score the search returned. A high similarity means the library answered well. A low similarity, below 0.45, means the question went unanswered and the visitor's exact wording is flagged as a content gap.\n\nThese two signal types are treated separately in assembly. Inferred signals from referrers and UTM parameters feed the general intent summary. Typed questions get their own section in the gap detection prompt, and a weak similarity score on a typed question outweighs inferred-signal evidence when assessing what content is missing from your library.\n\nThe assembled_pages record captures source and top similarity for every page built from a typed question. This data feeds both the live unanswered questions feed in your admin and the nightly gap detection run, giving you a complete picture of where your library is strong and where it is not.",
"layout": [
"title",
"content"
],
"stats": [
{
"label": "Weak match threshold",
"value": "similarity below 0.45"
},
{
"label": "Signal types tracked",
"value": "inferred and explicit"
}
]
}
},
{
"component": "AtomCard",
"slots": {
"atomId": 423,
"variant": "card",
"_atomId": 423,
"_role": "objection",
"title": "Patterns cached, people never",
"summary": "Visitor identity is never stored: classification is held against the signal pattern, with no visitor profile and no cross-session tracking.",
"content": "Visitor identity is never stored. Session signals such as referrer URL, UTM parameters, and the page they landed on are used to classify intent, and the classification happens entirely from those signals without any identifier attached to the person who sent them. The only thing Spectare remembers between visits is a page-visit history written into the visitor's own browser. That history never leaves their device and is never sent to Spectare servers.\n\nThe latency cost of this classification is under 200 milliseconds. That ceiling applies to every personalisation request regardless of the number of signals present, so there is no trade-off between richer context and page speed.\n\nBecause no visitor identifier is ever recorded, two people who arrive with identical signals are treated identically. There is no profile to merge, no cookie to rotate, and nothing to delete if someone asks. The privacy model is a consequence of the architecture rather than a policy layer added on top of it.",
"layout": [
"title",
"content"
],
"stats": [
{
"label": "Classification latency",
"value": "under 200ms"
},
{
"label": "Visitor data stored on server",
"value": "none"
}
]
}
}
]Ready to add server-side personalisation to your stack?
Live conversion data, updated every 8s