Controlling AEP WebSDK consent cookies functionality

[Kaushik_Ganguly]

Hi,

We are using the Opt-in/Opt-out feature of AEP WebSDK, where the consent is stored in the kndctr_<ORG_ID>_consent cookie at the domain level. However, we have cookie banners implemented at the subdomain level and even at the country-specific level, which is causing some challenges.

For example, we have a cookie banner on www.xyz.com. After giving consent, the cookie kndctr_<ORG_ID>_consent=general=in is stored at the .xyz.com domain level. Now, if the user navigates to stg.xyz.com, the same consent cookie is used and server calls are triggered even though stg.xyz.com has a separate cookie banner because the domain is still .xyz.com.

Another case is that we have different cookie banners based on countries, such as www.xyz.com/ie and www.xyz.com/de. If a user visits one of these and gives consent, and then visits the other, server calls are made due to the shared domain .xyz.com.

One solution we considered was to manually configure the cookie domain based on the cookie banner setup in our Launch property, but we’re not sure how to implement this or if it would even work.

Another possible solution is to use a custom code within a data element and pass that data element to the default consent configuration. In the custom code, we could check whether performance cookies are present. If not, we could delete the AEP WebSDK cookies and return consent as "pending"; otherwise, return it as "in".

Could someone please suggest a better approach to handle this scenario, or guide us on how to configure the cookie domain or delete cookies as per the approach mentioned?

Thanks in advance,
Kaushik

[Vinay_Chauhan · Accepted solution]

This is a common challenge when consent is handled at different levels across subdomains or regions. Since the AEP Web SDK sets the kndctr_<ORG_ID>_consent cookie at the root domain (e.g., .xyz.com), that consent value ends up being shared across all subdomains — which can cause issues when each subdomain or country path has its own cookie banner and requirements.

One option you might consider is customizing the cookie domain behavior directly in Adobe Launch. By default, it’s set to auto, but you can override this through custom code depending on the specific subdomain. For example, you can programmatically detect whether the user is on www.xyz.com, stg.xyz.com, or another environment, and set the cookie domain to match that subdomain rather than the root.

Another approach — and it sounds like you're leaning toward this — is to build a custom data element that evaluates the user’s consent status based on your banner logic. This can check for the presence of a region-specific performance or consent cookie. If that cookie isn't found or consent hasn’t been given, the data element can return "pending" and optionally remove existing AEP cookies. If the correct consent is detected, you can return "in" and allow tracking to proceed.

This gives you more precise control over how and when AEP starts tracking, and helps ensure that consent is respected according to your local setups.

Let me know if it helps.