DEV Community: Personyze Support

Headless CMS Personalization: How to Personalize Content in a Composable Stack

Personyze Support — Wed, 23 Sep 2026 22:13:26 +0000

Headless and composable stacks split the content (an API-first CMS) from the front end that renders it. That’s great for flexibility — one content source feeding a website, an app, and the edge — but it complicates personalization, which used to rely on a single page and a script tag swapping elements in the browser.

In a headless setup, personalization has to become a decision layer: something that decides who sees what for a given slot, and hands that decision to whatever front end is doing the rendering. Here’s a practical architecture for headless CMS personalization with Personyze — the building blocks, two ways to integrate, and the questions to settle before you build.

Why headless changes personalization

A traditional CMS renders the page and a personalization script rewrites the DOM after load. Headless breaks that model: the CMS is just a content API, and your front end — Next.js, Nuxt, a mobile app, an edge function — fetches content and renders it. There is no single page to inject into.

So personalization splits into three jobs: define audiences (who), decide the content or variant for this visitor and slot (what), and render it wherever your front end lives. Personyze handles the first two and hands the decision to your stack — on the server or in the browser.

The building blocks: audiences, placements, decisions

Audiences define who. The easiest path is to embed the Personyze Audience Builder in an iframe inside your own UI: editors define rules using your customer and account fields, and Personyze returns a compiled audience id/definition. You get a full rules engine without rebuilding audience UI or logic yourself. Audiences can combine on-site behavior, CRM data, and first-party signals.

Placements mark where personalized content goes. Each is a placement_id — you can create a universal placement or one scoped strictly to a given page or URL.

Decisions tie it together: given a visitor_id and the placement_ids on a page, Personyze resolves the visitor’s audience and returns the content_id and variant to show. The same decision flow powers A/B tests, so testing is not a separate system.

Two ways to wire it up

There’s no single “right” integration — it comes down mostly to whether you render on the server or in the browser.

Server-to-server, client-side, or Personyze-led with CMS content import.

Option A — Server-to-server (recommended)

Your CMS/back end stores the content_id, the placement_id (universal or page-scoped), and the audience id/definition. On each request, your server reports the visitor_id plus the placement_ids on the page to Personyze; Personyze returns the content_id and variant (the same flow as A/B tests); and your app renders the content.

The server reports visitor and placements; Personyze returns the content and variant to render.

Benefits: no coupling to content type, more control over content management, and a workflow that stays simple even when an update requires content edits. It fits server rendering, SSR, and edge cleanly.

The trade-off: server-to-server means you send Personyze the visitor context it needs to decide — the current page and URL, the referrer, the user agent, and the behavior events that build the visitor’s profile. The client-side option collects all of that automatically from a single Personyze tag (70+ attributes out of the box); server-to-server trades that convenience for control, keeping decisions on your backend. It’s the right call for many teams — just budget for the extra integration work.

Option B — Client-side rendering

Your front end sends the actual content payload to Personyze, and Personyze places it on the page in the browser. Use this when you want client-only rendering or rapid UI experiments without server hooks.

Because it runs through the Personyze tag, it also captures the visitor context for you — page, referrer, device, and on-site behavior — so there’s far less to wire up than the server-to-server path.

A/B testing comes along for free

Because the decision flow is “visitor_id + placement_id → variant,” the same wiring runs A/B and multivariate tests. Test content variants per placement and audience, and let Personyze close out losers and roll traffic to winners — no separate testing integration.

Server-side or client-side rendering?

Both work, and Personyze supports both a server-side REST API and a client-side JSON API. Server-side (during page generation, SSR, or at the edge) decides before render, so there’s no flicker and it works for SEO, apps, and email. Client-side decides in the browser, which is faster to iterate for SPA experiments. Many teams mix the two.

Dynamic content, recommendations, and JSON

