Didomi collecte des événements à travers les SDKs qui sont déployés sur vos biens (sites web, applications mobiles, centres de confidentialité, etc.). Ces événements sont utilisés pour calculer des données analytiques regroupées tels que des taux de consentements, des pages vues, etc.
Thèmes
- Evénements : Types d'événements collectés par le SDK Didomi
- Échantillonnage : Comment les événements sont échantillonnés par le SDK Didomi
Evénements
🔍 Le SDK Didomi collecte des événements automatiquement lorsqu'un utilisateur interagit avec votre site web, votre application mobile, etc.
Les événements suivants sont collectés automatiquement et utilisés par Didomi afin de générer des données analytiques regroupées. Certains événements sont aussi stockés en tant que preuve légale de consentement.
📊 Pagewiews (sites web)
Un événement de page vue est créé sur chaque page naviguée par un utilisateur sur vos sites web. Les pages vues sont pistées lorsque le SDK Didomi est présent sur la page, assurez-vous de bien intégrer le SDK Didomi sur chaque page de vos sites web.
L'événement comprend :
- Date et heure
- Statut de consentement de l'utilisateur pour les finalités et les partenaires
- Nom de domaine (mais pas l'URL réel/page visitée par l'utilisateur)
- Pays de l'utilisateur
- Expérimentation (s'il y a)
📊 App sessions (applications mobiles)
Les sessions d'applications sont pistées à chaque fois qu'une application mobile est lancée. Les sessions d'applications sont pistées seulement quand le SDK Didomi est initialisé, assurez-vous de bien intégrer le SDK Didomi dans votre application et de l'initialiser pour chaque lancement d'application.
Cet événement comprend:
- Date et heure
- Statut de consentement de l'utilisateur pour les finalités et les partenaires
- Identifiants d'application mobile
- Pays de l'utilisateur
📊 Notice Display
Cet événement piste lorsque les bannières de consentement sont montrées aux utilisateurs afin de collecter leur consentement.
L'événement comprend :
- Date et heure
- Les finalités et les partenaires montrés à l'utilisateur
- Le statut de consentement de l'utilisateur
- Domaine ou identifiant d'application mobile
- Pays de l'utilisateur
📊 Consent given
Cet événement piste les choix faits par l'utilisateur (aussi bien positifs que négatifs). Il est envoyé à chaque fois qu'un utilisateur accepte ou refuse une bannière de consentement (ou toute autre interface utilisateur affichée par Didomi) pour enregistrer le nouveau statut de consentement de l'utilisateur.
L'événement comprend :
- Date et heure
- Le nouveau statut de consentement de l'utilisateur pour les finalités et les partenaires
- L'ancien statut de consentement de l'utilisateur pour les finalités et les partenaires
- Domaine ou identifiant d'application mobile
- Pays de l'utilisateur
📊 Interactions avec l'interface utilisateur
Cet événement piste les interactions de l'utilisateur avec l'interface de consentement utilisateur (montrer la liste des finalités, détails des partenaires, etc.).
L'événement comprend:
- Date et heure
- L'identification de l'interaction avec l'interface utilisateur
- Domaine ou identifiant d'application mobile
- Pays de l'utilisateur
Échantillonnage
🔍 Tous les événements de "Consent given" sont collectés et stockés par Didomi car ils servent comme preuve légale de consentement et comme témoignage d'un choix utilisateur.
Les autres événements collectés par le SDK Didomi sur les sites web et les applications mobiles sont échantillonnés : les événements sont collectés d'un groupe d'utilisateurs choisis de façon aléatoire. Le taux d'échantillonnage varie en fonction du type d'événement et de la plateforme.
La stratégie d'échantillonnage appliquée est :
- Chaque utilisateur est associé à un identifiant utilisateur unique et aléatoire.
- Les identifiants utilisateurs sont distribués uniformément en N récipients aléatoires par le biais d'un processus de hachage.
- Les utilisateurs faisant partie des X% du haut des récipients sont sélectionnés pour faire partie de l'échantillon.
- Tous les événements des utilisateurs faisant partie de l'échantillon sont collectés.
Cette stratégie garantie que l'échantillon est représentatif de toute la population (tous les utilisateurs) en sélectionnant des utilisateurs complètement aléatoirement et en connectant tous les événements de tous ces utilisateurs (cela garantit que nous capturons bien la plage complète de comportement de ces utilisateurs).