Tracking consent
If your legal basis for processing customer data is consent, you need to be able to prove it. Consent tracking gives you that proof by recording each grant or revocation as an event tied to the customer's profile.
This isn't automatic. You need to integrate tracking at every touchpoint where you collect consent. If a customer raises a complaint with their data protection authority, these events are what you use as evidence. The event name must be consent.
Historical consents can be uploaded as a consent event via batch import. For new subscriptions and ongoing events, track consent using double_opt_in events together with a scenario. Read more about double opt-in.
Valid consent events
Every valid consent event requires 4 attributes. You can also track any additional custom attributes you need.
Invalid consent events revoke consent
If a consent event is invalid—for example, because it's missing a required attribute or uses an unrecognized action value—the customer's consent is revoked. This is by design: when the platform can't determine whether a consent event should be accepted or rejected, it defaults to revoking consent to stay on the safe side.
If this happens unintentionally, you can expire the invalid consent events to restore the customer's previous consent status.
Attributes for consent events
| Attribute | Description | How it's set | Required | Example |
|---|---|---|---|---|
| action | Whether consent was granted (accept) or revoked (reject). | Manual definition | Yes | accept |
| category | The ID of the consent category, as defined in project settings. | Manual definition | Yes | newsletter |
| Email of the person who provided the consent. | Manual definition | No | [email protected] | |
| identification | The identification value used when the customer gave consent. | Automatically generated | No | dab8a3d0d868126 |
| identification_type | The identification method used when the customer gave consent. A value of application means consent was generated in the app. | Automatically generated | No | cookie or application |
| imported_timestamp | Timestamp the event was imported or tracked into Bloomreach Engagement. Serves for auditing purposes. | Automatically generated | No | 1522071973 |
| message | Full quotation of the consent message that the customer reacted to. | Manual definition | No | Do you agree to...? |
| source | Where the consent came from. Auto-generated if the consent framework is enabled. See source values below. | Automatically generated | No, is generated automatically if the consent framework is enabled | import |
| timestamp | Date and time when the customer granted or rejected consent. This is the valid_from date for the consent. | Manual definition | Yes | 1528114618 |
| valid_until | When the consent expires. Set to unlimited for no expiry, or provide a timestamp for a specific expiration date. Required when action is accept. | Manual definition | Yes, when action is accept | unlimited |
Source values
| Value | Description |
|---|---|
| crm | Consent created manually in the app. |
| import | Consent imported via the import wizard. |
| list_unsubscribe | Tracked when a user clicks an unsubscribe link provided by the ESP. |
| page | Tracked from the consent page, or when a spam complaint is received. |
| public_api | Tracked via the tracking API using a public token. Only valid if enabled in project settings. See Consent management for more details. |
| private_api | Tracked via API using basic authentication. |
| scenario | Tracked from a scenario event node. |
Consent expiry behavior
If you set a timestamp in valid_until and the consent expires, its status changes to revoked. A reject event isn't tracked in this case.
How to track consent
API tracking
Track consent events in real-time from your website or internal systems using the API. See the JS SDK documentation and the Add event section of the API reference.
Security disclaimer
To prevent consent falsification, disable the public API for consents and use only the private API group when authenticating to the tracking API.
Asynchronous event tracking
Event tracking in the JS SDK is asynchronous. If you need to track a consent event before page navigation or form submission, use the successCallback parameter of the SDK's track method to wait until the event is successfully tracked before redirecting.
Example of a valid consent event
{
"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
You can load consents in bulk by connecting the platform to your existing database or uploading a CSV file.
When importing, you must include the required attributes. Set up API tracking first, then import your historical consents with a timestamp just before API tracking started—this helps distinguish them.
For new subscriptions and ongoing events, use double_opt_in events together with a scenario to capture consent.
Example CSV import
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]
Manual updates in the app
You can manually grant or revoke consent for individual customers in the customer view.
Go to Data & Assets > Customers, click on a customer, then click Consents. From there, you can view and update their consent status for each category.
Customer identification
To learn how customers are identified, how hard and soft IDs differ, and how to merge multiple IDs into one, see the Customer Identification article.
Updated 11 days ago