Web SDK & Edge domain | Community
Skip to main content
Michael_Soprano
Level 10
January 21, 2026
Solved

Web SDK & Edge domain

  • January 21, 2026
  • 2 replies
  • 39 views

I would like to implement one Web SDK on multiple domains in order for the user to have same ECID. 

Additionally I would like to configure CNAME. 

If I would have multiple domains then I should set up that domain as dynamic data element?
 

 

Best answer by bjoern__koth

The CNAME is the classic best practice to hide the requests from potential ad blockers.

This will also write a 1st-party cookie on that domain. Meaning, your cname.domainA cookie won’t be readable from your cname.domainB domain anyway.

 

If you enable third-party cookies in the WebSDK, you will see a demdex call being made that will write kndctr cookies on that very domain, which will be readable across domainA and domainB, as long as both are within the same AdobeOrgID.

Web SDK 3rd Party Settings

The approach ​@arpan-garg mentions with the appendIdentityToUrl is slightly different and works without third-party cookies, but is limited to links from domainA to domainB.

So, if your visitor visits domainA and then directly enters domainB in his address bar, he will not be recognized,

 

Bottom line:

 

Main requirements

  • all domains must be under the same AdobeOrgID

CNAME

  • writes 1st-party cookies, not readble between domains 
  • appendIdentityToUrl can help mitigate this by sending identity data in direct links (custom implementation)
  • Safari’s ITP detects CNAME not belonging to your website domain as 3rd party and will limit cookie lifetime

3rd-party cookies

  • readable from all domains (demdex cookie)
  • heavily underly browser cookie lifetime limitations

2 replies

arpan-garg
Community Advisor
Community Advisor
February 15, 2026

Hi ​@Michael_Soprano  - Have you gone through this page, we have the similar requirement because our client has multiple brands selling the same products and we used the approach mentioned here https://experienceleague.adobe.com/en/docs/experience-platform/collection/js/commands/appendidentitytourl

Thanks,

Arpan

bjoern__koth
Community Advisor and Adobe Champion
bjoern__kothCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
February 16, 2026

The CNAME is the classic best practice to hide the requests from potential ad blockers.

This will also write a 1st-party cookie on that domain. Meaning, your cname.domainA cookie won’t be readable from your cname.domainB domain anyway.

 

If you enable third-party cookies in the WebSDK, you will see a demdex call being made that will write kndctr cookies on that very domain, which will be readable across domainA and domainB, as long as both are within the same AdobeOrgID.

Web SDK 3rd Party Settings

The approach ​@arpan-garg mentions with the appendIdentityToUrl is slightly different and works without third-party cookies, but is limited to links from domainA to domainB.

So, if your visitor visits domainA and then directly enters domainB in his address bar, he will not be recognized,

 

Bottom line:

 

Main requirements

  • all domains must be under the same AdobeOrgID

CNAME

  • writes 1st-party cookies, not readble between domains 
  • appendIdentityToUrl can help mitigate this by sending identity data in direct links (custom implementation)
  • Safari’s ITP detects CNAME not belonging to your website domain as 3rd party and will limit cookie lifetime

3rd-party cookies

  • readable from all domains (demdex cookie)
  • heavily underly browser cookie lifetime limitations
Cheers from Switzerland!
arpan-garg
Community Advisor
Community Advisor
February 16, 2026

@Michael_Soprano  - What ​@bjoern__koth said is absolutely correct, in our case all of the sister brands redirects to the main website when the user click on any booking link.