Einrichten von Adobe Target mit Platform Web SDK

Erfahren Sie, wie Sie Adobe Target mit Adobe Experience Platform Web SDK implementieren. Erfahren Sie, wie Sie Erlebnisse bereitstellen und zusätzliche Parameter an Target übergeben.

Adobe Target ist die Adobe Experience Cloud-Anwendung, die Ihnen alle Tools bereitstellt, die Sie benötigen, um das Kundenerlebnis anzupassen und zu personalisieren, damit Sie Umsätze auf Ihren Websites, mobilen Sites, Apps und anderen digitalen Kanälen maximieren können.

Lernziele

Am Ende dieser Lektion können Sie mit einer Web SDK-Implementierung von Target Folgendes durchführen:

Voraussetzungen

Um die Lektionen in diesem Abschnitt abzuschließen, müssen Sie zunächst:

Flackerhandhabung hinzufügen

Stellen Sie vor dem Start fest, ob eine zusätzliche Lösung für den Umgang mit Flackern erforderlich ist, je nachdem, wie die Tag-Bibliothek geladen wird.

Asynchrone Implementierung

Wenn eine Tag-Bibliothek asynchron geladen wird, kann das Rendern der Seite abgeschlossen sein, bevor Target den Standardinhalt durch personalisierten Inhalt ersetzt hat. Dieses Verhalten kann zu einem so genannten „Flackern“ führen, bei dem Standardinhalte kurz angezeigt werden, bevor sie durch personalisierte Inhalte ersetzt werden. Wenn Sie dieses Flackern vermeiden möchten, empfiehlt Adobe, unmittelbar vor dem asynchronen Tag-Einbettungs-Code ein spezielles pre-hiding-Snippet hinzuzufügen.

Dieses Snippet ist bereits auf der Luma-Site vorhanden. Sehen wir uns jedoch genauer an, um zu verstehen, was dieser Code tut:

<script>
  !function(e,a,n,t){var i=e.head;if(i){
  if (a) return;
  var o=e.createElement("style");
  o.id="alloy-prehiding",o.innerText=n,i.appendChild(o),setTimeout(function(){o.parentNode&&o.parentNode.removeChild(o)},t)}}
  (document, document.location.href.indexOf("adobe_authoring_enabled") !== -1, ".personalization-container { opacity: 0 !important }", 3000);
</script>

Durch das pre-hiding-Snippet wird ein Stil-Tag im Kopf der Seite mit der gewünschten CSS-Definition erstellt. Dieses Stil-Tag wird entfernt, wenn eine Antwort von Target empfangen wird oder die Zeitüberschreitung erreicht wird.

Das Pre-hiding-Verhalten wird durch zwei Konfigurationen am Ende des Snippets gesteuert.

Das pre-hiding-Snippet ist auch in Tags verfügbar:

Synchrone Implementierung

Adobe empfiehlt, Tags asynchron zu implementieren, wie auf der Luma-Site gezeigt. Wenn die Tag-Bibliothek jedoch synchron geladen wird, ist das pre-hiding-Snippet nicht erforderlich. Stattdessen wird der Stil zum Vorab-Ausblenden in den Erweiterungsparametern der Platform Web SDK festgelegt.

Der Stil zum Vorab-Ausblenden für synchrone Implementierungen kann wie folgt konfiguriert werden:

Weitere Informationen zur Verwaltung von Flackern in Platform Web SDK finden Sie im Abschnitt Handbuch: von Flackern für personalisierte Erlebnisse.

Konfigurieren des Datenstroms

Target muss in der Datenstromkonfiguration aktiviert sein, bevor Target-Aktivitäten von Platform Web SDK bereitgestellt werden können.

So konfigurieren Sie Target im Datenstrom:

Eigenschafts-Token

