Dynamic Blocks und Personalisierung: Content je Kundensegment

1. Was Dynamic Blocks von statischem Content unterscheidet

Ein regulärer CMS-Block zeigt für jeden Besucher denselben Inhalt, unabhängig davon, ob es sich um einen Erstbesucher, einen Bestandskunden mit Kaufhistorie oder ein B2B-Firmenkonto handelt. Ein Dynamic Block löst genau dieses Problem: Er definiert mehrere Content-Varianten für dieselbe Platzierung und wählt zur Laufzeit die passende Variante anhand von Bedingungen wie Kundengruppe, Kundensegment oder Bestellhistorie aus. Für Redakteure bleibt die Bedienung im Backend nahezu identisch zu einem normalen Block, die Personalisierung passiert vollständig im Hintergrund.

Der praktische Nutzen zeigt sich besonders bei Cross-Selling-Bannern, Willkommensnachrichten und saisonalen Angeboten. Ein Neukunde sieht eine Einführungsaktion, ein Bestandskunde mit hohem Warenkorbwert sieht ein Premium-Angebot, ein B2B-Kunde sieht Firmenkonto-spezifische Inhalte, alles über denselben Dynamic Block an derselben Stelle im Layout. Diese Form der Personalisierung erhöht die Relevanz des angezeigten Contents erheblich, ohne dass für jede Zielgruppe eine separate Seite gepflegt werden muss.

2. Grundlage: Customer Segments als Zielgruppendefinition

Bevor ein Dynamic Block sinnvoll eingesetzt werden kann, braucht es eine saubere Definition der Zielgruppen über Customer Segments. Ein Customer Segment fasst Kunden anhand von Kriterien wie Kundengruppe, Anzahl bisheriger Bestellungen, letzter Bestellwert oder Website-Zuordnung zusammen. Diese Segmente werden regelmäßig per Indexer neu berechnet und bilden die Grundlage, auf die sich Dynamic Blocks später beziehen.

Ein häufiger Anfängerfehler ist, zu viele, zu granulare Segmente anzulegen, was die Pflege im Backend unübersichtlich macht und die Indexer-Laufzeit unnötig verlängert. Bewährt hat sich, mit einer kleinen Anzahl klar abgegrenzter Segmente zu starten, etwa Neukunden, Bestandskunden mit weniger als drei Bestellungen, Bestandskunden mit mehr als drei Bestellungen und B2B-Firmenkonten, und diese Struktur erst bei belegtem Bedarf zu verfeinern.

<!-- app/code/Mironsoft/DynamicBlockPersonalization/etc/adminhtml/system.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Config:etc/system_file.xsd">
    <system>
        <section id="mironsoft_dynamicblock" translate="label" type="text" sortOrder="200"
                 showInDefault="1" showInWebsite="1" showInStore="1">
            <label>Dynamic Block Personalization</label>
            <tab>mironsoft</tab>
            <resource>Mironsoft_DynamicBlockPersonalization::config</resource>
            <group id="general" translate="label" type="text" sortOrder="10" showInDefault="1">
                <label>Allgemein</label>
                <field id="enabled" translate="label" type="select" sortOrder="10" showInDefault="1">
                    <label>Personalisierung aktivieren</label>
                    <source_model>Magento\Config\Model\Config\Source\Yesno</source_model>
                </field>
                <field id="fallback_segment" translate="label" type="text" sortOrder="20" showInDefault="1">
                    <label>Fallback-Segment-ID</label>
                    <comment>Wird verwendet, wenn kein Segment zutrifft</comment>
                </field>
            </group>
        </section>
    </system>
</config>

3. Dynamic Block anlegen: Bedingungen und Zuordnung

Ein Dynamic Block wird im Backend unter Marketing angelegt, mit einem Zeitraum, einer Zuordnung zu einem oder mehreren Customer Segments und dem eigentlichen Content pro Variante. Die Bedingungslogik funktioniert additiv: Trifft ein Besucher auf mehrere Segmente gleichzeitig zu, entscheidet die Priorität der Dynamic-Block-Zuordnung, welche Variante ausgespielt wird. Diese Priorisierung sollte bewusst dokumentiert werden, weil sonst bei wachsender Anzahl an Blöcken schnell unklar wird, welche Regel im Konfliktfall gewinnt.

Für die technische Zuordnung im eigenen Modul lohnt sich ein Plugin auf den Segment-Resolver, der prüft, ob ein eingeloggter Kunde einem bestimmten Segment angehört. Dieser Resolver wird sowohl von der nativen Dynamic-Block-Logik als auch von eigenen Erweiterungen genutzt, etwa wenn zusätzlich zur Segmentzugehörigkeit auch Geodaten oder das verwendete Endgerät in die Personalisierung einfließen sollen.

<?php
declare(strict_types=1);

namespace Mironsoft\DynamicBlockPersonalization\Model;

use Magento\Customer\Model\Session as CustomerSession;
use Magento\TargetRule\Model\ResourceModel\Rule\CollectionFactory as RuleCollectionFactory;

/**
 * Resolves which dynamic block variant applies to the current visitor.
 */
class SegmentResolver
{
    /**
     * @param CustomerSession $customerSession Current customer session
     * @param RuleCollectionFactory $ruleCollectionFactory Factory for target rule collections
     */
    public function __construct(
        private readonly CustomerSession $customerSession,
        private readonly RuleCollectionFactory $ruleCollectionFactory,
    ) {
    }

    /**
     * Determines the highest priority segment ID that matches the current visitor.
     *
     * @param int $fallbackSegmentId Segment ID used when no match is found
     * @return int Resolved segment ID
     */
    public function resolveSegmentId(int $fallbackSegmentId): int
    {
        if (!$this->customerSession->isLoggedIn()) {
            return $fallbackSegmentId;
        }

        $customerGroupId = (int) $this->customerSession->getCustomer()->getGroupId();
        $orderCount = (int) $this->customerSession->getCustomer()->getData('order_count');

        // Simplified segment matching — real implementation queries segment index tables
        if ($orderCount === 0) {
            return 10; // new customer segment
        }

        if ($orderCount > 3) {
            return 20; // loyal customer segment
        }

        return $fallbackSegmentId;
    }
}

4. Einbindung im Layout und in Page Builder Seiten

Für die Einbindung stehen zwei Wege offen: als klassischer Block über Layout-XML oder als Baustein direkt innerhalb einer Page-Builder-Seite. Über Layout-XML wird der Dynamic Block an einer festen Container-Position eingehängt, etwa oberhalb des Produktrasters auf der Kategorieseite. Innerhalb von Page Builder erscheint der Dynamic Block als eigener Content Type im Editor-Panel und lässt sich von Redakteuren frei innerhalb der Seite platzieren, ohne dass ein Entwickler das Layout anfassen muss.

Für Hyvä-Themes ist wichtig, dass der Renderer-Block des Dynamic Content keine zusätzliche AJAX-Anfrage für die Segmentauflösung auslöst, sondern die Entscheidung serverseitig beim initialen Rendern trifft. Das hält die Implementierung im Einklang mit dem Hyvä-Prinzip, möglichst wenig zusätzliches JavaScript zu laden, und vermeidet einen sichtbaren Content-Sprung nach dem ersten Rendern der Seite.

5. Full Page Cache: warum personalisierte Blöcke ihn nicht brechen

Personalisierter Content und Full Page Cache scheinen zunächst im Widerspruch zu stehen: Wenn jeder Besucher unterschiedlichen Content sehen soll, wie kann eine Seite dann als Ganzes gecacht werden? Die Lösung liegt in der Trennung zwischen statischem, cachefähigem Seiteninhalt und dem personalisierten Fragment, das per Ajax-Nachladen oder über clientseitiges Caching der jeweiligen Segmentzuordnung im Local Storage ergänzt wird. Der Dynamic Block selbst wird dabei nicht Teil der gecachten HTML-Antwort, sondern als Platzhalter-Container ausgeliefert, der erst nach dem Cache-Hit mit dem passenden Segment gefüllt wird.

Diese Architektur ist bewusst so gestaltet, dass Full Page Cache und Personalisierung gleichzeitig funktionieren, ohne dass für jedes Segment eine eigene gecachte Seitenvariante vorgehalten werden muss. Wichtig ist, die Segmentauflösung selbst performant zu halten, etwa durch einen dedizierten, schlanken Endpoint, der nur die Segment-ID zurückgibt, statt den kompletten personalisierten HTML-Block bei jedem Request neu zu berechnen.

# Verify that dynamic block placeholders are not baked into the cached HTML response
curl -s -H "Cache-Control: no-cache" https://shop.example.com/ | grep -o 'data-dynamic-block-placeholder="[^"]*"'

# Check Full Page Cache hit status for a personalized landing page
curl -sI https://shop.example.com/ | grep -i x-magento-cache-debug

6. Eigene Segmentierungsregeln über Plugins erweitern

Die nativen Bedingungen für Customer Segments decken viele Standardfälle ab, reichen aber nicht für jede Personalisierungsanforderung aus. Über ein Plugin auf den Regel-Evaluator lassen sich eigene Bedingungen ergänzen, etwa die Zugehörigkeit zu einer externen Loyalty-Stufe, die nicht in Magento selbst gepflegt wird, sondern über eine API eines Drittsystems abgefragt wird. Wichtig ist dabei, das Ergebnis dieser externen Abfrage kurzzeitig zwischenzuspeichern, damit nicht bei jedem Seitenaufruf ein externer API-Call ausgelöst wird.

