User consent management using Didomi

Transparency and Consent Framework

The IAB Europe is the European-level association for the digital marketing and advertising ecosystem. They created the transparency and Consent Framework (TCF) which is a GDPR consent solution that standardizes consent collection mostly for ad tech providers.

While using the TCF, CMP must allow the user to make granular and specific consent choices for purposes on one side, and vendors on the other. You can have a closer look at their policies: https://iabeurope.eu/iab-europe-transparency-consent-framework-policies (Appendix B. C. c. iii)

General Didomi's CMP behavior

To be in compliance with IAB TCF policies, Didomi's CMP includes a preferences' view separated from the vendors' view which will allow the user to make granular consent choices.

Consent statuses are split between purposes and vendors. It means that for a vendor tag to be triggered, it will need the consent for itself, as well as for all purposes that are linked to this vendor.

Condition your custom vendor tags

Using Didomi's CMP, you will need to condition your custom vendor tags or SDKs to user consent. You can do so using a 📰 tag manager or by 📰 directly modifying your vendor tags on a web environment. On a mobile application, you will need to use our API and follow this 📰 specific documentation.

Using the vendor ID to condition your custom tags is the best way for you to respect the user consent choices. Didomi's native behavior is to check user consent values on the vendor, and then on the purposes linked to it. If one of the purposes linked to the vendor is set to false, then we will also return false for the vendor.

On the contrary, if you decide to use purposes to condition your custom vendor tags, you will take the risk of not respecting user consent choices. In fact, if the purpose is set to true, we will always send true for this purpose, whatever consent choice has been made to a vendor linked to the purpose by the user. Thus, if you condition on the purpose, you might trigger a tag while having a consent status set to false for the vendor itself.


Schema 3

The user has not given his consent to one of the purposes linked to a vendor and displayed on the preference view. On the contrary, he browsed through the list of vendors and said yes to this particular vendor.

In this case, we will send a "false" status to the vendor. As at least one of the purposes that were linked to the vendor was declined by the user, the tag cannot be triggered.

Schema 4

The user gave his consent to all purposes linked to a vendor and displayed on the preference view. On the contrary, he browsed through the list of vendors and said no to this same vendor.

In this case, we will send a "false" status to the vendor. As the vendor was declined by the user, the tag cannot be triggered. If you had decided to condition the tag on the purpose, the tag would have been triggered even though the user had not given his consent to the vendor. 

Other specific CMP behaviors

Agree / Disagree to all

When a user makes a granular choice on purposes and/or vendors, then, as a second choice, uses Agree to all or Disagree to all buttons, we give priority to Agree and Disagree to all buttons over granular choices. 

Capture d’écran 2023-09-08 à 13.50.13

Granular choice on purposes and no choice on vendors

When a user makes a granular choice on purposes but does not make any choice on vendors, we enable only the vendors that have at least one purpose enabled.