Envoyez des mises à jour de lignes partielles à Real-Time Customer Profile à l’aide de Data Prep
-
L’ingestion des messages de mise à jour d’entité du modèle de données d’expérience (XDM) (avec les opérations du PATCH JSON) pour les mises à jour de profil via l’inlet du DCS a été abandonnée. Suivez les étapes décrites dans ce guide en tant qu’alternative.
-
Vous pouvez également utiliser la source d’API HTTP pour ingérer des données brutes dans l’inlet du serveur de collecte de données et spécifier les mappages de données nécessaires pour transformer vos données en messages compatibles XDM pour les mises à jour de Profile.
-
Lors de l’utilisation de tableaux dans des serveurs de diffusion en continu, vous devez utiliser explicitement
upsert_array_append
ouupsert_array_replace
pour définir l’intention claire de l’opération. Vous pouvez recevoir des erreurs si ces fonctions sont manquantes.
Utilisez des upserts de diffusion en continu dans Data Prep pour envoyer des mises à jour de lignes partielles aux données Real-Time Customer Profile tout en créant et en établissant de nouveaux liens d’identité avec une seule requête API.
En diffusant en continu des upserts, vous pouvez conserver le format de vos données tout en convertissant ces données en demandes de PATCH Real-Time Customer Profile pendant l’ingestion. En fonction des entrées que vous fournissez, Data Prep vous permet d’envoyer une seule charge utile API et de traduire les données vers les requêtes Real-Time Customer Profile PATCH et Identity Service CREATE.
Data Prep utilise des paramètres d’en-tête pour faire la distinction entre les insertions et les upserts. Toutes les lignes qui utilisent des upserts doivent comporter un en-tête . Vous pouvez utiliser des upserts avec ou sans descripteurs d’identité. Si vous utilisez des upserts avec des identités, vous devez suivre les étapes de configuration décrites dans la section configuration du jeu de données d’identité. Si vous utilisez des upserts sans identités, vous n’avez pas besoin de fournir de configurations d’identité dans votre requête. Pour plus d’informations, consultez la section sur les upserts de diffusion en continu sans identités .
Ce document fournit des informations sur la diffusion en continu de upserts dans Data Prep.
Prise en main
Cette présentation d’ nécessite une compréhension professionnelle des composants suivants d’Adobe Experience Platform :
- Data Prep : Data Prep permet aux ingénieurs de données de mapper, de transformer et de valider des données vers et depuis le modèle de données d’expérience (XDM).
- Identity Service : profitez d’une meilleure vue d’ensemble des clients et de leur comportement en rapprochant des identités entre appareils et systèmes.
- Real-Time Customer Profile : fournit un profil client en temps réel unifié basé sur des données agrégées issues de plusieurs sources.
- Sources : Experience Platform permet d’ingérer des données provenant de diverses sources tout en vous offrant la possibilité de structurer, de libeller et d’améliorer les données entrantes à l’aide des services de Platform.
Utilisation de serveurs de diffusion en continu dans Data Prep streaming-upserts-in-data-prep
Workflow de haut niveau des upserts en flux continu
Les upserts de diffusion en continu dans Data Prep fonctionnent comme suit :
-
Vous devez d’abord créer et activer un jeu de données pour la consommation Profile. Pour plus d’informations, consultez le guide sur l’ activation d’un jeu de données pour Profile .
-
Si de nouvelles identités doivent être liées, vous devez également créer un jeu de données supplémentaire avec le même schéma que votre jeu de données Profile.
-
Une fois vos jeux de données préparés, vous devez créer un flux de données pour mapper votre requête entrante au jeu de données Profile.
-
Vous devez ensuite mettre à jour la requête entrante afin d’inclure les en-têtes nécessaires. Ces en-têtes définissent :
- L’opération de données à effectuer avec Profile :
create
,merge
etdelete
. - Opération d’identité facultative à effectuer avec Identity Service :
create
.
- L’opération de données à effectuer avec Profile :
Configuration du jeu de données d’identité configure-the-identity-dataset
Si de nouvelles identités doivent être liées, vous devez créer et transmettre un jeu de données supplémentaire dans la payload entrante. Lors de la création d’un jeu de données d’identité, vous devez vous assurer que les conditions suivantes sont remplies :
- Le jeu de données d’identité doit avoir son schéma associé comme jeu de données Profile. Une incohérence des schémas peut entraîner un comportement du système incohérent.
- Cependant, vous devez vous assurer que le jeu de données d’identité est différent du jeu de données Profile. Si les jeux de données sont identiques, les données seront écrasées au lieu d’être mises à jour.
- Bien que le jeu de données initial doive être activé pour Profile, le jeu de données d’identité ne doit pas être activé pour Profile. Dans le cas contraire, les données seront également écrasées au lieu d’être mises à jour. Cependant, le jeu de données d’identité doit être activé pour Identity Service.
Champs obligatoires dans les schémas associés au jeu de données d’identité identity-dataset-required-fileds
Si votre schéma contient des champs obligatoires, la validation du jeu de données doit être supprimée pour permettre à Identity Service de recevoir uniquement les identités. Vous pouvez supprimer la validation en appliquant la valeur disabled
au paramètre acp_validationContext
. Voir l’exemple ci-dessous :
curl -X POST 'https://platform.adobe.io/data/foundation/catalog/dataSets/62257bef7a75461948ebcaaa' \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {IMS_ORG}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-d '{
"tags": {
"acp_validationContext": [
"disabled"
],
"unifiedProfile": [
"enabled:false"
],
"unifiedIdentity": [
"enabled:true"
]
}
}'
Structure de payload entrante
L’exemple suivant illustre une structure de payload entrante établissant de nouveaux liens d’identité.
Payload avec configuration d’identité
{
"header": {
"flowId": "923e2ac3-3869-46ec-9e6f-7012c4e23f69",
"imsOrgId": "{ORG_ID}",
"datasetId": "621fc19ab33d941949af16c8",
"operations": {
"data": "create" (default)/"merge"/"delete",
"identity": "create",
"identityDatasetId": "621fc19ab33d941949af16d9"
}
}
... //The raw data attributes are included here as the key/value pairs of the "body" property.
}
flowId
datasetId
.imsOrgId
datasetId
operations
operations.data
operations.identity
operations.identityDatasetId
Opérations prises en charge
Les opérations suivantes sont prises en charge par Real-Time Customer Profile :
create
merge
delete
Les opérations suivantes sont prises en charge par Identity Service :
create
create
est transmis en tant que valeur pour operations.identity
, alors Data Prep génère une requête de création d’entité XDM pour Identity Service. Si l’identité existe déjà, l’identité est ignorée. Remarque : Si operations.identity
est défini sur create
, le identityDatasetId
doit également être spécifié. L’entité XDM crée un message généré en interne par le composant Data Prep sera généré pour cet identifiant de jeu de données.Charge utile sans configuration d’identité payload-without-identity-configuration
Si de nouvelles identités ne doivent pas être liées, vous pouvez omettre les paramètres identity
et identityDatasetId
dans les opérations. Cela envoie uniquement des données à Real-Time Customer Profile et ignore Identity Service. Voir la payload ci-dessous pour obtenir un exemple :
{
"header": {
"flowId": "923e2ac3-3869-46ec-9e6f-7012c4e23f69",
"imsOrgId": "{ORG_ID}",
"datasetId": "621fc19ab33d941949af16c8",
"operations": {
"data": "create"/"merge"/"delete",
}
}
... //The raw data attributes are included here as the key/value pairs of the "body" property.
}
Transmission dynamique des identités primaires
Pour les mises à jour XDM, le schéma doit être activé pour Profile et contenir une identité principale. Vous pouvez spécifier l’identité principale d’un schéma XDM de deux manières :
- Désigner un champ statique comme identité principale dans le schéma XDM ;
- Désignez l’un des champs d’identité comme identité principale par le biais du groupe de champs de carte d’identité dans le schéma XDM.
Désigner un champ statique comme champ d’identité principal dans le schéma XDM
Dans l’exemple ci-dessous, state
, homePhone.number
et d’autres attributs sont mis à jour avec leurs valeurs respectives données dans le Profile avec l’identité principale de sampleEmail@gmail.com
. Un message de mise à jour d’entité XDM est ensuite généré par le composant de diffusion en continu Data Prep. Real-Time Customer Profile confirme ensuite le message de mise à jour XDM pour insérer l’enregistrement de profil.
curl -X POST 'https://dcs.adobedc.net/collection/9aba816d350a69c4abbd283eb5818ec3583275ffce4880ffc482be5a9d810c4b' \
-H 'Content-Type: application/json' \
-H 'x-adobe-flow-id: d5262d48-0f47-4949-be6d-795f06933527' \
-d '{
"header": {
"flowId" : "d5262d48-0f47-4949-be6d-795f06933527",
"imsOrgId": "{ORG_ID}",
"datasetId": "62259f817f62d71947929a7b",
"operations": {
"data": "create"
}
},
{
"body": {
"homeAddress": {
"country": "US",
"state": "GA",
"region": "va7"
},
"homePhone": {
"number": "123.456.799"
},
"identityMap": {
"Email": [{
"id": "sampleEmail@gmail.com",
"primary": true
}]
},
"personalEmail": {
"address": "sampleEmail@gmail.com",
"primary": true
},
"personID": "346576345",
"_id": "346576345",
"timestamp": "2021-05-05T17:51:45.1880+02",
"workEmail": "sampleWorkEmail@gmail.com"
}
}'
Désigner l’un des champs d’identité comme identité principale par le biais du groupe de champs de carte d’identité dans le schéma XDM
Dans cet exemple, l’en-tête contient l’attribut operations
avec les propriétés identity
et identityDatasetId
. Cela permet de fusionner les données avec Real-Time Customer Profile et de transmettre les identités à Identity Service.
curl -X POST 'https://dcs.adobedc.net/collection/9aba816d350a69c4abbd283eb5818ec3583275ffce4880ffc482be5a9d810c4b' \
-H 'Content-Type: application/json' \
-H 'x-adobe-flow-id: d5262d48-0f47-4949-be6d-795f06933527' \
-d '{
"header": {
"flowId" : "d5262d48-0f47-4949-be6d-795f06933527",
"imsOrgId": "{ORG_ID}",
"datasetId": "62259f817f62d71947929a7b",
"operations": {
"data": "merge",
"identity": "create",
"identityDatasetId": "6254a93b851ecd194b64af9e"
}
},
{
"body": {
"homeAddress": {
"country": "US",
"state": "GA",
"region": "va7"
},
"homePhone": {
"number": "123.456.799"
},
"identityMap": {
"Email": [{
"id": "sampleEmail@gmail.com",
"primary": true
}]
},
"personalEmail": {
"address": "sampleEmail@gmail.com",
"primary": true
},
"personID": "346576345",
"_id": "346576345",
"timestamp": "2021-05-05T17:51:45.1880+02",
"workEmail": "sampleWorkEmail@gmail.com"
}
}'
Limites connues et considérations clés
Voici une liste des limites connues à prendre en compte lors de la diffusion en continu de upserts avec Data Prep :
- La méthode des upserts de diffusion ne doit être utilisée que lors de l’envoi de mises à jour de lignes partielles à Real-Time Customer Profile. Les mises à jour de lignes partielles sont et non consommées par le lac de données.
- La méthode de diffusion en continu upserts ne prend pas en charge la mise à jour, le remplacement et la suppression des identités. De nouvelles identités sont créées si elles n’existent pas. Par conséquent, l’opération
identity
doit toujours être définie pour créer. Si une identité existe déjà, l’opération est un "no-op". - La méthode des upserts de diffusion en continu ne prend actuellement pas en charge Adobe Experience Platform Web SDK et Adobe Experience Platform Mobile SDK.
Étapes suivantes
En lisant ce document, vous devez maintenant comprendre comment diffuser des upserts dans Data Prep pour envoyer des mises à jour de lignes partielles à vos données Real-Time Customer Profile, tout en créant et en liant des identités à une seule requête API. Pour plus d'informations sur les autres fonctionnalités Data Prep, consultez la Data Prep présentation. Pour savoir comment utiliser les ensembles de mappages dans l’API Data Prep, consultez le Data Prep guide de développement.