La gestion de la preuve de consentement chez Didomi

🔎 Didomi stocke les preuves de consentement de tous vos utilisateurs. Pour cela, nous stockons deux types d'information :

  • l'information sur l'utilisateur ;
  • sa preuve individuelle de consentement ainsi que la configuration de la notice au moment oĂą la preuve de consentement a Ă©tĂ© collectĂ©e.

👉Si vous avez besoin de rĂ©cupĂ©rer les preuves de consentement de manière frĂ©quente, notre fonctionnalitĂ© batch export vous permet de recevoir les consentements quotidiennement, car nous exportons et envoyons les informations du consentement des utilisateurs tous les jours. Vous pouvez consulter đź“° notre documentation technique.

👉Si vous n'utilisez pas notre batch export et qu'un utilisateur veut recevoir sa preuve individuelle de consentement, vous pouvez nous envoyer la demande à support@didomi.io. Nous vous fournirons toute l'information nécessaire sur le consentement de l'utilisateur et vous pourrez obtenir la configuration de la notice grâce à l'API.

👉Par ailleurs, si la demande provient d'une autorité de contrôle, Didomi est en mesure de vous fournir les preuves individuelles de consentement de tous vos utilisateurs, ainsi que toutes les configurations de la notice déployée sur le domaine contrôlé.

Dans ce cas, nous suivons cette procédure :
âś… Didomi fait un export complet de notre base grâce Ă  l'API.

✅ Vous pourrez de votre côté télécharger les versions des notices grâce à l'API (seulement si vous utilisez la console pour gérer vos notices).

L'information de l'utilisateur et sa preuve individuelle de consentement

Nous stockons l'information sur l'utilisateur grâce à un cookie qui contient un identifiant utilisateur. Nous utilisons cet ID pour obtenir la preuve individuelle de consentement de l'utilisateur.

Pour obtenir plus d'information sur les cookies stockés par Didomi, consultez cet article.

Si un utilisateur demande sa preuve de consentement, il devra retrouver son ID utilisateur. Cet article vous explique les Ă©tapes Ă  suivre.

Quand vous l'aurez obtenu, envoyez-nous votre demande de preuve de consentement avec l'ID utilisateur Ă  l'adresse support@didomi.io. Nous vous enverrons ensuite un document avec l'information suivante :

â—Ź  id : ID unique de l'Ă©vĂ©nement

â—Ź  type : type d'Ă©vĂ©nement

â—Ź  datehour : date et heure de l'Ă©vĂ©nement au format AAAAMM-JJ-HH

â—Ź  timestamp : heure unix de l'Ă©vĂ©nement (en millisecondes)

â—Ź  Datetime : date et heure de l'Ă©vĂ©nement au format AAAAMM-JJ-HH:mm:ss

â—Ź  Namespace : espace de nom de l'Ă©vĂ©nement (sdk pour les Ă©vĂ©nements SDK)

â—Ź  Rate : taux d'Ă©chantillonnage pour l'Ă©vĂ©nement (1/taux vous donnera le compte rĂ©el)

â—Ź  apikey : clef API de l'Ă©vĂ©nement

â—Ź  source : source de l'Ă©vĂ©nement

â—Ź  source.type : type de SDK (sdk-web, sdk-mobile ou sdkamp)

â—Ź  source.domain : domaine ou ID d'application mobile

â—Ź  source.key : clef API publique

â—Ź  source.version : version du SDK (si type est sdk-mobile)

â—Ź  user : utilisateur qui a crĂ©Ă© l'Ă©vĂ©nement

â—Ź  user.country : pays de l'utilisateur (code ISO 3166 Alpha-2)

â—Ź  user.id : ID de l'utilisateur

â—Ź  user.id_type : type d'ID de l'utilisateur

â—Ź  user.agent : agent utilisateur complet

â—Ź  user.agent_info.os_family : système d'exploitation

â—Ź  user.agent_info.os_version : version du système d'exploitation

â—Ź  user.agent_info.browser_family : navigateur

â—Ź  user.agent_info.browser_version : version du navigateur

â—Ź  user.agent_info.device_type : type de terminal (si type est sdk-web)

â—Ź  user.tcfv : version du TCF

â—Ź  user.tcfcs : consent string du TCF

â—Ź  user.token : token utilisateur

â—Ź  consent : statut de consentement de l'Ă©vĂ©nement

â—Ź  is_bot : si l'Ă©vĂ©nement a Ă©tĂ© crĂ©Ă© par un robot

