Consent management is essential for compliance, ensuring companies obtain and manage user consent for data collection, storage, and usage. This includes marketing permissions, outreach approvals, and personalization preferences. BlueConic enables businesses to collect, store, and manage consent preferences across multiple systems—online and offline, for both known and anonymous users. Consent data is stored in BlueConic Objectives.
BlueConic is not a consulting or law firm. This page does not constitute legal advice. We recommend you consult your organization’s legal and/or privacy experts to determine what is required for your specific organization.
Things to know about consent
Consent can be stored for both online and offline profiles. For online profiles, consent is typically managed by a Consent Management Platform (CMP). For offline profiles, consent is often included in the data feed.
The legislation zone determines how consent is handled:
GDPR (EU): Requires opt-in consent.
US-based laws: Typically follow an opt-out model.
Legislation zones are assigned as follows:
Online visitors: The legislation zone is automatically assigned based on IP address. Once set, it remains unchanged.
Offline data: The legislation zone must be set manually based on the data source.
If a legislation zone is not set, the profile is considered part of "Rest of World", and consent updates are ignored.
Consent tracking and logs
Consent actions (given or refused) are logged separately and visible under the Profile privacy management tab in a profile.
The latest status is reflected in the following profile properties:
consented_objectivesrefused_objectives
When a profile property is updated, the Privacy Event Log is also updated.
Syncing consent
To sync consent data correctly:
Ensure the Objective exists in the system.
The Objective ID must match the external system’s ID.
If an opt-out is received after an opt-in, the objective is removed from consented objectives (and vice versa).
Updating consent
Consent can be updated through multiple methods:
CMP Integration
JavaScript API / Mobile SDK
REST API
Import Connection
JavaScript API
Example of updating consent via JavaScript:
javascriptCopyconst profile = blueConicClient.profile.getProfile();
// User gave consent
profile.addConsentedObjective("iab_purpose_1");
// User refused consent
profile.addRefusedObjective("iab_purpose_2");
// Apply the updates
blueConicClient.profile.updateProfile();
In a native app, consent can be updated in a similar way (see mobile SDK documentation).
Alternatively, you can update consent using profile properties:
javascriptCopyconst profile = blueConicClient.profile.getProfile();
// User gave consent
profile.addValue("consented_objectives", "iab_purpose_1");
// User refused consent
profile.addValue("refused_objectives", "iab_purpose_2");
// Apply the updates
blueConicClient.profile.updateProfile();
REST API
Consent can be updated using the "Create or update one or more profiles" endpoint:
jsonCopy[ { "matching": [[{"id": "email", "value": "[email protected]"}]], "properties": [ {"id": "privacy_legislation", "values": ["GDPR"], "strategy": "SET"}, {"id": "consented_objectives", "values": ["objective_1", "objective_2"], "strategy": "ADD"}, {"id": "refused_objectives", "values": ["objective_3"], "strategy": "ADD"} ], "strategy": "UPSERT" } ]CMP integration
A Content Management Platform (CMP) is often in place to capture consent, allowing visitors to manage preferences via options like “manage options.” Consent and refusal (e.g., “I agree”/“I don’t agree”) are typically exposed through an API or cookies. For CMPs supporting the TCF standard, consent can be retrieved via:
window.__tcfapi("addEventListener", 2, function(tcData, success) {
// the tcData contains booleans for consented / refused
});This provides access to consent data for use with BlueConic Objectives. CMP integrations are available for OneTrust, Cookiebot, Osano, and any CMP supporting the TCF standard - typically syncing consent either immediately or on the next page view. Integrations act as global listeners, executing on every pageview across all channels. A key advantage is setting consent values before other scripts execute.
Global listeners run on every pageview across all channels, ensuring consent is set before other processes execute. If a listener is restricted to Objective X and consent is available when BlueConic loads, it executes immediately. However, if the CMP loads after BlueConic, the listener won't trigger, making execution timing critical.
Integration approaches
There are two common integration methods:
BlueConic is always loaded
The CMP syncs consent, ensuring all web-based connections respect it.
BlueConic is only loaded after consent is granted
Managed by the CMS, TMS, or CMP.
Ensures no data is captured before consent is given.
Note: If a CMP is not in place, BlueConic can display consent messages using the Privacy Management Plugin.
Import connections
When consent is captured in an external system and you want to map this to objectives, you can use the “Consented objectives” and “Refused objectives” profile properties.
For example, you have a CSV feed containing consent data from the external system:
email,consent_A,consent_B
[email protected],Yes,No
[email protected],Yes,Yes
Assuming that “objective_A” matches with “consent_A” and “objective_B” matches with “consent_B,” you can use the following Javascript data processor setup to make the translation to a “consented” and a “refused” property:
This can then be mapped using an import connection like SFTP:
After the import, it would look something like this on the profile:
Note: You can also use the Convert value data processor in the connection to map “Yes” or “No” to the objective ID.
Make sure that:
“Add” is used as the rule to apply; otherwise you would overwrite existing consents.
The profile contains a valid legislation zone if you do not want it to be included in the “Rest of the world” zone.
The objectives exist (with proper ID and proper casing) before the import runs.
Importing email / SMS opt-ins
In addition to privacy consent, customers often require opt-ins for channels like email and SMS. This differs from privacy consent in key ways:
In opt-in zones, explicit opt-in is often needed for sending messages, while in opt-out zones, data can be used unless the person opts out.
Opt-ins typically apply to specific email addresses or phone numbers. When profiles have multiple contacts (e.g., merging identifiers), tracking consent becomes tricky. For example, if consent is given for one email but not another, it's hard to manage.
To handle this, objectives can work for email/SMS opt-ins when:
Operating in an opt-in region (e.g., EU), and
There's a one-to-one mapping of email/phone to the profile.
If this isn’t the case, it is recommended that you import opt-in data to the timeline and use a rollup to determine which contact can be used for activation.
The following event type can be defined to establish this setup (specific properties are subject to the data provided):
Importing this data results in timeline events like this:
When this is imported, you can use a rollup to store the imported value, which can then be used to activate a profile property. This property can be used both in the export and in the segment definition to ensure that only profiles with consented email addresses are exported.