Consentement et identité dans la collecte de données

Le consentement et l’identité sont étroitement liés dans les implémentations de Web SDK. La manière et le moment où vous collectez le consentement affectent directement le moment et le moment où le SDK Web génère un ECID, définit des cookies d’identité et envoie des données à Edge Network. Lorsque le consentement n’est pas géré soigneusement, il en résulte souvent une inflation inattendue des visiteurs et des visiteuses, des lacunes dans la continuité de l’identité, ou les deux.

Cette page explique comment les choix de consentement interagissent avec le comportement de l’identité et fournit des conseils pour configurer votre implémentation afin d’éviter les pièges courants. Pour en savoir plus sur la façon dont le SDK Web gère les ECID, les FPID et d’autres signaux d’identité, voir Identité dans la collecte de données.

Comment le consentement affecte l’identité how-consent-affects-identity

Le SDK Web utilise à la fois la variable de configuration defaultConsent et la commande setConsent pour contrôler s’il envoie des données à Edge Network. Le statut de consentement détermine directement quand un ECID est généré et quand les cookies d’identité sont définis.

Le tableau suivant présente l’effet combiné de la defaultConsent et de la setConsent sur la collecte de données, la configuration des cookies et le comportement des identités.

Lorsqu’un visiteur accorde à nouveau son consentement après l’avoir précédemment révoqué (en appelant setConsent avec "general": "in" après "general": "out"), le SDK Web reprend l’envoi des événements et utilise l’ECID existant du cookie s’il n’a pas expiré. L’identité du visiteur est conservée.

Une fois qu’un visiteur a accordé ou refusé son consentement, le SDK Web conserve sa préférence dans un cookie de consentement kndctr_. Lors des chargements ultérieurs de la page, le SDK lit ce cookie et applique automatiquement la préférence stockée. Il n’est pas nécessaire de setConsent rappeler, sauf si la préférence du visiteur change. Notez que la valeur de configuration defaultConsent ne persiste pas entre les chargements de page, mais que le consentement résolu du visiteur (défini via setConsent) persiste.

Modèles d’implémentation implementation-patterns

Modèle Opt-in (consentement requis avant la collecte) opt-in

Utilisez ce modèle lorsque des réglementations (telles que le RGPD) exigent un consentement explicite avant de collecter des données.

alloy("configure", {
  orgId: "YOUR_ORG_ID@AdobeOrg",
  edgeDomain: "data.example.com",
  defaultConsent: "pending"
});

// When the visitor grants consent:
alloy("setConsent", {
  consent: [{
    standard: "Adobe",
    version: "1.0",
    value: { general: "in" }
  }]
});

Avec ce modèle :

Modèle d’opt-out (collection par défaut, stop on denial) opt-out

Utilisez ce modèle lorsque les réglementations autorisent la collecte de données par défaut avec une option de désinscription.

alloy("configure", {
  orgId: "YOUR_ORG_ID@AdobeOrg",
  edgeDomain: "data.example.com",
  defaultConsent: "in"
});

// If the visitor opts out:
alloy("setConsent", {
  consent: [{
    standard: "Adobe",
    version: "1.0",
    value: { general: "out" }
  }]
});

Avec ce modèle :

Consentement avec les identifiants d’appareils propriétaires consent-with-fpids

Si votre implémentation utilise des identifiants d’appareil interne (FPID), le cookie FPID est défini par votre serveur indépendamment de l’état de consentement du SDK Web. Le cookie FPID est un identifiant que vous gérez sur votre propre infrastructure. Cependant, le FPID n’est envoyé à Edge Network que lorsque le SDK Web effectue une requête (qui est validée par le consentement) :

Si votre implémentation du consentement nécessite qu’aucun identifiant ne soit défini avant le consentement, retardez la définition du cookie FPID jusqu’à ce que le consentement soit communiqué. Le point de contrôle du consentement de SDK Web seul n’empêche pas la définition du cookie FPID, puisqu’il est géré par votre serveur.

Pièges courants common-pitfalls