Marketing Cloud Next - Consent Management: Segmentation and the Consent Model

Note: This article is a companion article for the Consent Management: Frequently Asked Questions resource. Check that article out for additional details and other frequently asked questions.

How can I segment on consent data stored in Data Cloud?

Segmenting directly on consent data isn't supported out of the box today. The supported workaround is to create a Calculated Insight on consent data, then use that Calculated Insight in your segment filter. Subscriber-Key-based consent segmentation is on the roadmap.

Sample Calculated Insight query:

SELECT UnifiedIndividual__dlm.ssot__Id__c AS id__c,

count (UnifiedIndividual__dlm.ssot__Id__c) AS index__c,

ssot__CommunicationSubscriptionConsent__dlm.ssot__ConsentStatus__c AS ConsentStatus__c

FROM UnifiedIndividual__dlm

JOIN UnifiedContactPointEmail__dlm ON UnifiedIndividual__dlm.ssot__Id__c = UnifiedContactPointEmail__dlm.ssot__PartyId__c

JOIN ssot__CommunicationSubscriptionConsent__dlm ON ssot__CommunicationSubscriptionConsent__dlm.ssot__ContactPointValueText__c = UnifiedContactPointEmail__dlm.ssot__EmailAddress__c

GROUP BY ConsentStatus__c, id__c

IMPORTANT: 

This query is a starting point only and will likely need to be modified to fit your specific data model and use case. Keep in mind that Calculated Insights and segments that reference consent data are metered Data Cloud usage types, so running them may incur additional credit consumption each time they run. Design and schedule them with this in mind, especially at high contact volumes.

Why is PartyID not used by Marketing Cloud consent?

Marketing Cloud Next consent is intentionally agnostic of PartyID (the individual identifier). Instead, it keys consent on the Contact Point value (email address, phone number, device ID) combined with the Communication Subscription Channel Type (CSCT) ID. This design:

• Avoids conflicting consents for the same channel address. A single email or phone number can be associated with multiple individuals (shared household email, merges, duplicates). Keying on the individual would require resolving whose preference "wins."

• Uses a conservative, regulator-friendly default. Managing consent at the contact point value is more restrictive: if any individual sharing that address has opted out, the address is treated as opted out — aligning with how regulations are enforced (against the address being messaged).

What's the relationship between the Individual / Unified Individual and the consent model?

Consent doesn't store a mapping to the Individual or Unified Individual. It's a direct mapping between the Contact Point value, Communication Subscription, and Engagement Channel Type — independent of PartyID.

At build time: a Segment is created based on Individuals, and its output includes their related Contact Point values. A Send action is created, and you select which Communication Subscription is used to derive consent.

At send time: each Contact Point value is evaluated against Communication Subscription Consent (if a Communication Subscription is selected for the send action). If opted in, the message sends; if opted out, it doesn't. A relationship between the Unified Individual and the Contact Point value is needed so the Segment can produce the Contact Point values, but that's upstream and doesn't require a direct object relationship within the consent model.

How is consent handled when two people share one email address/phone number?

If two or more individuals share the same Contact Point email or Contact Point phone number, an opt-out on that email or phone number affects all of them. For example, there's no way to send to some individuals and suppress the others when they share the same email address — consistent with the conservative, address-level approach described above.