The same decision layer does more than swap static blocks. Dynamic content — a hero, banner, message, or CTA — can be personalized by audience, with your own custom fields (name, industry, location, account type) inserted as personalization tags right into the content or the recommendation set.

For recommendations, Personyze returns JSON for both product and content recommendations. You pick the algorithm and map the fields you want, and Personyze returns a personalized JSON set per visitor. Your front end reads it from a JavaScript variable and renders it in your own layout — cards, carousels, widgets — which is ideal for SPAs, mobile apps, and custom front ends. Prefer not to build the display? Managed, responsive widgets are available too.

And it fits either render path from above: client-side, using the client-side JSON API read in the browser or app; or server-side, calling Personyze’s API from your backend with the visitor’s id — even their CRM id or email — to get their recommendations back. There’s a full REST API and native iOS/Android SDKs, and the same multilingual logic applies, so content and recs arrive in the visitor’s language.

Two quick examples

1. A B2B homepage hero (server-to-server)

Build: Define a “Manufacturing accounts” audience in the Audience Builder using your CRM and firmographic fields. Create a placement — home-hero — and store two hero variants in your CMS. On each homepage request, your server sends the visitor_id, home-hero, and the visitor context (page, referrer, and the company from your own data) to Personyze, gets back a content_id, and renders that hero server-side.

End result: a classic B2B personalization play — a visitor from a manufacturing account lands on a hero and CTA written for manufacturing — server-rendered, no flicker — while everyone else sees the default. Point the same placement at two variants and you’ve got an A/B test.

2. A “Recommended for you” rail in a SPA (client-side JSON)

Build: Set up a Content Recommendations JSON action with a “readers also read” or “most read by interest” algorithm, map the fields you want (title, image, URL), and assign the result to a JavaScript variable. On your article page, read that variable and render your own card layout — no server changes.

End result: every reader sees a personalized rail in your own design — the heart of publisher & media personalization. New or anonymous readers get trending and popular picks; once an interest is known it shifts to interest-based recommendations — all client-side, and in the visitor’s language.

What to align on before you build

A short discovery checklist gets a headless integration scoped quickly:

Render path: server-side during page generation, or client-side?
Tech stack: which languages and frameworks power your rendering layer?
Auth & events: preferred auth (API key or OAuth), and — for server-to-server — can you send Personyze the visitor context it needs (current page/URL, referrer, user agent) plus real-time view/click events (visitor_id + placement_id)?
Caching / CDN: any constraints for server-to-server calls — TTLs, edge caching, or personalization-vs-cache rules — to factor in?

Works with any headless CMS

The decision layer is CMS-agnostic: it operates on content_ids and placement_ids, not on a specific product. That means it slots in alongside API-first platforms like Contentful, Sanity, Strapi, Contentstack, or ButterCMS — and it can pull unified profiles from a CDP such as Segment or an integration you already run.

Originally published on the Personyze blog.

Recommendation Algorithms Explained: Collaborative Filtering, Bought-Together, Trending, and More

Personyze Support — Wed, 23 Sep 2026 22:12:44 +0000

Recommendation widgets all look the same from the outside — a row of products or articles under a heading. What actually decides whether they lift revenue or just fill space is the algorithm behind them. Match the right one to the placement and you get relevance; pick wrong and you get noise.

Here are the four families of recommendation algorithms — collaborative filtering, bought-together, trending, and content/interest-based — what each is good for, and how they map to the algorithms Personyze ships. (For the machinery that powers them, see what’s under the personalization hood.)

Try the live interactive demo

The same engine on two very different pages: a product page attaching bought-together items, and a publisher’s site ranking what to read next. Watch it switch between them.

First, the cold-start problem

Every algorithm has to answer one awkward question: what do you show a brand-new visitor with no history? Personyze’s approach is to start from crowd data — what’s popular across everyone — and switch to personalized the moment it learns an interest. Interests are ranked and updated as the visitor browses, so the same widget gets sharper with every click. Keep that in mind as you read on: most of the algorithms below quietly fall back to crowd data until there’s enough signal to personalize.