Target Premium-Kunden haben die Möglichkeit, Benutzerberechtigungen mit Eigenschaften zu verwalten. Mit den Target-Eigenschaften können Sie Grenzen für Benutzerinnen und Benutzer festlegen, an denen Target-Aktivitäten ausgeführt werden können. Weitere Informationen finden Sie AbschnittEnterprise-Berechtigungen“ in der Target-Dokumentation.

Um Eigenschafts-Token einzurichten oder zu finden, navigieren Sie zu Adobe Target > Administration > Eigenschaften. Das Symbol </> zeigt den Implementierungs-Code an. Der at_property Wert ist das Eigenschafts-Token, das Sie in Ihrem Datenstrom verwenden würden.

Pro Datenstrom kann nur ein Eigenschafts-Token angegeben werden, aber mit Eigenschafts-Token-Überschreibungen können Sie alternative Eigenschafts-Token angeben, die das im Datenstrom definierte primäre Eigenschafts-Token ersetzen. Außerdem ist eine Aktualisierung der sendEvent Aktion erforderlich, um den Datenstrom zu überschreiben.

Zielumgebungs-ID

Umgebungen in Target helfen Ihnen in allen Entwicklungsphasen bei der Implementierung. Diese optionale Einstellung gibt an, welche Zielumgebung für jeden Datenstrom verwendet werden soll.

Adobe empfiehlt, die Zielumgebungs-ID für jeden Entwicklungs-, Staging- und Produktionsdatenstrom unterschiedlich festzulegen, um die Dinge einfach zu halten. Alternativ können Sie Ihre Umgebungen in der Benutzeroberfläche von Target mithilfe der Funktion hosts organisieren.

Um Umgebungs-IDs einzurichten oder zu finden, navigieren Sie zu Adobe Target > Administration > Umgebungen.

Namespace der Target-Drittanbieter-ID

Mit dieser optionalen Einstellung können Sie angeben, welches Identitätssymbol für die Target-Drittanbieter-ID verwendet werden soll. Target unterstützt nur die Profilsynchronisierung für ein einzelnes Identitätssymbol oder einen Namespace. Weitere Informationen finden Sie im Abschnitt Echtzeit-Profilsynchronisierung für mbox3rdPartyId des Target-Handbuchs.

Die Identitätssymbole befinden sich in der Identitätsliste unter Datenerfassung > Kunde > Identitäten.

Für dieses Tutorial zur Verwendung der Luma-Site verwenden Sie das Identitätssymbol, lumaCrmId während der Lektion über (Identitäten eingerichtet.

Rendern von visuellen Personalisierungsentscheidungen

Visuelle Personalisierungsentscheidungen beziehen sich auf die in Visual Experience Composer von Adobe Target erstellten Erlebnisse. Zunächst sollten Sie die in den Schnittstellen von Target und Tags verwendete Terminologie verstehen:

Aktualisieren der Aktion Ereignis senden

Visuelle Personalisierungsentscheidungen aus Target werden von Platform Web SDK bereitgestellt, wenn Target im Datenstrom aktiviert ist. Sie jedoch nicht automatisch gerendert. Sie müssen die Aktion Ereignis senden aktualisieren, um das automatische Rendering zu aktivieren.

Mit der Einstellung Visuelle Personalisierungsentscheidungen rendern wendet Platform Web SDK automatisch alle Änderungen an, die mit dem Visual Experience Composer oder der globalen Mbox von Target angegeben wurden.

Wenn Sie es vorziehen, diese Entscheidungen selbst mit benutzerdefiniertem Code zu rendern oder zu bearbeiten, können Sie die Einstellung Visuelle Personalisierungsentscheidungen rendern deaktiviert lassen. Platform Web SDK ist flexibel und bietet diese Funktion, um Ihnen vollständige Kontrolle zu geben. Weitere Informationen zum manuellen Rendern personalisierter Inhalte Sie im Handbuch.

Einrichten einer Target-Aktivität mit dem Visual Experience Composer

Nachdem die grundlegende Implementierung abgeschlossen ist, erstellen Sie eine Experience Targeting (XT)-Aktivität in Target, um zu überprüfen, ob alles ordnungsgemäß funktioniert. Weitere Informationen finden Sie im Target-Tutorial zum Erstellen Experience TargetingAktivitäten .

Validieren mit dem Debugger

Wenn Sie eine Aktivität einrichten, sollte der Inhalt auf der Seite gerendert werden. Selbst wenn keine Aktivitäten aktiv sind, können Sie sich jedoch auch den Netzwerkaufruf „Ereignis senden“ ansehen, um zu bestätigen, dass Target ordnungsgemäß konfiguriert ist.

Einrichten und Rendern eines benutzerdefinierten Entscheidungsumfangs

Benutzerdefinierte Entscheidungsumfänge (ehemals als „Mboxes“ bezeichnet) können verwendet werden, um HTML- oder JSON-Inhalte mithilfe des formularbasierten Experience Composers von Target strukturiert bereitzustellen. Inhalte, die für einen dieser benutzerdefinierten Bereiche bereitgestellt werden, werden von Platform Web SDK nicht automatisch gerendert. Sie kann mithilfe einer Aktion in Tags gerendert werden.

Fügen Sie der Aktion „Ereignis senden“ einen Bereich ​

Ändern Sie Ihre Seitenladeregel, um einen benutzerdefinierten Entscheidungsumfang hinzuzufügen:

Verarbeiten der Target-Antwort

Nachdem Sie nun Platform Web SDK so konfiguriert haben, dass Inhalte für den homepage-hero angefordert werden, müssen Sie etwas mit der Antwort tun. Die Tag-Erweiterung von Platform Web SDK bietet ein send event complete-Ereignis, mit dem sofort eine neue Regel Trigger werden kann, wenn eine Antwort von einer „send event–Aktion eingeht.

Einrichten einer Target-Aktivität mit dem formularbasierten Experience Composer

Nachdem Sie nun über eine Regel zum manuellen Rendern eines benutzerdefinierten Entscheidungsumfangs verfügen, können Sie in Target eine weitere Experience Targeting-(XT)-Aktivität erstellen. Verwenden Sie dieses Mal den formularbasierten Experience Composer.

Validieren mit dem Debugger

Wenn Sie Ihre Aktivität aktiviert haben, sollte der gerenderte Inhalt auf der Seite angezeigt werden. Selbst wenn keine Aktivitäten live sind, können Sie sich jedoch auch den Netzwerkaufruf Ereignis senden ansehen, um zu bestätigen, dass Target Inhalte für Ihre benutzerdefinierten Bereiche anfordert.

Parameter an Target senden

In diesem Abschnitt übergeben Sie Target-spezifische Daten und sehen sich genauer an, wie XDM-Daten den Target-Parametern zugeordnet werden.

Seitenparameter (Mbox) und XDM

Alle XDM-Felder werden automatisch als Seitenparameter oder Mbox-Parameter an Target übergeben.

Einige dieser XDM-Felder werden speziellen Objekten im Backend von Target zugeordnet. Beispielsweise stehen web.webPageDetails.URL beim Erstellen von Profilskripten automatisch zum Erstellen URL-basierter Zielgruppenbestimmungsbedingungen oder als page.url zur Verfügung.

Sie können Seitenparameter auch mithilfe des Datenobjekts hinzufügen.

Spezielle Parameter und das Datenobjekt

Es gibt einige Datenpunkte, die für Target nützlich sein können und nicht vom XDM-Objekt zugeordnet sind. Zu diesen speziellen Zielgruppen-Parametern gehören:

Diese Parameter müssen im data-Objekt gesendet werden, anstatt im xdm-Objekt. Darüber hinaus können auch Seiten- (oder Mbox-)Parameter in das data-Objekt aufgenommen werden.

Um das Datenobjekt auszufüllen, erstellen Sie das folgende Datenelement und verwenden Sie Datenelemente wieder, die in der Lektion Datenelemente erstellen erstellt wurden:

Aktualisieren der Seitenladeregel

Wenn Sie zusätzliche Daten für Target außerhalb des XDM-Objekts übergeben möchten, müssen alle anwendbaren Regeln aktualisiert werden. In diesem Beispiel müssen Sie nur das neue Datenelement data.content in die allgemeine Seitenladeregel und die Produktseitenansichtsregel einbeziehen.

Aufteilen von Personalization- und Analytics-Anfragen

Die Datenschicht auf der Luma-Site wird vollständig definiert, bevor der Tag-Einbettungs-Code verwendet wird. Auf diese Weise können wir mit einem einzigen Aufruf personalisierte Inhalte abrufen (z. B. aus Adobe Target) und Analysedaten senden (z. B. an Adobe Analytics).

Auf vielen Websites kann die Datenschicht jedoch nicht früh genug oder schnell genug geladen werden, um für beide Anwendungen einen einzigen Aufruf zu verwenden. In diesen Situationen können Sie zwei Aktionen vom Typ Ereignis senden auf einer einzelnen Seite verwenden und die erste für die Personalisierung und die zweite für die Analyse verwenden. Wenn Sie die Ereignisse auf diese Weise aufteilen, kann das Personalisierungsereignis so früh wie möglich ausgelöst werden, während Sie warten, bis die Datenschicht vollständig geladen ist, bevor Sie das Analytics-Ereignis senden. Dies ist ähnlich wie bei vielen SDK-Implementierungen vor dem Web, bei denen Adobe Target den target-global-mbox oben auf der Seite und Adobe Analytics den s.t()-Aufruf unten auf der Seite auslöste

So erstellen Sie die „Personalization-on-top“-Anfrage:

So erstellen Sie die Analytics-On-Bottom-Anfrage:

Validieren mit dem Debugger

Nachdem die Regeln aktualisiert wurden, können Sie mithilfe des Adobe Debuggers überprüfen, ob die Daten korrekt weitergeleitet werden.

Validieren in der Target-Oberfläche

Überprüfen Sie anschließend in der Target-Oberfläche, ob Daten empfangen wurden und für die Verwendung in Zielgruppen und Aktivitäten verfügbar sind. XDM-Daten werden automatisch benutzerdefinierten Target-Parametern zugeordnet. Sie können überprüfen, ob XDM-Daten von Target empfangen wurden und verfügbar sind, indem Sie eine Zielgruppe erstellen.

Überprüfen Sie als Nächstes, ob das Profilattribut für den Anmeldestatus erfolgreich übergeben wurde.

Wenn Sie über Target Premium verfügen, können Sie auch überprüfen, ob die Entitätsdaten korrekt übergeben und die Produktdaten in den Recommendations-Produktkatalog geschrieben wurden.

Mit Assurance validieren

Darüber hinaus können Sie bei Bedarf Assurance verwenden, um zu bestätigen, dass Target-Entscheidungsanfragen die richtigen Daten erhalten und dass alle Server-seitigen Transformationen korrekt ausgeführt werden. Sie können auch bestätigen, dass die Kampagnen- und Erlebnisinformationen in den Adobe Analytics-Aufrufen enthalten sind, selbst wenn die Target-Entscheidungsaufrufe und die Adobe Analytics-Aufrufe separat gesendet werden.

Dadurch wird bestätigt, dass die A4T-Informationen, die zur späteren Übermittlung in die Warteschlange gestellt wurden, als der Target Decisioning-Aufruf durchgeführt wurde, ordnungsgemäß gesendet wurden, als der Analytics-Tracking-Aufruf später auf der Seite ausgelöst wurde.

Nachdem Sie nun diese Lektion abgeschlossen haben, sollten Sie über eine funktionierende Implementierung von Adobe Target mit der Platform Web SDK verfügen.

Weiter: