Managing consents
Consent management allows you to manage your subscription policies and tracks any changes to consents for every customer. The main features of consent management in Intempt are:
-
Defining your consent categories that customers can subscribe to
-
Setting subscriptions based on a legitimate interest
-
Lifetime overview of the whole consent history for every customer - see who, when, and where gave or withdrew consent
-
Customizable consent/preference management page
Consent categories
Consent categories allow you to manage and organize data into multiple categories, each with different consent status and a different approach to data processing and communication. Thanks to the categories, you will be able to approach each of your customers in the way to which the specific customer consented or for which they have a legitimate interest. There are three types of categories available in Intempt:
-
General consent
-
Consent
-
Legitimate interest
Managing consents via the user details page
On the user details page, you can monitor and manage consents for each individual customer. The overview in their profile shows the consents granted and revoked and the current status of every consent given by the particular customer.
You can also view all consent events by timeline to view consent details, such as the source of the consent and their expiration dates.Β
Consent categories
Consent categories allow you to manage and organize data into multiple categories, each with a different consent status and data processing and communication approaches. Thanks to the categories, you will be able to approach each of your customers in the way to which the specific customer consented or for which they have a legitimate interest. There are three types of categories available in Intempt:
Category type | Description |
---|---|
General consent | This system setting in Intempt allows you to send messages to all your customers, even without consent or to those who have already opted out. This only allows you to send transactional emails or important warnings that must be used carefully. |
Consent | As per GDPR, a customer must freely and actively give consent. You can define multiple consent categories (such as "Newsletter," "Notifications," etc.). Consents need to be tracked/imported for every customer. |
Legitimate interest | Processing data under legitimate interest is more flexible than active consent. It enables you to process personal data without actively asking your customers for consent. In Intempt, you can define a legitimate interest group by creating an automatic filter based on a customer's behavior (such as purchasing, etc.). |
Configuring the categories
You can configure consent categories in the βPrivacy centerβ section.
You can then select from these categories in the settings of each journey action you are about to launch.Β
This will ensure that you only send messages to customers with the appropriate consent.
Deleting consent categories
To delete a consent category with relations, you must first disconnect the consent form from active journeys.
Configuring consent categories
General consent
General consent should be used only in very few instances. When it is used, customer consent preferences are ignored, which may result in approaching customers without any legal basis for doing so. Therefore, permission to use General consent should be very limited.
The best practice is to disable it altogether and re-enable it only for very specific purposes where you are sure its use is legal and appropriate. In the consent section, you can choose which channels to use the General consent.
If you decide to disable a channel, you can also see which of your campaigns and scenarios have been using General consent in 'Check dependencies' so that you know what campaigns need adjustments in their Consent category. General consent will only be disabled after the adjustments to the running campaigns are made.
Consents
You can create custom consent categories based on the specific consent you received from your customers. It is preferable to have multiple consent categories, first because different customers will give you consent for different things, and secondly, it is preferable to allow customers to opt-out only from some of your communication they had previously consented to instead of withdrawing their consent to all communication.
Setting | Description |
---|---|
Consent category | This field is used to map the consent category to the tracked consent event. It must have the same value as the βcategoryβ property in the consent event. We recommend using simple lowercase words for easy troubleshooting. This field will not be visible to your customers. |
Name | This is a human-readable name of the consent category, which will also be visible to your customers on the consent page. |
Description | A description of the consent category will also be visible to your customers on the consent page. |
Regulation | This field is optional. The regulation under which a user's consent or preference is being saved, for example, GDPR or CCPA. |
Legitimate interest
You can apply a legitimate interest to all your customers or only a specific segment using the "Applies on" filter.
Legitimate interest has the same configuration as consent except for the βApplies onβ in the settings. The remaining ones are the same as in the table above.
Setting | Description |
Applies on | Use this setting to define to which customers you want to apply this legitimate interest."Specific users" β the group of customers defined by the filter will have a legitimate interest. Note that this filter is not static and always reflects the actual state based on customers' behavior. |
Opting in/out from a legitimate interest
Customers can opt-in/opt-out of a legitimate interest in the same way as they can for consent. They are also visible on the consent page.
Tracking an explicit consent event containing a legitimate interest consent category will always override the legitimate interest filter.
Tracking consent
When a customer consents, you need to track it as an event. This is important because if your legal base for processing the customerβs data is consent, you might be asked to provide proof of consent if one of your customers complains to their local data protection authority.
Consent tracking does not happen automatically, so you need to integrate tracking of the event on all the touchpoints where you collect customersβ consent. The name of the event has to be consent.
Every valid consent event must include 4 required attributes as defined below. Other attributes are defined either manually as custom attributes or generated automatically. You can specify and track any other custom attributes you need.
If you track consent with a specified timestamp in the valid_until event parameter and consent gets expired, the consent will change to revoked, and the consent event with status reject will not be tracked.
Attribute | Description | Required | Example |
---|---|---|---|
action | Options: accept - consent granted; reject - consent revoked | Yes | "accept" |
category | The ID of the consent category, as defined in project settings | Yes | "newsletter" |
timestamp | Date and time when the consent was granted or rejected by the customer.In other words, consent timestamp is "valid_from" for the given consent | Yes | 1528114618 |
valid_until | Multiple options:unlimited<timestamp> - Timestamp of the expiration date | Yes, when action is accept | "unlimited" |
userId | User identifier value | No | β[email protected]β |
source | Multiple options:web_store - Manually created consent in the application.api - API which uses basic authenticationios_app - tracked from a an ios app. Source name user belong to or βapiβ value. | Yes, is generated automatically if consent framework is enabled | "web_store" |
sourceId | Source id value | Yes, if soure is provided. If profile id is not required: null | β1003β |
Email of the person who provided the consent. | No | [email protected] | |
message | Full quotation of the consent message that the customer reacted to. | No | Do you agree to...? |
Event tracking in JS SDK
You need to use the consent
method to track if the user has consented to use his data.
Example
const consentParams = {
action: 'agree',
validUntil: 1691823151, // Unix timestamp for consent expiry
email: '[email protected]',
message: 'User agreed to marketing emails.',
category: 'marketing'
};
intempt.consent(consentParams);
In this example, the consent
method logs a user's agreement to receive marketing emails, specifying the duration of the consent and additional details about the consent given.
intempt.consents({
action: "accept", // "accept" for granting or "reject" for revoking
validUntil: 1710859460000,// "timestamp" value of the Date till the consent is valid
category: "", // category of the consent (optional)
email: "", // email used/entered by the visitor (optional)
message: "" // optional (can be left as empty string)(optional)
})
Below is an example of how the tracking can be implemented on a signup page.
Before using consent tracking methods, ensure you have created consent purposes in your organization's settings.
Here is an example of a successfully tracked consent:
{
"action": "accept",
"category": "news"
"timestamp": 1707735272863,
"validUntil": 1710859460000,
"source": "Mobile",
"sourceId": 589541138664144896,
"profileId": "07940997-185b-437e-84d8-151f479fd088",
"email": "[email protected]",
"message": "Yes, email me offers, style updates and special invites to sales and events."
}
Good to know
Refer to JS SDK documentation for information on implementing the Consent tracking method.
Updated 5 months ago