AI recommendations: predicting what each visitor will buy

The most powerful recommendations aren’t a single rule — they’re a prediction. Personyze’s personalized (AI) recommendations combine many data points at once to work out what each visitor is most likely to buy or engage with next:

Your product feed and catalog — attributes, categories, price, availability.
The site itself, crawled, so the engine understands your products and content.
The visitor’s own profile — CRM fields, demographics, location.
Other visitors’ behavior — the crowd patterns behind “people like you.”
What this visitor clicks, views, and adds to cart, in real time.
What they — and everyone else — actually purchased.

Personyze weighs the catalog, the crowd, and the individual together, then ranks the catalog by how likely this visitor is to buy.

Instead of leaning on one signal, the engine weighs the catalog, the crowd, and the individual together, ranks your catalog by how likely this visitor is to buy, and gets sharper with every interaction. That’s what powers Personyze’s Highest Relevance / Personalized Recommendations — the truest form of “personalized.”

Because recommendations are built on transaction statistics, a brand-new setup would normally take a little while to gather enough data. You can skip the wait by uploading your past or offline transactions — feeding the engine your purchase history (including in-store sales) so it reaches relevance from day one.

Collaborative filtering: “people like you”

Collaborative filtering is the workhorse of recommendations. It learns from behavior across many visitors — people who bought or viewed this also bought or viewed that — without needing to understand the product itself. It’s how “you might also like” works.

In Personyze, this family includes Highest Relevance (a personalized mix based on visitors with similar demographics and interactions), Likely to Buy (items bought by those who viewed the current one), and Likely to View (items viewed by those who viewed it). On the content side, Visitors Who Read This Also Read These is the same idea for articles. Best for discovery and personalized picks.

Bought together: the cross-sell engine

Where collaborative filtering finds “people like you,” bought-together finds item-to-item associations: what gets purchased alongside a specific product, or alongside whatever’s already in the cart. It’s the most direct lever on average order value.

Personyze’s Bought Together (for product pages) shows the items most frequently bought by people who bought the current item, while Cross-sale Cart Recommendation and Most Frequently Bought with Cart do the same for the cart. Best for cross-sell on product and cart pages.

A frequently-bought-together widget: the current item plus its most common companions, with one add-all-to-cart action.

Trending and popular: the crowd as a signal

Sometimes the smartest move is to show what’s working right now. Popularity-based algorithms surface the most bought or viewed items — optionally filtered by the visitor’s interest, or by fresh and discounted stock — and they’re the natural answer to cold-start.

Personyze offers Popular from Most Recent Interest and Popular from Recent Interests, plus merchandising-friendly variants like New In Stock, Recently Discounted, Price Recently Changed, and even most popular by gender/age. Best for new visitors, homepages, and promoting fresh or discounted inventory.

Content and interest-based: match the thing, not just the crowd

For articles — and for interest matching generally — you often want to recommend by topic and the visitor’s ranked interests, not only by co-behavior. Personyze’s content engine does exactly this, and automatically excludes pieces the visitor has already read.

It includes Most Read Based on Interest(s), New Article Based on Your Interests, Most Popular from This Author, and conversion-minded options like Content That Led to Most Conversions and Likely to Read and Buy for content-to-commerce. Best for publishers and any site that uses content to drive sales.

History-based: what they already did

The simplest algorithms are often the highest-converting, because they lean on the visitor’s own history. Buy It Again resurfaces past purchases in order, View It Again brings back browsed items, and In Your Cart reminds them what’s waiting. Best for reorders, reminders, and cart recovery.

Filtering the picker to visitor-history algorithms — Buy It Again, View It Again, and In Your Cart.

How to pick the right algorithm for each placement

You choose one algorithm per widget — with an optional fallback if it can’t fill — and match it to the placement:

