La gestion du consentement de l'utilisateur avec Didomi

Transparency and Consent Framework

L'IAB Europe est une association au niveau européen qui travaille dans le domaine du marketing digital et de la publicité.  Cette organisation a créé le cadre Transparency and Consent Framework (TCF), une solution de consentement en conformité avec le RGPD qui standardise la collecte du consentement, surtout pour des fournisseurs de technologie publicitaire (ad tech providers). 

Les CMP qui utilisent le cadre TCF doivent permettre à l'utilisateur de faire des choix de consentement de manière granulaire et spécifique pour les finalités ainsi que pour les vendors. Vous pouvez obtenir plus d'information sur les politiques de l'IAB ici : https://iabeurope.eu/iab-europe-transparency-consent-framework-policies (Appendix B. C. c. iii)

Le comportement de la CMP de Didomi

Afin d'être en conformité avec les politiques du TCF de l'IAB, la CMP de Didomi inclut une vue "préférences" séparée de la vue "vendors", ce qui permet à l'utilisateur de faire un choix de consentement plus granulaire.  

Le statut de consentement est partagé entre les finalités et les vendors. De cette manière, pour que le tag d'un vendor soit déclenché, il faut avoir le consentement pour le vendor ainsi que pour toutes les finalités liées à ce vendor.   

Conditionnez les tags de vos custom vendors

Si vous utilisez la CMP de Didomi, vous devez conditionner les tags ou les SDKs de vos vendors personnalisés au consentement de l'utilisateur. Pour cela, vous pouvez utiliser un 📰 tag manager ou vous pouvez 📰 modifier les tags de vos vendors directement dans un environnement web. Sur app, vous devez utiliser notre API et suivre notre 📰 documentation technique. 

La meilleure façon de respecter les choix de l'utilisateur sur son consentement est d'utiliser l'ID du vendor pour conditionner les tags. Didomi vérifie les valeurs de consentement de l'utilisateur pour le vendor et, ensuite, pour les finalités liées au vendor. Si la valeur d'une des finalités liées à un vendor spécifique est à "False", la valeur du vendor sera aussi établie à "False". 

Au contraire, si vous décidez d'utiliser les finalités pour conditionner les tags de vos propres vendors, vous risquez de ne pas respecter le choix de consentement de l'utilisateur. Dans ce cas, si la valeur d'une finalité est à "True", Didomi enverra toujours la valeur comme "True" pour cette finalité, quel que soit le choix de consentement pour les vendors liés à la finalité. De cette manière, si vous conditionnez les tags à la valeur des finalités, vous pourriez les déclencher même si la valeur de consentement du vendor est à "False".

Schéma 3

L'utilisateur n'a pas donné son consentement pour une finalité liée à un vendor spécifique et affichée sur la vue "préférences". Cependant, il a accédé à la liste de vendors et il a donné son consentement pour ce vendor.   

Dans ce cas, Didomi enverra à ce vendor un statut de consentement "False". Comme il y a au moins une finalité du vendor qui a été refusée par l'utilisateur, le tag ne peut pas être déclenché.  

Schéma 4 

L'utilisateur a donné son consentement pour toutes les finalités liées à un vendor déterminé et affichées sur la vue "préférences".  Cependant, il a accédé à la liste de vendors et il a refusé le consentement pour ce vendor.  

Dans ce cas, Didomi enverra à ce vendor un statut de consentement "False". Comme le vendor a été refusé par l'utilisateur, le tag ne peut pas être déclenché. Si vous aviez conditionné le tag aux finalités, le tag aurait été déclenché même sans le consentement pour le vendor.