Utiliser Adobe Target et Web SDK pour la personnalisation
Adobe Experience Platform Web SDK peut fournir et générer des expériences personnalisées gérées dans Adobe Target sur le canal web. Vous pouvez utiliser un éditeur WYSIWYG, appelé Visual Experience Composer (VEC), ou une interface non visuelle, le compositeur d’expérience d’après les formulaires, pour créer, activer et diffuser vos activités et expériences de personnalisation.
Les fonctionnalités suivantes ont été testées et sont actuellement prises en charge dans Target :
Diagramme système Web SDK
Le diagramme suivant vous aide à comprendre le processus de prise de décision en périphérie Target et Web SDK.
b. Le contenu personnalisé pour les vues affichées à la suite d’actions de l’utilisateur dans une application d’une seule page (SPA) est mis en cache afin de pouvoir être appliqué instantanément sans appel au serveur supplémentaire lorsque les vues sont déclenchées.
c. L’Edge Network envoie l’identifiant visiteur et d’autres valeurs dans des cookies, tels que le consentement, l’ID de session, l’identité, la vérification de cookie et la personnalisation.
Activation de Adobe Target
Pour activer Target, procédez comme suit :
- Activez Target dans votre datastream avec le code client approprié.
- Ajoutez l’option
renderDecisions
à vos événements.
Vous pouvez ensuite, éventuellement, ajouter les options suivantes :
decisionScopes
: récupérez des activités spécifiques (utiles pour les activités créées avec le compositeur basé sur les formulaires) en ajoutant cette option à vos événements.- Prémasquer le fragment de code : masquez uniquement certaines parties de la page.
Utilisation du VEC d’Adobe Target
Pour utiliser le VEC avec une mise en oeuvre Web SDK, installez et activez l’extension d’assistance du VEC Firefox ou Chrome.
Pour plus d’informations, voir Extension d’assistance du compositeur d’expérience visuelle dans le guide Adobe Target.
Rendu du contenu personnalisé
Voir Rendu du contenu de personnalisation pour plus d’informations.
Audiences dans XDM
Lors de la définition d’audiences pour vos activités Target diffusées via Web SDK, XDM doit être défini et utilisé. Après avoir défini les schémas XDM, les classes et les groupes de champs de schéma, vous pouvez créer une règle d’audience Target définie par les données XDM pour le ciblage. Dans Target, les données XDM s’affichent dans Audience Builder en tant que paramètre personnalisé. Le XDM est sérialisé à l’aide de la notation par points (par exemple, web.webPageDetails.name
).
Si vous avez des activités Target avec des audiences prédéfinies qui utilisent des paramètres personnalisés ou un profil utilisateur, elles ne sont pas diffusées correctement via le SDK. Au lieu d’utiliser des paramètres personnalisés pour le profil utilisateur, vous devez utiliser XDM à la place. Cependant, il existe des champs de ciblage d’audience prêts à l’emploi pris en charge par le biais de Web SDK qui ne nécessitent pas XDM. Ces champs sont disponibles dans l’interface utilisateur Target qui ne nécessite pas XDM :
- Bibliothèque Target
- Géo
- Réseau
- Système d’exploitation
- Pages du site
- Navigateur
- Sources de trafic
- Période
Pour plus d’informations, voir Catégories d’audiences dans le guide Adobe Target.
Jetons de réponse
Les jetons de réponse sont utilisés pour envoyer des métadonnées à des tiers tels que Google ou Facebook. Les jetons de réponse sont renvoyés
dans le champ meta
de propositions
-> items
. Voici un exemple :
{
"id": "AT:eyJhY3Rpdml0eUlkIjoiMTI2NzM2IiwiZXhwZXJpZW5jZUlkIjoiMCJ9",
"scope": "__view__",
"scopeDetails": ...,
"renderAttempted": true,
"items": [
{
"id": "0",
"schema": "https://ns.adobe.com/personalization/dom-action",
"meta": {
"experience.id": "0",
"activity.id": "126736",
"offer.name": "Default Content",
"offer.id": "0"
}
}
]
}
Pour collecter les jetons de réponse, vous devez vous abonner à la promesse alloy.sendEvent
, effectuer une itération sur propositions
et extraire les détails de items
-> meta
.
Chaque proposition
possède un champ booléen renderAttempted
indiquant si le proposition
a été rendu ou non. Consultez l’exemple ci-dessous :
alloy("sendEvent",
{
"renderDecisions": true,
"decisionScopes": [
"hero-container"
]
}).then(result => {
const { propositions } = result;
// filter rendered propositions
const renderedPropositions = propositions.filter(proposition => proposition.renderAttempted === true);
// collect the item metadata that represents the response tokens
const collectMetaData = (items) => {
return items.filter(item => item.meta !== undefined).map(item => item.meta);
}
const pageLoadResponseTokens = renderedPropositions
.map(proposition => collectMetaData(proposition.items))
.filter(e => e.length > 0)
.flatMap(e => e);
});
Lorsque le rendu automatique est activé, le tableau de propositions contient :
Au chargement de la page :
- Compositeur basé sur les formulaires
propositions
avec indicateurrenderAttempted
défini surfalse
- Propositions basées sur le compositeur d’expérience visuelle avec l’indicateur
renderAttempted
défini surtrue
- Propositions basées sur le compositeur d’expérience visuelle pour une vue d’application d’une seule page avec l’indicateur
renderAttempted
défini surtrue
On View - change (pour les vues en mémoire cache) :
- Propositions basées sur le compositeur d’expérience visuelle pour une vue d’application d’une seule page avec l’indicateur
renderAttempted
défini surtrue
Lorsque le rendu automatique est désactivé, le tableau de propositions contient :
Au chargement de la page :
- Form-based Composer basé sur
propositions
avec l’indicateurrenderAttempted
défini surfalse
- Propositions basées sur Visual Experience Composer avec indicateur
renderAttempted
défini surfalse
- Visual Experience Composer propositions basées sur une vue d’application d’une seule page avec l’indicateur
renderAttempted
défini surfalse
On View - change (pour les vues en mémoire cache) :
- Propositions basées sur le compositeur d’expérience visuelle pour une vue d’application d’une seule page avec l’indicateur
renderAttempted
défini surfalse
Mise à jour d’un profil unique
Web SDK vous permet de mettre à jour le profil vers le profil Target et vers le Web SDK en tant qu’événement d’expérience.
Pour mettre à jour un profil Target, vérifiez que les données de profil sont transmises avec les éléments suivants :
- Sous
"data {"
- Sous
"__adobe.target"
- Préfixe
"profile."
renderDecisions
decisionScopes
<String>
xdm
data
Retarder l'enregistrement des paramètres de profil ou d'entité jusqu'à ce que le contenu soit affiché pour l'utilisateur final
Pour retarder l’enregistrement des attributs dans le profil jusqu’à l’affichage du contenu, définissez data.adobe.target._save=false
dans votre requête.
Par exemple, votre site web contient trois portées de décision correspondant à trois liens de catégorie sur le site web (Hommes, Femmes et Enfants) et vous souhaitez effectuer le suivi de la catégorie que l’utilisateur a finalement visitée. Envoyez ces requêtes avec l’indicateur __save
défini sur false
pour éviter de conserver la catégorie au moment de la demande du contenu. Une fois le contenu visualisé, envoyez la charge utile appropriée (y compris eventToken
et stateToken
) pour que les attributs correspondants soient enregistrés.
L’exemple ci-dessous envoie un message de style trackEvent, exécute des scripts de profil, enregistre des attributs et enregistre immédiatement l’événement.
alloy("sendEvent", {
"renderDecisions": true,
"xdm": { /* Experience Event XDM data */ },
"data": {
"__adobe": {
"target": {
" __save": true|false,
//defaults to true if omitted
"profile.gender": "female",
"profile.age": 30,
"entity.name": "T-shirt",
"entity.id": "1234"
}
}
}
})
__save
est omise, l’enregistrement des attributs de profil et d’entité se produit immédiatement. La directive __save
n’est pertinente que pour les attributs de profil et les détails d’entité.Demande de recommandations
Le tableau suivant répertorie les attributs Recommendations et indique si chacun est pris en charge via Web SDK :
Comment envoyer des attributs Recommendations à Adobe Target :
alloy("sendEvent", {
"renderDecisions": true,
"data": {
"__adobe": {
"target": {
"entity.id": "123",
"entity.genre": "Drama"
}
}
}
});
Affichage des mesures de conversion de mbox display-mbox-conversion-metrics
L’exemple ci-dessous montre comment effectuer le suivi des conversions des mbox d’affichage et envoyer des paramètres de profil à Adobe Target, sans avoir à être admissible pour un contenu ou une activité.
alloy("sendEvent", {
"xdm": {
"_experience": {
"decisioning": {
"propositions": [{
"scope": "conversion-step-1" //example scope name
}],
"propositionEventType": {
"display": 1
}
}
},
"eventType": "decisioning.propositionDisplay"
}
});
xdm._experience.decisioning.propositions[x].scope
xdm._experience.decisioning.propositions[x].eventType
"decisioning.propositionDisplay"
pour ce cas d’utilisation.Débogage
mboxTrace et mboxDebug ont été abandonnés. Utilisez plutôt une méthode de débogage du SDK Web .
Terminologie
Propositions : Dans Adobe Target, les propositions correspondent à l’expérience sélectionnée dans une activité.
Schéma : Le schéma d’une décision est le type d’offre dans Adobe Target.
Portée : Portée de la décision. Dans Adobe Target, la portée est la mBox. La mBox globale est la portée __view__
.
XDM : Le XDM est sérialisé en notation par point, puis placé dans Adobe Target en tant que paramètres mBox.