Consents and Preferences
This guide describes how the Didomi platform stores consent information and how you can implement the most common workflows through our API.
The Didomi platform is structured around the following concepts.
An end user that Didomi stores consent information on. A user is associated with a set of Didomi user IDs. When consent is collected through the Didomi SDKs, multiple users can actually be tied to a single real end user as Didomi IDs are stored in cookies and local storage so that it is practically a device ID.
You can associate a user with an organization user ID, which is a unique user ID that you can assign and that is used to link a Didomi user to your internal systems as well as resolve cross-platform IDs. It can be an email address, a phone number, a CRM ID, etc.
Additional metadata can also be associated with a user to track organization-specific information and apply specific rules.
As per GDPR, consents are authorization given by the user for a set of purposes and vendors. Examples: consent to cookies, marketing communications, etc.
In the Didomi platform, Preferences are more granular choices expressed by the user with respect to expressed consents. Those are not GDPR consents per se but are used to add more details to consents and store more granular choices from users. Preferences can be associated with a list of channels and with specific metadata.
Preferences are always tied to a specific purpose. Examples:
The "cookies" purpose can be broken down into multiple categories: analytics, essential, marketing, social, etc.
The "marketing communications" purpose can be broken down into different types of communications (newsletter, special offers, etc.) and channels (email, text, etc.)
The concepts presented above are represented, in the Didomi platform, with the following entities. Read on for more information on how to use the API for managing user consents.
