Expand my Community achievements bar.

Join us on September 25th for a must-attend webinar featuring Adobe Experience Maker winner Anish Raul. Discover how leading enterprises are adopting AI into their workflows securely, responsibly, and at scale.
SOLVED

Set Consent at the channel level rather than device specific

Avatar

Level 2

I'm sending consent preferences upon account creation for a website, planned to be sent by the Web SDK. I want to set preferences at the channel level, but on my RTCDP profile, I'm seeing a path that is specific to the ECID. How can I set consent at the email level, rather than something that is device specific? 

 

Here's a sample of the call I'm currently sending that results in preferences that are specific to an ECID value.

alloy("setConsent", {
  consent: [{
    standard: "Adobe",
    version: "2.0",
    value: {
      collect: {
        val: "y"
      },
      marketing: {
        preferred: "email",
        email: {
          val: "y"
        }
      },
      metadata: {
        time: new Date().toISOString()
      }
    }
  }]
});

 Here's what I'm seeing on profile, notice how the path contains "idSpecific."

kyle_rosenlof_0-1754328900193.png

 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @kyle_rosenlof 

I can confirm this is happening and I fully agree that this behavior clearly mentioned in the documentation.

 

My assumption is that this is happening by design, connecting the consent payload to your specific ECID, since we are talking about Web SDK, and with every new / private window you will have to reconsent anyway.
This will give you a potentially different set of consent, and your website is rather handling analytics and marketing pixel consent, but not marketing channel consent like emails, push or SMS.

 

I think the channel-specific consent would rather have to be an onboarded from the CRM as dataset that may contain additional channels a cookie consent banner might not know about.

 

-------------------------------------------------------------

 

[UPDATE] @kyle_rosenlof  this is what I got back from Adobe. This should hopefully answer your question.

 

1. Why is the consent sent via Web SDK showing as idSpecific (ECID-bound) rather than channel-level?
This behavior is expected. When consent is sent from a browser via the Web SDK, it is tied to the ECID generated for that session/device. This means the consent is scoped to that specific browser instance (i.e., “idSpecific”) because the Web SDK works within the identity context available at the time — which is typically just the ECID unless other declared identities (e.g., email, CRM ID) are passed and resolved.

2. Does channel-level consent only apply through backend methods like CMP source connectors?
Yes, channel-level (or global) consent is generally handled through backend ingestion methods like CMP source connectors, where identity mapping (e.g., hashed email, phone) is explicit. This allows the platform to apply consent broadly across all profiles and datasets associated with that identifier, not just a single ECID.

Implications for data activation:

Web SDK: Consent applies to the ECID and is limited to that session/browser. Returning via incognito or another device will generate a new ECID, hence requiring new consent unless identity stitching is implemented.

Backend ingestion (e.g., CMP): Consent applies to all merged profiles with matching identity values, ensuring broader enforcement (e.g., across all email-based activities).

3. Why Consent 1.0 is still available:
Consent Standard 1.0 provides basic yes/no control, typically suited for simpler use cases. Standard 2.0 introduces granularity (channel-/field-level), but is most effective when used with full identity context — which is often only available via system-onboarded datasets or backend ingestion.

 

Cheers from Switzerland!


View solution in original post

6 Replies

Avatar

Correct answer by
Community Advisor

Hi @kyle_rosenlof 

I can confirm this is happening and I fully agree that this behavior clearly mentioned in the documentation.

 

My assumption is that this is happening by design, connecting the consent payload to your specific ECID, since we are talking about Web SDK, and with every new / private window you will have to reconsent anyway.
This will give you a potentially different set of consent, and your website is rather handling analytics and marketing pixel consent, but not marketing channel consent like emails, push or SMS.

 

I think the channel-specific consent would rather have to be an onboarded from the CRM as dataset that may contain additional channels a cookie consent banner might not know about.

 

-------------------------------------------------------------

 

[UPDATE] @kyle_rosenlof  this is what I got back from Adobe. This should hopefully answer your question.

 

1. Why is the consent sent via Web SDK showing as idSpecific (ECID-bound) rather than channel-level?
This behavior is expected. When consent is sent from a browser via the Web SDK, it is tied to the ECID generated for that session/device. This means the consent is scoped to that specific browser instance (i.e., “idSpecific”) because the Web SDK works within the identity context available at the time — which is typically just the ECID unless other declared identities (e.g., email, CRM ID) are passed and resolved.

2. Does channel-level consent only apply through backend methods like CMP source connectors?
Yes, channel-level (or global) consent is generally handled through backend ingestion methods like CMP source connectors, where identity mapping (e.g., hashed email, phone) is explicit. This allows the platform to apply consent broadly across all profiles and datasets associated with that identifier, not just a single ECID.

Implications for data activation:

Web SDK: Consent applies to the ECID and is limited to that session/browser. Returning via incognito or another device will generate a new ECID, hence requiring new consent unless identity stitching is implemented.

Backend ingestion (e.g., CMP): Consent applies to all merged profiles with matching identity values, ensuring broader enforcement (e.g., across all email-based activities).

3. Why Consent 1.0 is still available:
Consent Standard 1.0 provides basic yes/no control, typically suited for simpler use cases. Standard 2.0 introduces granularity (channel-/field-level), but is most effective when used with full identity context — which is often only available via system-onboarded datasets or backend ingestion.

 

Cheers from Switzerland!


Avatar

Level 2

So if I'm understanding you correctly, there isn't a way to set channel-level consent by using Web SDK? That must be done by other means?

Avatar

Employee Advisor

To add to what @bjoern__koth said, if you want to set it at at channel level, you have to set the values outside of idSpecific through another mechanism.  Look here for details and exact syntax, but the values you want are "outside" idSpecific.

https://experienceleague.adobe.com/en/docs/experience-platform/xdm/data-types/consents

 

  "consents": {
    "marketing": {
      "preferred": "email",
      "any": {
        "val": "y"
      },

 

Avatar

Level 2

Hi Danny,

I'm not passing anything device specific, so I assume that is grabbing my ECID value automatically with Web SDK. I'm passing the consent values similar to how you described already (see my code snippet in the original posting). So in my "setConsent" function, I'm not sending "idSpecific" anywhere, yet the consent is still getting applied to just my ECID. Is there a way to pass an identity with setConsent? I've tried a few different approaches to do that but without luck so far.

 

Thanks,

Kyle

Avatar

Community Advisor

Hi @kyle_rosenlof  - I can also confirm this by default behavior, what we are doing is, using event forwarding and making a call via eventforwarding to set the consent at channel level instead of id level.

 

Thanks,

Arpan

 

Avatar

Employee Advisor

@kyle_rosenlof From Experience League:

After you have communicated user preferences to the Web SDK using the setConsent command, the SDK persists user preferences to a cookie.

Thus, it will use the idSpecific data structure to persist the value for that device.  If you want to assume last in wins across all previous values and across devices, you can use @arpan-garg approach or even Data Distiller.