Für komplexere Personalisierungsszenarien, etwa wetterabhängige oder standortbasierte Inhalte, lässt sich derselbe Mechanismus nutzen, der auch für Customer Segments greift, nur dass die Bedingungsauswertung zusätzliche Kontextdaten aus dem Request heranzieht. Diese Erweiterbarkeit macht Dynamic Blocks zu einem flexiblen Fundament für Personalisierung, das deutlich über reine Kundengruppen-Logik hinausgeht.

7. Personalisierung für B2B-Firmenkonten und Kundengruppen

Im B2B-Kontext gewinnt Personalisierung eine zusätzliche Dimension: Nicht nur der einzelne Kunde, sondern das gesamte Firmenkonto mit seinen Rollen und Freigabeworkflows beeinflusst, welcher Content relevant ist. Ein Firmenkonto-Administrator sieht möglicherweise Hinweise zu Bestellfreigaben, während ein einfacher Mitarbeiter-Account dieselbe Fläche für Produktempfehlungen aus dem vereinbarten Sortiment nutzt. Ein Dynamic Block mit Bedingung auf die Firmenkonto-Rolle deckt diesen Fall ab, ohne dass für B2B eine komplett eigene Content-Strategie nötig wird.

Kundengruppen bleiben dabei die einfachste und robusteste Grundlage für Personalisierung, weil sie bereits an vielen Stellen in Magento verankert sind, etwa bei Preisregeln und Sichtbarkeit von Produkten. Ein Dynamic Block, der sich in erster Linie auf Kundengruppen stützt und erst sekundär auf feinere Customer Segments zurückgreift, ist in der Praxis wartbarer als eine Lösung, die ausschließlich auf komplexe Segmentlogik setzt.

8. Erfolg messen: A/B-Tests und Auswertung je Segment

Personalisierter Content ohne Erfolgsmessung bleibt eine Vermutung. Jeder Dynamic Block sollte über ein eindeutiges Tracking-Attribut verfügen, das beim Klick oder bei der Conversion an die Analytics-Plattform übergeben wird, getrennt nach ausgespielter Variante. So lässt sich belegen, ob die Premium-Variante für Bestandskunden tatsächlich höhere Konversionsraten erzielt als eine generische Variante, oder ob die Personalisierung im konkreten Fall keinen messbaren Unterschied macht.

Für belastbare Aussagen empfiehlt sich ein kontrollierter A/B-Test, bei dem ein Teil eines Segments trotz Zugehörigkeit die generische Variante sieht. Nur dieser Vergleich innerhalb desselben Segments zeigt, ob die Personalisierung selbst den Unterschied macht, statt nur die ohnehin unterschiedliche Kaufbereitschaft verschiedener Segmente zu bestätigen.

9. Personalisierungsansätze im Vergleich

Für die Auswahl des richtigen Personalisierungsansatzes lohnt sich ein Blick auf Aufwand, Cache-Verträglichkeit und Aktualität der Daten.

Für die meisten Magento-Shops ist die Kombination aus Dynamic Block und Customer Segment der beste Startpunkt, weil sie nativ in Magento verankert ist, mit dem Full Page Cache zusammenarbeitet und ohne zusätzliche Drittsystem-Lizenz auskommt. Erst bei sehr komplexen, ML-gestützten Empfehlungen lohnt sich der Blick auf externe Personalisierungs-Engines.

10. Zusammenfassung

Dynamic Blocks lösen das Grundproblem statischer Content-Bausteine: Nicht jeder Besucher hat dieselben Bedürfnisse, und ein einziger Inhalt für alle verschenkt Conversion-Potenzial. Auf Basis sauber definierter Customer Segments lässt sich Personalisierung so umsetzen, dass sie mit dem Full Page Cache zusammenarbeitet, statt ihn zu deaktivieren, indem der personalisierte Anteil als schlankes Fragment nachgeladen wird.

Der größte Hebel liegt in der Kombination aus wenigen, klar abgegrenzten Segmenten, einer sauberen Priorisierung bei Überschneidungen und einer konsequenten Erfolgsmessung je Variante. Wer diese drei Bausteine zusammenbringt, gewinnt eine Personalisierungslösung, die sowohl für einfache Cross-Selling-Banner als auch für komplexere B2B-Firmenkonto-Szenarien tragfähig ist.

11. FAQ: Dynamic Blocks und Personalisierung