Type de données Consentements et préférences
Créé pour :
- Développeur
Le type de données Consentement pour les préférences de confidentialité, de Personalization et de marketing (ci-après dénommé « type de données Consentements et préférences ») est un type de données Experience Data Model (XDM) destiné à prendre en charge la collecte des autorisations et des préférences des clients générées par les plateformes de gestion du consentement (CMP) et d’autres sources à partir de vos opérations de données.
Ce document couvre la structure et l’utilisation prévue des champs fournis par le type de données Consentements et préférences .
Conditions préalables
Ce document nécessite une compréhension pratique de XDM et de l’utilisation des schémas dans Experience Platform. Veuillez consulter la documentation suivante avant de continuer :
Structure du type de données
Le type de données Consentements et préférences fournit plusieurs champs utilisés pour capturer des informations de consentement et préférence.
Le consentement est une option qui permet à un client ou une cliente de spécifier comment ses données peuvent être utilisées. La plupart des consentements ont un aspect juridique, en ce sens que certaines juridictions exigent l'obtention d'une autorisation avant que les données puissent être utilisées d'une manière particulière, ou exigent que le client ait une option pour arrêter cette utilisation (opt-out) si un consentement affirmatif n'est pas requis.
Une préférence est une option qui permet au client ou à la cliente de spécifier comment différents aspects de son expérience avec une marque doivent être traités. Elles se répartissent en deux catégories :
- Préférences Personalization : préférences concernant la manière dont la marque doit personnaliser les expériences diffusées à un client.
- Préférences marketing : préférences concernant l’autorisation ou non d’une marque à contacter un client par le biais de divers canaux.
La capture d’écran suivante montre comment la structure du type de données est représentée dans l’interface utilisateur d’Experience Platform :
Le fichier JSON suivant illustre un exemple du type de données que le type de données Consentements et préférences peut traiter. Vous trouverez des informations sur l’utilisation spécifique de chacun de ces champs dans les sections suivantes.
{
"consents": {
"collect": {
"val": "VI",
},
"adID": {
"idType": "IDFA",
"val": "y"
},
"share": {
"val": "y",
},
"personalize": {
"content": {
"val": "y"
}
},
"marketing": {
"preferred": "email",
"any": {
"val": "u"
},
"push": {
"val": "n",
"reason": "Too Frequent",
"time": "2019-01-01T15:52:25+00:00"
}
},
"metadata": {
"time": "2019-01-01T15:52:25+00:00"
}
}
}
consents
consents
contient plusieurs champs qui décrivent les consentements et les préférences d’un client ou d’une cliente. Ces champs sont décrits en détail dans les sous-sections ci-dessous.
"consents": {
"collect": {
"val": "VI",
},
"adID": {
"idType": "IDFA",
"val": "y"
},
"share": {
"val": "y",
},
"personalize": {
"content": {
"val": "y"
}
},
"marketing": {
"preferred": "email",
"any": {
"val": "u"
},
"email": {
"val": "n",
"reason": "Too Frequent",
"time": "2019-01-01T15:52:25+00:00"
}
}
}
collect
collect
représente le consentement du client pour la collecte de ses données.
"collect": {
"val": "y"
}
val
adID
adID
représente le consentement du client pour savoir si un ID d’annonceur peut être utilisé pour lier le client dans les applications sur cet appareil.
"adID": {
"idType": "IDFA",
"val": "y"
}
idType
IDFA
pour l’ID d’Apple pour les annonceurs ou GAID
pour l’ID d’annonceur Google, également appelé ID d’annonceur Android (AAID).val
share
share
représente le consentement du client quant à savoir si ses données peuvent être partagées avec (ou vendues à) des secondes ou des tiers.
"share": {
"val": "y"
}
val
personalize
personalize
capture les préférences des clients concernant les façons dont leurs données peuvent être utilisées pour la personnalisation. Les clients peuvent se désabonner de cas d’utilisation de personnalisation spécifiques, ou se désabonner entièrement de la personnalisation.
personalize
ne couvre pas les cas d’utilisation marketing. Par exemple, si un client choisit de ne pas utiliser la personnalisation pour tous les canaux, il ne doit pas cesser de recevoir des communications par ces canaux. Les messages qu’ils reçoivent doivent être génériques et non basés sur leur profil.marketing
, comme expliqué dans la section suivante), il ne doit pas recevoir de messages, même si la personnalisation est autorisée."personalize": {
"content": {
"val": "y",
}
}
content
val
marketing
marketing
capture les préférences des clients concernant les objectifs marketing pour lesquels leurs données peuvent être utilisées. Les clients peuvent se désabonner de cas d’utilisation marketing spécifiques, ou se désabonner entièrement du marketing direct.
"marketing": {
"preferred": "email",
"any": {
"val": "u"
},
"email": {
"val": "n",
"reason": "Too Frequent"
},
"push": {
"val": "y"
},
"sms": {
"val": "y"
}
}
preferred
any
marketing
. Si vous prévoyez d’utiliser des options de consentement plus granulaires, il est recommandé d’exclure ce champ.Si la valeur est définie sur
n
, tous les paramètres de personnalisation plus spécifiques doivent être ignorés. Si la valeur est définie sur y
, toutes les options de personnalisation plus précises doivent également être traitées comme des y
, sauf si elles sont explicitement définies sur n
. Si la valeur n’est pas définie, les valeurs de chaque option de personnalisation doivent être respectées comme spécifié.email
push
sms
val
time
metadata
, ce champ ne doit pas être défini pour cette préférence.reason
metadata
metadata
capture les métadonnées générales concernant les consentements et préférences du client ou de la cliente à chaque dernière mise à jour.
"metadata": {
"time": "2019-01-01T15:52:25+00:00",
}
time
time
sous une préférence individuelle remplace l’horodatage metadata
de cette préférence particulière.Ingestion de données à l’aide du type de données
Pour utiliser le type de données Consentements et préférences afin d’ingérer les données de consentement de vos clients, vous devez créer un jeu de données basé sur un schéma contenant ce type de données.
Consultez le tutoriel sur la création d’un schéma dans l’interface utilisateur pour savoir comment attribuer des types de données aux champs. Une fois que vous avez créé un schéma contenant un champ avec le type de données Consentements et préférences, reportez-vous à la section relative à la création d’un jeu de données dans le guide d’utilisation des jeux de données, en suivant les étapes de création d’un jeu de données avec un schéma existant.
Gérer les modifications de consentement et de préférence
Lorsqu’un client modifie ses consentements ou ses préférences sur votre site web, ces modifications doivent être collectées et immédiatement appliquées à l’aide de Adobe Experience Platform Web SDK. Si un client se désinscrit de la collecte de données, toute collecte de données doit immédiatement cesser. Si un client refuse la personnalisation, aucune personnalisation ne doit figurer sur la page suivante qu’il visite.
Annexe
Les sections ci-dessous fournissent des informations de référence supplémentaires concernant le type de données Consentements et préférences.
Valeurs acceptées pour val
Le tableau suivant décrit les valeurs acceptées pour val
:
y
n
p
p
jusqu’à ce qu’il sélectionne un lien dans un e-mail pour vérifier qu’il a fourni la bonne adresse e-mail. À ce stade, le consentement est mis à jour sur y
.Si ce consentement ou cette préférence n’utilise pas un processus de vérification à deux ensembles, le choix
p
peut alors être utilisé pour indiquer que le client n’a pas encore répondu à l’invite de consentement. Par exemple, vous pouvez définir automatiquement la valeur sur p
sur la première page d’un site web, avant que le client n’ait répondu à l’invite de consentement. Dans les juridictions qui n’exigent pas de consentement explicite, vous pouvez également l’utiliser pour indiquer que le client ne s’est pas explicitement opposé (en d’autres termes, le consentement est présumé).Bien que cette valeur puisse être ingérée dans le Profile à l’aide d’autres mécanismes, tels que l’ingestion par flux, elle n’est pas prise en charge pour la collecte de données ou la collecte de consentement sur Edge Network. Bien que la valeur
p
ne puisse pas être envoyée explicitement, la file d’attente des événements est toujours gérée par le Web SDK et l’événement est distribué à Edge Network une fois le consentement de l’utilisateur final explicitement in
.u
dy
Notez que si des lois ou des modifications apportées à la politique de confidentialité de votre entreprise entraînent des modifications des valeurs par défaut de certains utilisateurs ou de tous les utilisateurs, vous devez mettre à jour manuellement tous les profils contenant des valeurs par défaut.
dn
Notez que si des lois ou des modifications apportées à la politique de confidentialité de votre entreprise entraînent des modifications des valeurs par défaut de certains utilisateurs ou de tous les utilisateurs, vous devez mettre à jour manuellement tous les profils contenant des valeurs par défaut.
LI
CT
CP
VI
PI
Valeurs acceptées pour preferred
Le tableau suivant décrit les valeurs acceptées pour preferred
. Les valeurs preferred
indiquent le canal préféré du client ou de la cliente pour recevoir des communications qui l’informeraient sur la collecte de données, les politiques de confidentialité et les options de personnalisation.
email
push
inApp
sms
phone
phyMail
inVehicle
inHome
iot
social
other
none
unknown
Schéma complet Consentements et préférences
Pour afficher le schéma complet du type de données Consentements et préférences, reportez-vous à la section référentiel XDM officiel.