Consent Management Platform (CMP) analytics
Access Type: Analytics - Viewer
Didomi Consent Management Platform (CMP) analytics provides your organization with a variety of dashboards that can be subsequently filtered to review key data on how your consent notices are performing on your domains/apps. In this article, we will cover the following for CMP analytics:
Note: The following refers to aggregated analytics data captured in Didomi structured CMP dashboards. Consent proofs (the individual historical records of an end-user's consent choices are stored by Didomi for 5 years).
Dashboard updates
Didomi CMP analytics dashboards are updated daily (at approximately 7:00 AM UTC) with a 1-day delay.
Historical data limits
The look-back window for data is dependent on the available date aggregation for a particular dashboard. Please refer to the table for the historical data limits for each dashboard:
Hourly
14 days
Exploration
Daily
1 year
Domains & Apps
Countries
Tech
Web Pageviews
App Sessions
North America
AB Tests
Notice implementation
Measured events
Didomi SDKs automatically collect events when an end-user interacts with your website, mobile app, etc... The following events are collected and aggregated to generate CMP analytics dashboards:
Events with an invalid domain or containing localhost are filtered out from the CMP analytics in your dashboard.
Website pageviews
A pageview event is fired on every page browsed by an end-user on your website where the Didomi SDK is present.
Note: Pageviews are only tracked when the Didomi SDK is present on the page so ensure to embed the Didomi SDK tag on every page of your website.
This event includes the following data points:
Date and time
Consent status of the end-user for purposes and vendors
Domain name (but not the actual URL/page visited by the user)
Country of the end-user
Experiment (if any)
Mobile app sessions
App sessions are tracked every time your mobile app is launched.
Note: App sessions are only tracked when the Didomi SDK is initialized so ensure to embed the Didomi SDK in your app and initialize it on every app launch.
This event includes the following data points:
Date and time
Consent status of the end-user for purposes and vendors
Mobile app ID
Country of the end-user
Notice display
Event tracks when consent notices are shown to end-users for collecting their consent.
This event includes the following data points:
Date and time
Purposes and vendors shown to the end-user
Consent status of the end-user
Domain or mobile app ID
Country of the end-user
End-user consent decisions
Event tracks consent decisions made by the end-user (both positive and negative). consent.given is sent every time an end-user agrees or declines purposes or vendors in a consent notice (or any other UI displayed by Didomi) in order to register the new consent status of the end-user.
This event includes the following data points:
Date and time
New consent status of the user for purposes and vendors
Previous consent status of the user for purposes and vendors
Domain or mobile app ID
Country of the user
Note: This event is stored as a legal proof of consent.
UI interactions
Event tracks the end-user's interactions within the consent UI (showing the list of purposes, expanding vendor details, etc.).
This event includes the following data points:
Date and time
Identifier of the interaction with the UI
Domain or mobile app ID
Country of the user
Data sampling
Aside from the end-user consent decisions event (which is collected and stored by Didomi as legal proof of consent and to demonstrate end-user choices), the remaining events collected by the Didomi SDKs on websites and mobile apps are sampled.
Sampling refers to the collection of events from random end-users and then extrapolating the analytics data in your organization's CMP dashboards. The Didomi sampling strategy is currently:
Every end-user is associated with a unique and random user ID
User IDs are uniformly distributed into N random buckets through hashing
Users from the top X% buckets are selected as being part of the sample
All events from users in the sample are collected
Note: The sampling rate varies across event types and platforms.
This strategy ensures that the sample is representative of the entire end-use base by selecting purely random end-users and logging all events for those end-users (which ensures that we capture the full behavior of those end-users).
Last updated