Homepage: trending or interest-based, so new and returning visitors both see something relevant.
Product page: bought-together plus likely-to-buy, to drive discovery and order value.
Cart: cross-sell based on what’s already in the basket.
Article or blog: content and interest-based, excluding what they’ve already read.
Category page: trending or popular within the category, tuned to the visitor’s interests.

In Personyze each widget runs a single algorithm — with a fallback for when it can’t fill — and you choose a design from the recommendation template gallery, then apply filters and display options like direct add-to-cart or showing the recommendations as a popup (including exit-intent).

In Personyze, choose the algorithm per widget — with fallbacks, filters, and options like direct add-to-cart or popup display.

Delivered your way: a managed widget or raw JSON

Choosing the algorithm is one decision; how you deliver the recommendations is another — and Personyze supports both ends of the spectrum.

The usual path is a managed widget: pick a ready-made design from the recommendation template gallery, customize the look and feel, and drop it in — no code required. You preview exactly what visitors will see before you publish.

Customize and preview the widget before publishing — no code required.

For full control, pull the recommendations as JSON instead — through a client-side JavaScript API or a JSON feed — and render them in your own front end or on the server. Headless storefronts, mobile apps, and fully custom layouts all work: the algorithm and personalization run in Personyze, while you own the presentation. The same recommendation engine can power a no-code widget or a bespoke, server-side component.

How Personyze fits

Personyze ships every algorithm above out of the box, blends crowd data with the visitor’s ranked interests, and lets you place the right one on every surface — product, cart, homepage, or article. See them in action in our product recommendation examples, and when you’re ready to measure the payoff, our personalization ROI guide covers how to read recommendation contribution — the revenue recommendations actually influence.

Recommendation analytics — contribution, purchases, and the sessions each algorithm influenced.

Originally published on the Personyze blog.

An MCP server for a personalization platform: OAuth 2.1, 23 tools, and staging by default

Personyze Support — Wed, 23 Sep 2026 21:38:10 +0000

You can now connect Claude, ChatGPT or any other MCP-capable assistant straight to your Personyze account and work in plain conversation — ask how campaigns are doing, find where you’re losing traffic, build a campaign, pause an action, manage audiences. No exports, no copying between tabs, no code.

One connection, and your assistant can read and act on your Personyze account.

What MCP is, briefly

MCP (Model Context Protocol) is the open standard AI assistants use to work with outside services. Anthropic introduced it in November 2024; OpenAI adopted it in 2025, and by early 2026 there were over 10,000 active public MCP servers. The usual analogy is “USB-C for AI”: instead of every tool building a bespoke integration for every assistant, a tool exposes one MCP server and every compatible assistant can use it.

Personyze runs one. An assistant that connects to it reaches your account directly, under your account’s permissions — the same external API surface as the full-featured API.

Server URL:  https://personyze.com/mcp/

Connecting an assistant

Most assistants ask only for the URL and then walk you through signing in:

In Personyze, open Integrations → AI Assistants (MCP) and copy the Server URL.
In the assistant, add a custom connector and paste it — in Claude: Settings → Connectors → Add custom connector; in ChatGPT: install it from the ChatGPT app directory instead, which skips the pasting.
Approve the connection on the Personyze screen that opens. Nothing to copy and paste — the assistant receives its own credential.

The AI Assistants (MCP) card in Personyze — copy the Server URL into your assistant. API keys are only for tools that can’t open a browser.

Tools that can’t open a browser — a script, an IDE plugin — can send a Personyze API key as a header instead:

Authorization: Bearer YOUR_API_KEY

A note on availability: Personyze is now listed in the Claude connector directory, so on Claude it is a one-click install rather than pasting a URL — see the announcement. On ChatGPT it installs from the ChatGPT app directory the same way; any other assistant connects with the URL above as a custom connector. Both Claude and ChatGPT gate connectors by plan tier, so check yours if the connection screen never appears.

