Hi All,
We have a client who owns multiple domains under same Organisation and uses same VisitorID service.
With the help of the demdex cookie we have the same ECID on all the different websites. After disabling 3rd party cookies in the browser settings and clearing the browsercache/storage, we got a different ECID on each website.
We are using this cross-website tracking with the help of the demdex cookie in our reports, primarily to evaluate the customer journey from one website to another website.
This demdex cookie will be disabled after 3rd PArty Cookie deprecation, so is there any alternative solution of demdex cookie so that croos website tracking is still possible and same ECID is generated across all websites.
Please note :
Any help on this would be really helpful.
Solved! Go to Solution.
Views
Replies
Total Likes
@ambikaTewari_ATCI , given your 3 domains:
I would expect that a user who navigates between www.abc.de and xyz.abc.de will always have the same ECID / MID value, if ECID is configured to use "abc.de" as the cookieDomain when implemented in both www.abc.de and xyz.abc.de. This implies that if xyz.abc.de has its ECID implementation configured to use "xyz.abc.de" as the cookieDomain, then I would expect the ECID / MID value of the user to be different from the value at www.abc.de.
Also, I would expect a user who navigates between www.abc.de and www.abc-pqr.de to always have different ECID / MID values. This is because "abc.de" is not the same as "abc-pqr.de". In such cases, you will definitely need to use the cross-domain tracking appendVisitorIDsTo method to ensure that the ECID / MID value can be transferred from the origin to the destination.
Also, I generally set overwriteCrossDomainMCIDAndAID to be true.
Views
Replies
Total Likes
You mentioned 3 domain levels. So let's use the examples of 3 websites: foo.www.domain.com, bar.www.domain.com, baz.www.domain.com.
Since the top level domain (domain.com) and even the 2nd level domain (www.domain.com) are common across your websites, then I don't see why you need to rely on the demdex cookie. demdex is needed only if your top level domain is different, e.g. domain1.com, domain2.org, domain3.com.
I suspect that your ECID cookie domain has been set to the 3rd level (foo.www.domain.com, bar.www.domain.com, baz.www.domain.com), so a different cookie has been set per website. If you change your ECID cookie domain to be the 2nd level -- or preferably the top level -- then you should not run into your problem, even without demdex.
Hi @yuhuisg
Below are three website under same organization :
We visited the websites with 3rd party cookies enabled and then in a another test with disabled 3rd party cookies.
With the help of the demdex cookie we had the same ECID on all the mentioned websites. After disabling 3rd party cookies in the browser settings and clearing the browsercache/storage, we got a different ECID on each website.
for what it's worth, maybe this appendVisitorIDcould help as well.
Note though that this is only working when you are having links pointing from www.abc.de to www.abc-pqr.de .
In general, as @yuhuisg stated, the visitor ID will no longer be accessible without a demdex 3rd-party cookie.
I have tried many different approaches, even including a hidden/super tiny iframe with query params to initialized the ecid there, but all modern browsers are smart enough to detect this approach as 3rd-party as well.
Google is working on the approach of CHIPS (Cookies Having Independent Partitioned State) a.k.a. cookie partitioning, which would technically solve this issue.
But as far as I know, it is still in development and Chrome would anyway be the only browser - yet - to support it - and Firefox and Safari will probably never adapt it because they are not ad driven like Chrome and don't care about it.
You know, just like in good old times when every browser did something on their like CSS or other JS functions, and you ended up using libraries to get a uniform approach to tackle them... yay.
Cheers
Björn
Views
Replies
Total Likes
Hi @bjoern__koth sure , I'll try this appendVisitorID approach to see if mid remains same when a user goes from www.abc.de. to
Hi @bjoern__koth @yuhuisg I found this article https://experienceleague.adobe.com/en/docs/id-service/using/id-service-api/configurations/overwrite-...
As per this article, overwriteCrossDomainMCIDAndAID if set as true then this will overwrite the existing mid of the domain by the previous visited domain if both domain belongs to same org.
1. This attribute is set as true in Adobe Launch and even then when we navigate to xyz.abc.de or www.abc-pqr.de from www.abc.de, mid differs (when thirdparty cookies are blocked of the browser)
Is it because in ECID cookieDomain domain is set as abc.de ? And if make it to top level domain then mid will remain same across all browsers and we dont need to rely on demdex cookie ?
Views
Replies
Total Likes
@ambikaTewari_ATCI , given your 3 domains:
I would expect that a user who navigates between www.abc.de and xyz.abc.de will always have the same ECID / MID value, if ECID is configured to use "abc.de" as the cookieDomain when implemented in both www.abc.de and xyz.abc.de. This implies that if xyz.abc.de has its ECID implementation configured to use "xyz.abc.de" as the cookieDomain, then I would expect the ECID / MID value of the user to be different from the value at www.abc.de.
Also, I would expect a user who navigates between www.abc.de and www.abc-pqr.de to always have different ECID / MID values. This is because "abc.de" is not the same as "abc-pqr.de". In such cases, you will definitely need to use the cross-domain tracking appendVisitorIDsTo method to ensure that the ECID / MID value can be transferred from the origin to the destination.
Also, I generally set overwriteCrossDomainMCIDAndAID to be true.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies