Dieser Artikel richtet sich an technisch orientierte Dynamic Yield Nutzer
In der heutigen Marktumgebung, in der die Kundenbindung sowohl von der Leistung der Website als auch von personalisierten Erlebnissen abhängt, stehen Unternehmen oft vor zwei entgegengesetzten Meinungen – die Priorisierung der Website-Leistung oder die Bereitstellung hochgradig personalisierter Inhalte.
Einerseits möchten das Personalisation-Teams völlig unabhängig von Entwicklern agieren und perfekt abgestimmte Kreativinhalte für jeden Benutzer veröffentlichen – vor allem während Hauptverkaufszeiten, bei Sonderangeboten oder anderen bedeutsamen Ereignissen, die nicht mit den Zyklen der Programmierung übereinstimmen. Darüber hinaus verwenden Content-Teams in der Regel bereits ein eigenständiges Tool für das Content-Management und möchten vermeiden, dass sie sich in eine neue Plattform einarbeiten und somit zwei verschiedene Content-Quellen pflegen müssen.
Andererseits möchten Entwickler die Kontrolle darüber haben, welche Inhalte wie angezeigt werden, um sicherzustellen, dass die Benutzererfahrung auf der Website kohärent ist und fehlerfrei bereitgestellt wird.
Die Nutzung der Experience-API-Funktionen von Dynamic Yield in Kombination mit dem CMS Ihrer Wahl kann die Anforderungen beider Gruppen erfüllen, um hochgradig personalisierte Inhalte in einer Weise bereitzustellen, die für die Leistung optimiert ist. Diese Konfiguration kann parallel zu den typischen clientseitig eingefügten Skriptkampagnen durchgeführt werden.
Anwendungsbeispiel
Ein typisches Szenario, das zu einer solchen Integration führen würde, ist ein Fall, in dem eine große Menge personalisierter Inhalte an kleinere Benutzersegmente geliefert werden muss. Zum Beispiel möchte das Content-Team personalisierte Homepage-Banner basierend auf folgenden Kriterien bereitstellen:
- Geschlecht des Benutzers
- Affinität des Benutzers zu einer Produktgruppe
- Affinität des Benutzers zu einer bestimmten Farbe.
Davon ausgehend, dass ein typischer E-Commerce-Shop mindestens 5 verschiedene Produktgruppen in 5 verschiedenen Farben für 2 Geschlechter anbietet, würde die Anzahl der Variationen bereits auf 50 verschiedene Banner steigen. Um eine solche Kampagne manuell zu erstellen, müsste jede Geschlechts- und Farb-Variante separat verwaltet werden, indem der Inhalt erstellt, exportiert und in die entsprechenden Varianten in Dynamic Yield hochgeladen wird. Das ist nicht nur ineffizient, sondern erfordert auch regelmäßige Wartungen und könnte möglicherweise zu menschlichen Fehlern führen.
Die Vorteile einer automatisierten CMS-Integration verringern die Zeit, die für die Erstellung und Wartung einer solchen Kampagne aufgewendet wird, indem:
- Die Kampagnenstruktur übersichtlicher und leichter zu überwachen ist
- Die Wartungszeit auf ein Minimum reduziert wird. Falls sich der Inhalt während der Laufzeit der Kampagne ändert, muss nicht in die Konfiguration eingegriffen werden, da die Änderungen direkt aus dem CMS stammen würden.
Architekturbeschreibung
Eine solche Konfiguration würde im Allgemeinen aus 3 Teilen bestehen:
- Anwendung – rendert den Inhalt
- CMS – enthält Kreativinhalte
- Dynamic Yield – entscheidet über auszuspielende Inhalte
Das folgende Sequenzdiagramm beschreibt die Aktionen und den Datenfluss, der mit der ersten Interaktion des Benutzers auf der Website beginnt:
Aus einer Integrationsperspektive würde die Anwendung über die Experience-API mit Dynamic Yield kommunizieren, indem sie eine Entscheidung für eine bestimmte Kampagne anfordert. Diese Anfrage würde Benutzerdaten (Benutzer-ID) enthalten, die es Dynamic Yield ermöglichen, die beste Entscheidung auf der Grundlage des Erlebnisziels innerhalb der Kampagne zu treffen.
Bevor Sie mit der Implementierung der Konfiguration beginnen, ist es wichtig zu überlegen, wie die Behandlung verschiedener Benutzergruppen (z. B. Benutzer, die sich abgemeldet haben, angemeldete Benutzer, Gäste) durchgeführt werden soll!
Konfiguration von Dynamic Yield
Alle Entscheidungen von Dynamic Yield erfolgen kampagnenbasiert. Immer, wenn eine Entscheidung von Dynamic Yield benötigt wird, muss in der Plattform eine entsprechende Kampagne hinterlegt sein, die von der Anwendung abgefragt werden kann, da Dynamic Yield Informationen nicht proaktiv senden kann. Solche Kampagnen können zahlreiche zielgerichtete Erlebnisse für die Personalisierung sowie mehrere Variationen für A/B-Tests enthalten.
Im Fall der folgenden Grafik ist jedes Erlebnis auf Benutzer in bestimmten Wetterbedingungen am aktuellen Tag ausgerichtet – Regen, Bewölkung oder Sonne. Jedes Erlebnis enthält zudem 2 Variationen, um zu testen, welcher Inhalt pro Wettertyp besser funktioniert.
Es ist bewährte Praxis, ein “Fallback”-Erlebnis einzuschließen, um sicherzustellen, dass Benutzer, die keine der anderen Bedingungen erfüllen, dennoch Inhalte sehen.
Im Gegensatz zu typischen API-Kampagnen enthalten die Variationen in Dynamic Yield z. B. keine URLs zu tatsächlichen Bannerinhalten. Stattdessen beinhaltet die Kampagnenantwort eine ID oder einen Namen des Inhalts, der im entsprechenden CMS gefunden wird.
Entscheidungsprozess
Nach Erhalt einer API-Anforderung von der Anwendung führt Dynamic Yield Berechnungen durch, um zu bestimmen, welche Inhalts-Variante angezeigt werden soll:
- Zu welchem Erlebnis gehört der Benutzer?
Die API-Anforderung an Dynamic Yield enthält jeweils eine Benutzerkennung und zusätzliche Benutzerinformationen. Dynamic Yield verwendet diese Eigenschaft, um Benutzerdaten aus Datenbanken abzurufen (zur Ausrichtung basierend auf Zielgruppe, Ereignis usw.) oder Daten aus dem Browser oder dem Standort des Benutzers auszuspielen (zur Ausrichtung basierend auf Standort, Gerät usw.) - Welche Variation sollte dem Benutzer angezeigt werden?
- Im Fall von A/B-Tests basiert die Entscheidung auf der im Erlebnis definierten Aufteilung des Traffics
- Im Fall der dynamischen Zuweisung hängt die Entscheidung davon ab, welche Variation die beste Chance hat, den Benutzer zu konvertieren.
Anschließend gibt Dynamic Yield eine Entscheidung an die Anwendung zurück, die Informationen darüber enthält, welcher Inhalt dem Benutzer angezeigt werden soll.
Darstellung des Inhalts für den Benutzer
In unserem Beispiel haben wir festgelegt, dass der Marketing-Inhalt in unserem CMS anhand der Content-ID identifiziert werden kann (z. B. 112233-sun-version_b).
Nach Erhalt der Entscheidung von Dynamic Yield ruft die Anwendung den ausgewählten Inhalt aus dem CMS ab. Je nach Integration ist dies meist eine Art von API-Anfrage, bei der die Anwendung nach einer bestimmten ID sucht und sie dem Benutzer ausspielt, sobald sie gefunden wurde.
Für eine optimale Performance empfiehlt es sich, die Entscheidung von Dynamic Yield abzurufen, bevor ein Rendervorgang auf der Website durchgeführt wird, und zwar sobald der Benutzer den ersten Kontakt mit der Anwendung herstellt. So wird ein sichtbares Flackern oder Verschieben von Inhalten minimiert
Hinzufügen von Tracking
Ein weiterer wichtiger Schritt besteht darin, Engagement-Tracking zum ausgespielten Inhalt hinzuzufügen. Dadurch werden Daten an Dynamic Yield zurückgesendet, die zeigen, wie Benutzer mit der jeweiligen Variation interagieren. Das Tracking ist wichtig für:
- Die Erfassung von Benutzerdaten zur Identifizierung spezifischer Benutzermerkmale (z. B. Benutzer, die auf Variation A klicken, bevorzugen im Allgemeinen fröhliche Nachrichten)
- Die Erfassung von Kampagnendaten zur Bestimmung des Gewinners des A/B-Tests oder zum Weiterleiten von mehr Traffic zur am besten performenden Variation bei Nutzung der dynamischen Trafficverteilung.
Die genauen Schritte zur Implementierung des Trackings sind in der Dynamic Yield API-Referenz beschrieben.
Wie Sie Ihre E-Commerce-Personalisierung mit Dynamic Yield starten
Eliza Suhareva ist Technical Team Lead bei Up Reply und hat sich auf die Bereiche Development und Solutions Architecture Consulting spezialisiert. Mit tiefgehenden technischen Kenntnissen über die Funktionen von Dynamic Yield hilft sie Kunden bei der Integration von Personalisierung und Optimierung in verschiedene Plattformen, um Kundenbindung und -engagement kanalübergreifend voranzutreiben. Im Up Reply Blog teilt Eliza Einblicke und Best Practices zur technischen Implementierung und praktische Anleitungen.
