Reporting for GDPR
Dashboard capability in GDPR v2.0 Web SDK as well as Mobile SDK provides the reporting details of users that have interacted with the Privacy Manager. The data of the active users are made available based on the first 3 metrics and last metric is used for gathering the details of the users that have not interacted with the CMP.
Full Consent
Partial Consent
No Consent
Unknown Consent
The user's consent state is calculated based on the last known consent state and sent to the analytics back-end upon initialization of the Privacy Manager. In case the user does not have a consent state, it is marked as unknown. All new users that we see initially have status “unknown”. Reporting is immediately updated after the user changes consent state for the first time.
Note
For examples on how the calculations are done for reporting, see the different use-cases at the bottom of the document.
Metrics: consent state of daily active users
1. Full Consent
After user presses Accept All or after user sets all purposes and vendors to true for consent as well as legitimate interest.
2. Partial Consent
In case not all purposes and/or vendors are enabled.
3. No Consent
After user presses Reject All or after user sets all purposes and vendors to false for consent as well as legitimate interest (in case some purposes are locked then consent state will always be partial or full).
4. Unknown Consent
User that does not have any consent data present. On the first load, a user has no consent status at all. If there is no interaction with the CMP for more than 15 seconds, the user’s status will be updated as Unknown Consent. If the user leaves the page before the 15 seconds time limit without interacting with the CMP, they will not be included in the metrics. The consent state is updated as soon as the user interacts with the CMP.
Note
Please note: No Consent reporting data can be influenced when ‘Legitimate Interest button scope’ functionality is disabled.
DAU (Daily Active Users)
LiveRamp Privacy Manager for web and mobile billing and analytics data are based on the monthly sum of Daily Active Users (DAU), which is the total number of unique users on a given day. This metric can be tracked within any standard site analytics tool, and effectively equals the monthly sum of unique cookies per day for web and app environments.
The reporting data of the active users can be verified based on the following:
Consent Rates over time
Data can be checked between a specific period of time i.e. for example by settings the start/end date via the calendar : 1st April , 2020 - 30 April , 2020
Consent Rates Per Device Type
Data can be checked for the following devices:
Tablet
Console
SmartTV
Mobile
Desktop
Consent Rates per Version
Data can be checked on per version basis, this means that after the change of any configuration via Console we can verify for positive/negative effects of the changes on the End Users.
Tip
The reporting data are updated every 24 hours with the latest information of users that have interacted with the CMP. The reporting data are also based on 100% of the traffic.
Calculation
The interpretation on your data relies heavily on the understanding on how the calculations are done. Below you can find different examples of use cases to help you understand the way calculations are done for Privacy Manager.
Use Case 1
The CMP has been implemented for just over 14 days. After checking the dashboard we see a consent rate of 86% Full Consent, 5% Partial Consent, and 4% No Consent. In this case, there is 5% Unknown Consent.
To have the user’s consent state set as Unknown Consent, the user has to let the timer expire upon first visit to the website. After the timer is expired and the user has not interacted with the CMP (clicked either 'Save & Exit', 'Accept All' or 'Reject All') the consent state is set to Unknown Consent until the user has interacted with the CMP. Once the interaction has been measured, we update the previous Unknown Consent state to its respective state based on the user’s interaction which will be reflected in the dashboard (e.g. unknown consent rate is replaced with either full, partial, or no consent).
During the 14 days, we have not pushed any new configuration version in the console.
Use Case 2
The CMP is live for 7 days, but we’ve pushed a new configuration version on day 4 that includes a new vendor on the vendor list. Our redisplay is set on 7 days. When checking the dashboard on day 7 we see a consent rate of 56% full consent data, 34% partial consent, 5% no consent, and 5% unknown consent.
In this use-case, Partial Consent contains 2 different calculation methods compared to the usual calculation method. If we check the consent rate on day 3 we’ll see a much higher consent rate and we’ll see that from day 4 and onwards, a huge part is shifting towards partial consent.
The explanation for the phenomenon that’s causing the shift is related to the new configuration that we’ve pushed on day 4. Our CMP calculates each new day when the visitor returns to the website their consent state compared to the current version of the configuration. To illustrate; user A gave full consent on day 3 for configuration version 2. User A then returns to the website on day 5, but is not prompted to renew his consent after the push we’ve done on day 4. This is because we’ve set the redisplay for consent on 7 days. Because user A is not prompted to give his consent again, his Full Consent is based on configuration version 2, which contains less vendors than configuration version 3. As the CMP calculates the numbers for the dashboard each day, and as the user still consented to an older version that contains less vendors, his Full Consent is then changed to Partial Consent. Remember, the CMP checks the consent state based on the current version of the configuration.
Because the redisplay is set on 7 days, user A will need to renew his consent on day 12 (new config is pushed on day 4 + the 7 days from the redisplay means that after day 11 his consent needs to be renewed). When user A revisits the website on day 12 and clicks on ‘Accept All’ again, his consent will be set on Full Consent.
To wrap it all up, you will most likely see an increase in partial consent after every new configuration push that contains an update in the vendor list. This is expected behaviour as it highlights on a daily level how many users are still operating under an older vendor list.