Personalisierung im Headless CMS: Inhalte in einem Composable Stack personalisieren

Headless- und Composable-Stacks trennen die Inhalte (ein API-first CMS) vom Frontend, das sie rendert. Das ist großartig für die Flexibilität — eine Inhaltsquelle speist Website, App und Edge —, macht aber die Personalisierung komplizierter, die bisher auf einer einzelnen Seite und einem Script-Tag beruhte, das Elemente im Browser austauschte.

In einem Headless-Setup muss Personalisierung zu einer Entscheidungsebene werden: etwas, das entscheidet, wer in einem bestimmten Slot was sieht, und diese Entscheidung an das Frontend übergibt, das gerade rendert. Hier ist eine praxisnahe Architektur für Headless-CMS-Personalisierung mit Personyze — die Bausteine, zwei Integrationswege und die Fragen, die Sie vor dem Bau klären sollten.

Warum Headless die Personalisierung verändert

Ein klassisches CMS rendert die Seite, und ein Personalisierungsskript schreibt nach dem Laden das DOM um. Headless bricht mit diesem Modell: Das CMS ist nur eine Content-API, und Ihr Frontend — Next.js, Nuxt, eine mobile App, eine Edge-Funktion — ruft Inhalte ab und rendert sie. Es gibt keine einzelne Seite mehr, in die man etwas einschleusen könnte.

Personalisierung zerfällt also in drei Aufgaben: Zielgruppen definieren (wer), den Inhalt oder die Variante für diesen Besucher und Slot bestimmen (was) und ihn in Ihrem Frontend rendern — egal, wo es läuft. Personyze übernimmt die ersten beiden Aufgaben und übergibt die Entscheidung an Ihren Stack — auf dem Server oder im Browser.

Die Bausteine: Zielgruppen, Platzierungen, Entscheidungen

Zielgruppen legen fest, wer. Am einfachsten betten Sie den Audience Builder von Personyze per iframe in Ihre eigene Oberfläche ein: Redakteure definieren Regeln mit Ihren Kunden- und Kontofeldern, und Personyze liefert eine kompilierte Zielgruppen-ID bzw. -Definition zurück. So erhalten Sie eine vollständige Regel-Engine, ohne Zielgruppen-Oberfläche oder -Logik selbst nachzubauen. Zielgruppen kombinieren Verhalten auf der Website, CRM-Daten und First-Party-Signale.

Platzierungen markieren, wo personalisierte Inhalte erscheinen. Jede ist eine placement_id — Sie können eine universelle Platzierung anlegen oder eine, die strikt auf eine bestimmte Seite oder URL beschränkt ist.

Entscheidungen führen alles zusammen: Anhand einer visitor_id und der placement_ids auf einer Seite ermittelt Personyze die Zielgruppe des Besuchers und gibt die content_id und die anzuzeigende Variante zurück. Derselbe Entscheidungsablauf steuert A/B-Tests, Testen ist also kein separates System.

Zwei Wege der Anbindung

Es gibt nicht die eine „richtige“ Integration — es hängt vor allem davon ab, ob Sie auf dem Server oder im Browser rendern.

Option A — Server-to-Server (empfohlen)

Ihr CMS bzw. Backend speichert die content_id, die placement_id (universell oder seitenspezifisch) und die Zielgruppen-ID bzw. -Definition. Bei jeder Anfrage meldet Ihr Server die visitor_id sowie die placement_ids der Seite an Personyze; Personyze gibt die content_id und die Variante zurück (derselbe Ablauf wie bei A/B-Tests), und Ihre App rendert den Inhalt.

Vorteile: keine Kopplung an den Inhaltstyp, mehr Kontrolle über das Content-Management und ein Workflow, der auch dann einfach bleibt, wenn ein Update Inhaltsänderungen erfordert. Das passt nahtlos zu Server-Rendering, SSR und Edge.

Der Kompromiss: Server-to-Server bedeutet, dass Sie Personyze den Besucherkontext senden, den es für die Entscheidung braucht — die aktuelle Seite und URL, den Referrer, den User Agent und die Verhaltensereignisse, aus denen das Profil des Besuchers entsteht. Die clientseitige Option erfasst all das automatisch über ein einziges Personyze-Tag (über 70 Attribute ab Werk); Server-to-Server tauscht diesen Komfort gegen Kontrolle und hält die Entscheidungen in Ihrem Backend. Für viele Teams ist das die richtige Wahl — planen Sie nur den zusätzlichen Integrationsaufwand ein.

Option B — Clientseitiges Rendering

Ihr Frontend sendet den eigentlichen Inhalt an Personyze, und Personyze platziert ihn im Browser auf der Seite. Nutzen Sie das, wenn Sie nur clientseitig rendern oder schnelle UI-Experimente ohne Server-Hooks durchführen möchten.

Da es über das Personyze-Tag läuft, erfasst es auch den Besucherkontext für Sie — Seite, Referrer, Gerät und Verhalten auf der Website —, sodass deutlich weniger anzubinden ist als beim Server-to-Server-Weg.

A/B-Tests gibt es gratis dazu

Da der Entscheidungsablauf „visitor_id + placement_id → Variante“ lautet, führt dieselbe Anbindung auch A/B- und multivariate Tests durch. Testen Sie Inhaltsvarianten pro Platzierung und Zielgruppe, und lassen Sie Personyze Verlierer beenden und Traffic zu den Gewinnern leiten — ohne separate Testintegration.

Serverseitig oder clientseitig rendern?

Beides funktioniert, und Personyze bietet sowohl eine serverseitige REST-API als auch eine clientseitige JSON-API. Serverseitig (bei der Seitengenerierung, per SSR oder am Edge) wird vor dem Rendern entschieden, also ohne Flackern, und es funktioniert für SEO, Apps und E-Mail. Clientseitig wird im Browser entschieden, was bei SPA-Experimenten schnellere Iterationen erlaubt. Viele Teams kombinieren beides.

Dynamische Inhalte, Empfehlungen und JSON

Dieselbe Entscheidungsebene kann mehr, als statische Blöcke auszutauschen. Dynamische Inhalte — ein Hero, Banner, eine Botschaft oder ein CTA — lassen sich nach Zielgruppe personalisieren, wobei Ihre eigenen Felder (Name, Branche, Standort, Kontotyp) als Personalisierungs-Tags direkt in den Inhalt oder das Empfehlungsset eingefügt werden.

Für Empfehlungen gibt Personyze JSON für Produkt- und Content-Empfehlungen zurück. Sie wählen den Algorithmus und ordnen die gewünschten Felder zu, und Personyze liefert pro Besucher ein personalisiertes JSON-Set. Ihr Frontend liest es aus einer JavaScript-Variablen und rendert es in Ihrem eigenen Layout — Karten, Karussells, Widgets —, ideal für SPAs, mobile Apps und individuelle Frontends. Sie möchten die Darstellung nicht selbst bauen? Verwaltete, responsive Widgets gibt es ebenfalls.

Und es passt zu beiden Render-Wegen von oben: clientseitig über die clientseitige JSON-API, die im Browser oder in der App ausgelesen wird, oder serverseitig über einen Aufruf der Personyze-API aus Ihrem Backend mit der ID des Besuchers — sogar mit seiner CRM-ID oder E-Mail-Adresse —, um seine Empfehlungen abzurufen. Es gibt eine vollständige REST-API und native SDKs für iOS und Android, und dieselbe mehrsprachige Logik greift, sodass Inhalte und Empfehlungen in der Sprache des Besuchers ankommen.

Zwei kurze Beispiele

1. Ein B2B-Startseiten-Hero (Server-to-Server)

Umsetzung: Definieren Sie im Audience Builder eine Zielgruppe „Fertigungsunternehmen“ mit Ihren CRM- und firmografischen Feldern. Legen Sie eine Platzierung an — home-hero — und speichern Sie zwei Hero-Varianten in Ihrem CMS. Bei jeder Startseitenanfrage sendet Ihr Server die visitor_id, home-hero und den Besucherkontext (Seite, Referrer und das Unternehmen aus Ihren eigenen Daten) an Personyze, erhält eine content_id zurück und rendert diesen Hero serverseitig.

Ergebnis: ein klassischer Fall von B2B-Personalisierung — ein Besucher aus einem Fertigungsunternehmen landet auf einem Hero und CTA für die Fertigungsbranche — serverseitig gerendert, ohne Flackern —, während alle anderen die Standardversion sehen. Richten Sie dieselbe Platzierung auf zwei Varianten aus, und Sie haben einen A/B-Test.

2. Eine Leiste „Für Sie empfohlen“ in einer SPA (clientseitiges JSON)

Umsetzung: Richten Sie eine JSON-Aktion für Content-Empfehlungen mit einem Algorithmus wie „Leser lasen auch“ oder „Meistgelesen nach Interesse“ ein, ordnen Sie die gewünschten Felder zu (Titel, Bild, URL) und weisen Sie das Ergebnis einer JavaScript-Variablen zu. Lesen Sie diese Variable auf Ihrer Artikelseite aus und rendern Sie Ihr eigenes Karten-Layout — ohne Änderungen am Server.