What you can ask it to do

The wording is yours — these are kinds of question, not fixed commands.

Understand how campaigns are performing

“Which campaigns performed best in the last 30 days?”
“How is the pricing-page banner doing compared to April?”
“Which campaigns had no activity at all last month?”

It reads the daily performance summary per action — impressions, deliveries, clicks, dismissals, failures, your configured goals and revenue totals. It will decline to quote a click-through rate on a sample too small to mean anything and say so, rather than quoting it anyway.

Find where you’re losing traffic

“Which landing pages lose the most sessions?”
“Which traffic sources convert worst?”
“What organic search terms bring people in?”

Site-wide traffic for any date range by page, landing page, referrer, search term, device, city or country — with sessions, bounces, goals, goal value and time on page, plus the personalization impressions and clicks on those pages. Rates are computed after grouping and low-traffic rows are excluded when ranking by a rate, so a 100% bounce rate over three sessions doesn’t outrank a real problem.

See what’s running, and why

“Why isn’t the welcome banner showing?”
“What is the targeting on campaign 1834?”
“Which of my actions are live and which are still in testing?”

Targeting comes back as readable rule text — “Include on current page: Contains /pricing and not Full URL contains login” — not raw configuration.

Build and change campaigns

“Create a campaign targeting returning mobile visitors.”
“Rename it to Summer Promo and re-target to visitors from paid search.”
“Pause the popup on the checkout page.”

Work with audiences and profiles

“How many audiences do I have, and how big is each one?”
“Add john@example.com to the Enterprise Prospects audience.”
“Which visitors have visited more than five times?”

Ask how the product works — or get a human

“How do I set up conversion tracking?” is answered from the knowledge base with links to the articles used; if the docs don’t cover it, the assistant says so and offers to open a support ticket rather than guessing — writing up what you were doing and what it already checked, so support doesn’t start from nothing.

The tools behind it

23 tools, plus a fall-through to the REST API for everything else.

Twenty-three tools cover campaigns and actions, analytics, audiences and visitor profiles, placeholders, docs search and support tickets. Anything the dedicated tools don’t cover falls through to personyze_api — the same REST objects available to any API client — so the assistant isn’t boxed in by the tool list.

Safety: staging, confirmation, revocation

Giving an assistant write access to your website deserves scrutiny. Three properties matter here:

New campaigns are created in staging mode. They’re shown only to visitors arriving from a staging IP; real traffic keeps seeing what’s live, and you publish in the panel. Targeting described in plain words is compiled into real rules and read back to you — because a rule that says something slightly different from what you asked looks identical from the outside.
Pausing or resuming an action is live, so it’s confirmed first — naming the action, the campaign it sits in, and what visitors stop or start seeing. One action at a time, and fully reversible.
Access is revocable instantly. Every connected assistant rides on an API key belonging to your account and acts with that account’s permissions. Delete the key under Integrations to disconnect; revocation is immediate.

For developers building a client rather than using a ready-made assistant, the server implements OAuth 2.1 (authorization code with PKCE/S256, public clients), dynamic client registration (RFC 7591), and discovery per RFC 9728 and RFC 8414, with scope personyze:full.

Why this matters for personalization

Personalization tools have always had a reporting problem: the data lives in one panel, the decision happens in someone’s head, and the change happens in a third place a week later. MCP collapses that. You can ask which pages leak sessions, get the answer from your real personalization data, and stage a campaign against that page — in the same conversation, without leaving your assistant.

It also means Personyze fits into whatever agentic stack you’re already assembling. Forrester expects 30% of enterprise app vendors to launch MCP servers in 2026; the practical upshot is that your assistant can read your CRM, your ads and your personalization platform side by side, and reason across them.

Docs

MCP server documentation: full tool list, auth details and troubleshooting.
Server URL: https://personyze.com/mcp/

Originally published on the Personyze blog.