Cross domain tracking/implementation with Adobe Web SDK extension

[AnuKalra_100]

Hi There - Did anyone worked on Cross domain tracking/implementation with Adobe Web SDK extension?

If the user goes from abc.com to a subdomain like jp.abc.com , do we need to employ the cross-domain handling ?

[Jennifer_Dungan · Accepted solution]

In my experience, if I open up Chrome Incognito (so there are absolutely no cookies available), and I open Site A (domainA.com) in one tab, then open Site B (domainB.com) in a another tab, both sites correctly stitch me to the same ECID without needing to do any special effort.

However, that said, Chrome does still accept third party cookies... I know that this is limited on some other browsers... 

If you are expecting that a lot of people will click through from Site A to Site B, then you can use try using https://experienceleague.adobe.com/docs/id-service/using/id-service-api/methods/appendvisitorid.html... and append the visitor Id, then read the value on the other site.

But if the user isn't going direct from A to B, I think you just have to rely on Adobe to do its best to stitch the user properly.

[AnuKalra_100]

Thanks @Jennifer_Dungan 

I've request related to the second scenario where link click will redirect users to the language specific subdomain.

1. It sounds like we do not need to setup a CNAME, correct?
2. Can you explain what Adobe is doing with its cookie on subdomains that requires this setup? (i.e. why doesn’t it treat a subdomain like part of the parent domain’s site?

[Jennifer_Dungan]

Hi,

In my sample, I am on two completely different domains... For you (I wasn't sure if your were talking subdomain, or just using examples) if they are a main and subdomain, you shouldn't need to so anything... domains and subdomains are fine (just so long as you are setting the first party cookies against the main domain.

By which I mean

On site "abc.com" the cookies are set against ".abc.com" (notice the dot at the beginning)

On site "jp.abc.com" the cookies are also set against ".abc.com"

All cookies on ".abc.com" can be read by both domains, cookies set against "jp.abc.com" can only be read by jp.abc.com.

For example, look at these Google cookies:

(.google.com can be read on all google domains; news.google.com can only be read by Google News)

Now, you may need to check how you are setting cookies in your Cloud Id Extension... and make sure that both sites are set up properly.

If they are, you won't need to do anything... including appending IDs to links... in fact, if you have your suite set up correctly, your subdomain shouldn't even trigger an exit link... both should be considered internal domains.

[AnuKalra_100]

Thanks @Jennifer_Dungan  for your comments.

When you said, "you may need to check how you are setting cookies in your Cloud Id Extension... and make sure that both sites are set up properly.". 

I'm using " Adobe web SDK" extension in launch and I think in that case we don't need the separate Cloud Id extension? correct?

[Jennifer_Dungan]

Ah, if you are using the Web SDK, you should be fine (as you are not relying on cookies). That should be setting the ECID on the server based on your organization.

[AnuKalra_100]

Sounds good.

As per our above conversation, I don't requires to do any changes to track cross-domain in user's journey. Domain name abc.com and link click -> jp.abc.com (sub domain of abc.com) will be tracked automatically in user's journey path? when I'm using the Web SDK extension to collect data in analytics.

[Jennifer_Dungan]

Right.. and because abc.com and jp.abc.com share the same main domain, even if you weren't using the web SDK, it should still be fine (with the correct cookie config) since these are the same domain.

[Jennifer_Dungan]

You are also correct, you don't need a new CNAME.... 

If you have s.abc.com set up as a tracking server, it will work on your main and all subdomains.

Adobe does treat subdomains the same... provided you have configured everything properly against the root domain.

[VaniBhemarasetty]

@AnuKalra_100 This use case does not require cross domain tracking, cross domain tracking comes into picture, if the visitor goes from abc.com to dce.com, however in this case, jp.abc.com is a subdomain, web SDK will track this automatically, you don't need to do any extra configuration in this as case as Jennifer mentioned

[AnuKalra_100]

Sounds good, thanks!

[Hey_John]

Web SDK also have the mechanism for cross domain / mobile to web-view tracking,

https://experienceleague.adobe.com/docs/experience-platform/edge/identity/id-sharing.html?lang=en

[SuchetaMo]

Hi @Jennifer_Dungan 

For the same scenario where I want to track www.abc.com (Main domain) www.sd1.abc.com (Subdomain1) and wwe.sd2.abc.com(Subdomain2) with analytics extension.

Do I need implement appendvisitor id () method? 

Also, considering Virtual report suites to be created do we need to setup different launch properties? 

Website has different structure overall

[Hey_John]

Hi @SuchetaMo ,

In your case, the ECID cookie is based on abc.com and will be shared by their sub-domains. So you don't need anything on cross domain tracking.

And I do not see any dependency between VRS and Launch properties.

[Jennifer_Dungan]

Looks like @Hey_John is on top of this! But I agree, your ECID should be set against .abc.com (assuming it's set correctly), and would thus be already set and shared between the main and sub-domains. You should check your implementation to be sure that the cookie is being set to main part of the domain.

It's possible that the cookies were set against www.abc.com and www.sd1.abc.com but even still, I have 30 domains in my network and have not implemented appendvisitorid, and I see the same ECIDs across my domains... 

While appendvisitorid might be a way to ensure users clicking directly from Domain A to Domain B are recognized, the fact is it does nothing if the users hit those domains separately. But ECID being an identifier for your Organization does a good job at identifying those users and setting the same ECID.

As for the virtual report suites, you absolutely do not need separate Launch properties.. 

Virtual Report Suites are just a report suite built based on one or more segments on your main suite. It has nothing to do with how the sites were tagged.

However, what you do need to consider when it comes to your sub-domains, is how fundamentally different is the code base? How hard will it be to maintain changes in the same Launch Property for the different sites?

I will often create new Launch Properties for each sub-domain because it has significantly different code base... it allows me to make the appropriate rules and setup for each sub-domain (without having to add a lot of code in one property to identify which code base and to run variation code).

But this all depends on your complexity.