Ergebnis: Jeder Leser sieht eine personalisierte Leiste in Ihrem eigenen Design — das Herzstück der Personalisierung für Verlage und Medien. Neue oder anonyme Leser erhalten Trends und beliebte Inhalte; sobald ein Interesse bekannt ist, wechselt es zu interessenbasierten Empfehlungen — alles clientseitig und in der Sprache des Besuchers.

Was Sie vor dem Bau klären sollten

Mit einer kurzen Discovery-Checkliste ist eine Headless-Integration schnell abgesteckt:

• Render-Weg: serverseitig bei der Seitengenerierung oder clientseitig?
• Tech-Stack: Welche Sprachen und Frameworks treiben Ihre Render-Ebene an?
• Authentifizierung und Events: Bevorzugte Authentifizierung (API-Schlüssel oder OAuth) und — bei Server-to-Server — können Sie Personyze den benötigten Besucherkontext (aktuelle Seite/URL, Referrer, User Agent) sowie Echtzeit-Events für Aufrufe und Klicks senden (visitor_id + placement_id)?
• Caching / CDN: Gibt es Einschränkungen für Server-to-Server-Aufrufe — TTLs, Edge-Caching oder Regeln für Personalisierung versus Cache —, die zu berücksichtigen sind?

Funktioniert mit jedem Headless CMS

Die Entscheidungsebene ist CMS-unabhängig: Sie arbeitet mit content_ids und placement_ids, nicht mit einem bestimmten Produkt. Deshalb fügt sie sich neben API-first-Plattformen wie Contentful, Sanity, Strapi, Contentstack oder ButterCMS ein — und kann einheitliche Profile aus einer CDP wie Segment oder einer Integration beziehen, die Sie bereits nutzen.

Headless-Personalisierung: FAQ

Was ist Headless-CMS-Personalisierung?

Das Personalisieren von Inhalten, die ein Headless-CMS (API-first) an ein entkoppeltes Frontend liefert. Statt eines Skripts, das eine gerenderte Seite umschreibt, entscheidet eine Entscheidungsebene, welcher Inhalt oder welche Variante jeder Besucher in einem bestimmten Slot sehen soll, und Ihr Frontend rendert ihn — auf dem Server oder im Browser.

Kann ich eine Headless-Website personalisieren, ohne mein Frontend neu zu bauen?

Weitgehend ja. Beim Server-to-Server-Muster speichert Ihr Backend content_id, placement_id und Zielgruppe, meldet dann visitor_id + placement_ids und rendert, was Personyze zurückgibt. Es gibt keine Kopplung an den Inhaltstyp, der Großteil der Arbeit besteht also darin, Events und einen Entscheidungsaufruf anzubinden.

Sollte ich Personalisierung serverseitig oder clientseitig rendern?

Serverseitig (SSR oder Edge) wird vor dem Rendern entschieden, Flackern vermieden, und es funktioniert für SEO, Apps und E-Mail. Clientseitig lässt sich bei SPA-Experimenten schneller iterieren. Personyze bietet sowohl eine serverseitige REST-API als auch eine clientseitige JSON-API, und viele Teams kombinieren beides.

Wie werden Zielgruppen in einem Headless-Setup definiert?

Sie können den Audience Builder von Personyze per iframe in Ihre eigene Oberfläche einbetten, sodass Redakteure Regeln mit Ihren Kunden- und Kontofeldern definieren und Personyze eine kompilierte Zielgruppendefinition zurückgibt — oder Sie legen Zielgruppen direkt in Personyze an. So oder so müssen Sie keine Zielgruppenlogik nachbauen.

Funktionieren A/B-Tests in einer Headless-Architektur?

Ja. Derselbe Entscheidungsablauf — visitor_id + placement_id liefert eine Variante — führt A/B- und multivariate Tests durch, mit automatischer Auswahl des Gewinners. Testen ist keine separate Integration.

Mit welchen Headless-CMS funktioniert das?

Mit jedem API-first CMS. Die Entscheidungsebene arbeitet mit content_ids und placement_ids statt mit einem bestimmten Produkt, passt also zu Contentful, Sanity, Strapi, Contentstack, ButterCMS und anderen und lässt sich mit einer CDP wie Segment kombinieren.

Jetzt loslegen

Personalisieren Sie Ihren Headless-Stack, ohne ihn neu aufzubauen. Buchen Sie eine Demo und stecken Sie den Rahmen einer Integration ab, oder sehen Sie sich die Tarife an.

Weiterführende Artikel

• Empfehlungsalgorithmen erklärt — wie die Engine auswählt, was sie ausspielt.
• Mehrsprachige Personalisierung — Inhalte und Empfehlungen in jeder Sprache.
• Website-Personalisierung — die Targeting- und Content-Engine hinter allem.