Tracking Consent
When a customer gives you consent, you need to track it as an event. This is important because if your legal base for processing the customer’s data is consent then you might be asked to provide proof of consent if one of your customers complains to their local data protection authority.
Tracking of consent does not happen automatically, so you need to integrate tracking of the consent event on all the touchpoints where you collect customers’ consent. The name of the event has to be consent
.
Historical imports can be uploaded as a consent event.
For a new subscription and ongoing events, it is recommended that you track first via double_opt_in events (to capture consent from the customer) together with a Bloomreach Engagement scenario.
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 grantedreject - Consent revokedManual definition | Yes | "accept" |
category | The ID of the consent category, as defined in project settings. Manual definition | 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. Manual definition | Yes | 1528114618 |
valid_until | Multiple options:unlimited <timestamp> - Timestamp of the expiration dateManual definition | Yes, when action is accept | "unlimited" |
identification_type | Type of identification which was used while the customer was giving the consent. If the identification_type has value "application" that means, the consent was generated in application. Automatically generated | No | "cookie" or "application" |
identification | Identification value which was used while the customer was giving the consent. Automatically generated | No | "dab8a3d0d868126" |
source | Multiple options:crm - Manually created consent in the application.import - Consent imported from the import wizard.public_api - Most likely tracking API, which uses only public token for authentication. This source is valid only if enabled in project settings. See Consent management for more details.private_api - API, which uses basic authenticationpage - Tracked from the consent page or when a spam complaint is receivedlist_unsubscribe - when the user clicks on the unsubscribe link provided by the ESPscenario - Tracked from the scenario from event nodeAutomatically generated | No, is generated automatically if the consent framework is enabled | "import" |
imported_timestamp | Timestamp the event was imported or tracked into Bloomreach Engagement. Serves for auditing purpose. Automatically generated | No | "1522071973" |
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...? |
Bloomreach Engagement provides three ways in which you can track consent:
API tracking
You can track consent events in real-time from your website or from your internal systems using our API. More information about tracking can be found in the JS SDK documentation. Tracking of a new event is also explained in the Add event section of the API reference.
Security disclaimer
To avoid falsifying consents by potential attacks, you should disable Public API for consents and use only private API group when authenticating to Tracking API.
Event tracking in JS SDK is asynchronous
If you need to track the
consent
event before page navigation (or when the user submits a form), make sure to wait until the event is successfully tracked by utilizing thesuccessCallback
parameter of the SDK'strack
method before redirecting to the new URL.
{
"customer_ids": {
"registered": "user12345" // choose which IDs to use for identification
},
"event_type": "consent",
"timestamp": 1528114618,
"properties": {
"action": "accept",
"category": "weekly_newsletters_from_web",
"valid_until": "unlimited",
"message": "This consent was tracked from landing page" // additional attribute
}
}
Batch imports
Bloomreach Engagement supports batch loading of consents. You can either connect Bloomreach Engagement to your existing database or provide consents in a CSV file format. If you decide to load consents via batch imports, you have to define the required consent attributes from the table above. If you choose this option, make sure that you set up API tracking first and only then import consents. Imported consents should have a timestamp just before the API tracking started so you can distinguish them.
action,category,valid_until,timestamp,customer_id
reject,weekly_newsletter,unlimited,1522158555,[email protected]
accept,weekly_newsletter,unlimited,1522156555,[email protected]
accept,push_notification,1522112345,1522152855,[email protected]
CRM
You can manually grant or revoke consent for each customer in the customer view. Go to Data & Assets
> Customers
> click on the desired customer > click on Consents
, and there you are able to see and change the customer's status for each category. This is important for adjusting consent when a customer changes their preferences.
Customer identification
If you want to know more about how individual customers are identified, what is the difference between their hard and soft IDs, and how do you merge multiple IDs into one, go to the Customer Identification article.
Updated about 1 year ago