â—Ź  parameters : paramètres spĂ©cifiques de l'Ă©vĂ©nement

â—Ź  experiment : information sur l'expĂ©rimentation (AB test)

â—Ź  experiment.id : ID de l'expĂ©rimentation dont l'utilisateur a fait partie

● experiment.group : groupe de l'expérimentation dont l'utilisateur a fait partie (groupe test ou référence)

Voici ce Ă  quoi ressemble ce document :

La configuration de la notice au moment de la collecte de la preuve de consentement

Nous stockons aussi les différentes versions de la notice de consentement depuis sa création dans la console Didomi.

⚠️ Si vous n'utilisez pas la console pour gĂ©rer vos notices et que vous utilisez un fichier de configuration en local, Didomi ne stocke pas les versions de la configuration des notices. Nous vous recommandons d'importer vos notices dans la console Didomi pour avoir toutes les versions de la notice que vous devrez fournir en cas de contrĂ´le par les autoritĂ©s chargĂ©es de la protection des donnĂ©es.

Cela vous permet d'obtenir la configuration d'une notice spécifique à la date de la collecte de la preuve de consentement. Cette configuration contient des informations sur les vendors, les finalités, le format, les textes et d'autres éléments présents sur la notice implémentée quand l'utilisateur a fait un choix de consentement.

Vous pouvez rĂ©cupĂ©rer la configuration de la notice en utilisant notre API. Consultez nos đź“° spĂ©cifications API pour avoir plus d'information. 

page4image43709440 

Vous pouvez utiliser GET/widgets/notices/configs/{id} et un ID de configuration de notice pour récupérer cette configuration, comme dans l'image ci-dessous :

 

Vous pouvez aussi retrouver un déploiement spécifique avec notre API. Consultez les spécifications ici.

Voici les descriptions de certains éléments que vous pouvez retrouver dans la configuration. Il ne s'agit pas d'une liste exhaustive, vous pouvez obtenir plus d'information dans notre documentation API.

â—Ź  id : ID unique de la configuration de la notice

â—Ź  full_atp : si le SDK utilise les vendors ATP sĂ©lectionnĂ©s par Didomi (false)

ou les vendors ATP sélectionnés par le client (true)

â—Ź  enable_ignore_consent_before : si le consentement doit ĂŞtre recollectĂ© après une date prĂ©cise

â—Ź  ignore_consent_before : la date Ă  partir de laquelle le consentement doit ĂŞtre recollectĂ© (si enable_ignore_consent_before est Ă  “true”)

â—Ź  text_mode : si la notice utilise un texte custom ou un texte validĂ© page5image41100096

â—Ź  negative_action : quelle est l'action nĂ©gative affichĂ©e sur la notice

â—Ź  disagree_button_style : le style du bouton refuser

â—Ź  country : le pays de la notice de consentement

â—Ź  notice_deny_applies_to_li : base lĂ©gale configurable pour "refuser tout"dans la notice

â—Ź  preferences_deny_applies_to_li : base lĂ©gale configurable pour "refuser tout" dans les prĂ©fĂ©rences

â—Ź  app : configuration principale

â—Ź  vendors : vendors (đź“° voir la documentation)

â—Ź  iab : configuration relative au TCF

â—Ź  restrictions : restrictions du TCF (đź“° voir la documentation)
○ enabled : si l'intégration TCF est activée ou pas
â—Ź  languages : langues (đź“° voir la documentation)

â—‹ enabled : liste des langues disponibles

â—‹  default : langue par dĂ©faut

â—Ź  content : contenu de la notice (đź“° voir la documentation)

â—Ź  daysBeforeShowingAgain : nombre de jours après la collecte du consentement pendant lesquels la notice ne se rĂ©-affiche pas (đź“° voir la documentation)

â—Ź  enable : si la notice est activĂ©e ou pas (đź“° voir la documentation)

â—Ź  position : format de la notice (bottom, popup, etc.) (đź“° voir la documentation)

â—Ź  preferences : prĂ©fĂ©rences (finalitĂ©s et vendors)

â—‹ content : contenu des popups (đź“° voir la documentation)

â—Ź  categories : finalitĂ©s et catĂ©gories

â—Ź  theme : thème (đź“° voir la documentation)

â—Ź  color : couleur principale utilisĂ©e par le SDK

â—Ź  linkColor : couleur des liens

â—Ź  font : police affichĂ©e

â—Ź  buttons : thème des boutons

â—Ź  css : custom CSS