Cross domain stitching of a visitor

[SanyaTh1]

We would like to stitch the users of two domains of a particular organization together, i.e sub domain
As, we want to track the same visitors traversing from page 1 to page 2 ( another sub domain).
MID does not remain same, hence would like to know the way out !
kindly suggest.

[FarazHusain]

Hey @SanyaTh1 To ensure visitors are stitched across subdomains, you need to implement cross-domain tracking using Adobe Analytics' built-in features. Here's the link for the same: https://experienceleague.adobe.com/en/docs/id-service/using/id-service-api/methods/appendvisitorid

[Harveer_SinghGi1]

Hi @SanyaTh1 ,

Assuming that the Visitor ID Service on both of these domains is configured using the same Adobe Org ID, you can achieve this as below,

• If user's browser accepts third party cookies: In this case you don't need any additional implementation as user browser will get the Demedx cookie and both sites will have same ECID returned using the Adobe Org ID and Demdex ID combination. This is explained in this documentation - https://experienceleague.adobe.com/en/docs/id-service/using/intro/id-request
• If user's browser doesn't accept third party cookies: In this case you'll need to manually shared the visitor information among details using appendVisitorIDsTo method which @FarazHusain has mentioned.

So, if you implement appendVisitorIDsTo it will take care of browsers with TP limitations and normal browsers will anyways give you the cross domain stitching.

Cheers!

[SamuelPaulPeter]

Hi @SanyaTh1, the solution could be achieved in three ways:

1. By Implementing Cross-Domain Tracking:

Share the ECID across both subdomains. Ensure the ECID is same across domains. 

- Configure cookies to be set at parent domain level. For Eg: instead of using domain as "abc.domain.com" or "xyz.domain.com", use ".domain.com"

- Use visitor.appendVisitorIDsTo method to pass ECID while redirecting users between domains. This helps to append ECID as a query string parameter.

Use the below link to help you with this process:

Link for Cross Domain Tracking 

2. Use "Common Cookie" approach:

Again, configure cookies to be set at top-level domain (For Eg: ".domain.com")

Use the below link to help you with this process:

Link for Common Cookie Approach 

3. Stitching on Server-Side using Customer Identifiers:

You can use unique customer identifiers like Customer ID, Login ID, CRM Identifiers, etc., to stitch the data across domains.

Among the above, this method is effective but required the identifier to be captured every time, or required user authentication.

Use the below link to help you with this process:

Link for Server Side Customer ID Approach 

Points to Remember:

1.Do not forget to test it before you take it live.

2.Ensure the privacy compliance is met. 

[Jennifer_Dungan]

Just adding my two cents here...

You can add Cross Domain tracking, but you really shouldn't have to... One of the things I don't like about this is the appending of a lot of content into the URL... which, I get, we use parameters for campaigns... but this also comes with challenges... like if someone shares this URL, anyone who clicks on that link will be stitched in as the original user.... so I would only use this as a last resort.

I have a network of 30 different domains, each of those domains have several sub-domains each. I don't use Cross Domain Tracking as there is very little direct traffic between the sites.

I ensure that I am setting my cookies to the main domain (i.e. www.siteA.com, sub1.siteA.com, sub2.siteA.com, etc all set their cookies to .siteA.com - not to each individual variance)... these being first party cookies are freely used by all the shared domain... but even between different domains (i.e. www.siteA.com and www.siteB.com) which do not share cookies, the proper Organization setup of my Visitor ID service properly identifies those users as the same person, and they get the same ECID / MID.

I can test this by opening up an Incognito window, in one tab typing opening Site A, and in another tab opening Site B... both share the same ECID / MID.

First, are you using App Measurement or WebSDK for your implementation?

If you are using App Measurement, check for the s_ecid cookie, make sure it's being set (the last time I helped someone with a similar issue, their site wasn't setting the cookies, so there was no "re-identification" possible, so a new ECID / MID was being set for each use).

I am not sure on WebSDK if you are set to use client side cookies or just server-side cookies... you may need to ensure that client side is being set as part of your overall network heath.