.svg)
You’ve worked hard to be compliant with data legislation and to optimise your consent rate. But that’s only one side of the story. How do these consents get passed from the Consent Management Platform (CMP) on your website or app to third-party vendors? Carry on reading to find out how this can affect your revenue, due to what is known as “consent deperdition”.
Summary:
- What is consent deperdition?
- How does consent deperdition occur?
- How does the Didomi SDK combat the main sources of consent deperdition?
What is consent deperdition?
The aim of a Consent Management Platform (CMP) like Didomi’s is to ensure compliance and optimise consent rate. Let’s say that with the Didomi CMP you have a 95% average consent rate (to find out more about optimising consent rates check out our article on this subject here).
You might well assume that this 95% consent rate is the quantity effectively seen by vendors. However, a topic not often discussed is that your vendors in fact tend to see a lower consent string validity rate than that which your CMP actually collects. The difference between the observed consent events from the CMP (i.e. the actual choices made by the user) and the actual consent string validity rate seen by vendors is known as consent deperdition.
Why does it matter? Consent deperdition is incredibly important, as the gap between your consent string validity rate and what your vendors see has a large impact on revenue. Consent deperdition reduces the number of consents that your vendors receive, the personalized ads that can be displayed, and, therefore, your revenue.
Feeling concerned? Schedule a demo with Didomi and we can help you optimise consent rates and reduce consent deperdition.
But, for now, let’s dive in deeper as to why this happens. Or, find the full recording of the webinar where we discuss optimising consent rates and reducing consent deperdition here (the discussion on deperdition begins 10 minutes into the webinar):
How does consent deperdition occur?
To better understand how consent deperdition occurs, we need to look at how a CMP calculates its consent rate. On the Didomi side, we use a couple of sources for this:
User choices:
At the time when consent is given, we collect an event that will be used for computing the consent rate and for keeping a proof of consent for our records and for use.
App sessions:
From time to time we’ll collect some events from the user when they’re launching or browsing an app over time to include that in a computation of the consent rates.
The consent rate collected by the CMP is actually the optimal consent rate when everything works perfectly. In other words, when consent is precisely collected, when all users are exposed, and when all vendors receive consent correctly. This is the ideal consent rate that the CMP computes, it’s the ceiling of what your vendors will see.
How does the Didomi SDK combat the main sources of consent deperdition?
How do we ensure that vendors receive the maximum number of consents possible? To analyze the sources of consent deperdition, we need to understand the typical workflow of a CMP. Let’s take the example of a workflow of a CMP in an app:
- App launched by user,
- CMP initializes: loads consent status of the user and, if needed, collects consent from the user if they haven’t given it before,
- CMP shares consent status with the vendors.
From this simple workflow, we can see that consent deperdition can be caused by three main sources:
- Initialization speed of the CMP
- Integration with vendors
- Late consent
1. Initialization speed of the CMP:
The slower the CMP, the higher the consent deperdition. A slow CMP will have a negative impact as it will slow down all further operations such as Ads loading and display, analytics and events collection and app responsiveness on launch.
If the CMP is too slow, vendors can simply proceed without waiting, and this leads to consent deperdition. For instance, some ad vendors will only wait X seconds before loading ads. If the CMP is not available in that timeframe, non-personalized ads will be loaded as a back-up option with a lower CPM, regardless of whether the user had given consent or not.
To combat this, these are the ways that we ensure a fast initialization speed in the Didomi SDK:
- All operations are local: Consent is read from the device and shared with vendors, there is no blocking HTTP/async operation after the initial consent collection.
- Consent is shared as soon as possible: When we load the SDK, sharing consent with vendors and the app is the first thing we do before other operations (events, checking if consent needs to be re-collected, etc.).
On average, our SDK initializes in less than one second: This helps to reduce the gap between the consent rate collected and the effective consents seen by vendors
2. Integration with vendors:
The second source of consent deperdition is having sub-optimal integrations with vendors. Generally, an app needs to pass the consent information to vendors, and if these direct integrations are not done the right way this can lead to consent deperdition. Passing the information with accuracy and speed is key to reducing consent deperdition.
Here are a few key downfalls we often see:
- There is no integration at all: This means that some vendors will not get the consent, and will continue operating without consent.
- The timing is not right: this echoes our last point. If the CMP is too slow, ads will be loaded without consent.
- Invalid consent is collected and sent to vendors: A case that we see pretty often with clients that have recently joined us is that the consent seen by vendors is not correct. For example, the consent string is not correctly formatted, or it is not seen soon enough.
To prevent any of these downfalls, the Didomi SDK ensures that all major vendors are integrated seamlessly (TCF, Unity Ads, GAM) and that consent is shared as soon as possible.
We also support other vendors, despite not having direct integrations with them, through our very complete API.
3. Late consent:
Finally, the timing of consent collection has an impact on consent deperdition. Most Didomi clients choose to collect consent as soon as the app is launched. However, you can also choose to collect consent at a later point.
Asking for consent when the user is already engaged with the app can lead to a higher consent rate. Yet, the downside is that fewer users will be exposed to the CMP. This leads to lower user coverage and means that the vendors loaded or the ads displayed before the user gives consent will be without consent, regardless of whether the user does end up giving consent at a later point.
Therefore, collecting consent late, after the vendors and ads have been loaded, will generally lead to consent deperdition.
This is a tricky element with no clear-cut solution, as you essentially have a trade-off between consent rate and some level of deperdition.
Do also bear in mind Google's recent announcement that, as of November 9, 2020, the requirement for TCF v2.0 CMPs to respond within 500ms to AdManger, AdSense, or AdMob requests has been removed. Now Ad Manager, AdSense, and AdMob will wait indefinitely for a response from the CMP you choose to implement.
The Didomi SDK ensures that:
- Consent is collected as soon as possible
- Consent is shared as soon as possible.
So, these are the three main sources for consent deperdition.
Without taking these sources into consideration, we estimate that your vendors effectively see around 25-30% less consent than that which you are collecting with your CMP.
At Didomi, we understand the intricacies involved in consent collection and deperdition. We have been working with clients for years to make sure that this deperdition can be minimised as much as possible. Schedule a demo with us today, and find out how we can optimise your consent rates and minimise your consent deperdition with the Didomi SDK.
.avif.avif){kind=tracking}
