Server Side Cross Domain Tracking

[liamevans11]

Hello,

I am currently investigating server side tracking, in particular, its ability to overcome Safari's ITP for cross domain tracking. Could HTTP response headers be used to set the MID on domain one and then retrieve it on domain two? There is a similar solution that can be used in Google Analytics using FPID and FPLC cookies but I cannot find any documentation for this specific server side tracking use case for Adobe Analytics/Launch.

For example, users on my website go through a quote process on domain A (quote.com) and then the application process is held on domain B (application.com). I currently use client-side cross domain tracking via link decoration to retrieve the MID from domain A on domain B to make sure the sessions are stitched. However, due to Safari's ITP, this cookie expires after 24 hours. Having done research on server side tracking and HTTP response header cookies in particular, it seems like a valid option to circumvent ITP's cookie restrictions and ensure the cookie doesn't expire but I'm not sure if this would work for cross-domain tracking. Could domain B obtain the MID from domain A? Would this prevent Safari's ITP from adding a 24 hour expiration date for the cookie containing the MID?

Any guidance/advice on this topic would be much appreciated.

Many thanks

Liam

[Krishna_Musku · Accepted solution]

We didn't tried to bypass ITP, as we are monitoring how much is the impact of ITP to our analytics by this process mentioned below:

https://experienceleague.adobe.com/docs/analytics/technotes/cookies/cookies.html?lang=en

But there are some articles on how to bypass Safari ITP

ways to bypass ITP:

https://mcgaw.io/blog/bypass-safari-itp-workaround/#gs.vbh6xx

Local-storage tracking is also blocked with ITP 2.3 update

https://impact.com/partnerships/browser-news-what-is-itp-2-3-and-google-chromes-latest-on-tracking/

More on ITP from Webkit:

https://webkit.org/tracking-prevention/#intelligent-tracking-prevention-itp

[Jennifer_Dungan]

From what I understand, Adobe's WebSDK sets server side cookies, but you can also set a client side cookie to help stitch properties together during your rollout.

Here is a recent session I hosted in User Groups that make WebSDK easier to implement (more like your current client side tracking)

https://www.youtube.com/watch?v=k7re4vxZBVk

There were also some good sessions at this year's summit:

https://business.adobe.com/summit/2023/sessions.html?Search=web+sdk

Here is documentation of the First Party Ids:

https://experienceleague.adobe.com/docs/experience-platform/edge/identity/first-party-device-ids.htm...

[liamevans11]

Hi Jennifer,

Thank you for your response. I have just read the documentation related to the FPIDs. This seems like a great way to limit the impact of browser cookie expiration policies. However, the question regarding cross domain tracking still remains. Do you know if it is possible for the Edge Network to retrieve the FPID from the server when a user navigates to our application journey, which sits on a different domain to our quote journey? Would it require the use of a query string parameter?

Thanks

Liam

[Jennifer_Dungan]

Do you have analytics configured on both domains (quote.com and application.com)?  Are both set up with first party tracking servers (stats.quote.com and stats.application.com)?

Because both of these should be connected to your Organization ID, they should be able to identify the same user ID (since the whole concept of the Cloud Ids is to be able to identify users across all the websites in your network)... but that said, the Edge server is all new, and technology is constantly changing (and Safari seems determined to cause havoc with everything)... 

So it can't hurt to use something like appendVisitorIDsTo in your process to be safe:

https://experienceleague.adobe.com/docs/id-service/using/id-service-api/methods/appendvisitorid.html...

I assume this should still work with the Edge server implementation.... 

[liamevans11]

Yes analytics is configured on both domains. However, we currently need to use link decoration in order for the Cloud IDs to be recognised as one journey when users move from domain A to domain B so although they are part of the same organisation ID, they still require link decoration to be recognised as the same website. We haven't implemented any server side tracking as of yet as we are looking at how it could help to circumvent the ITP 2.3. 

The main question for me is, if we use server side tracking and make use of the FPID, would this work with cross domain tracking? As if we set the FPID in the HTTP response header, there is no way for this to get read by JavaScript on the browser so how would domain B read the value? If we use the appendVisitorID method, which we already use for client-side tracking, would that still be classed as a client-side cookie and therefore be subject to Safari's ITP 2.3?

Google Analytics server-side allows users to set the FPID and then uses the FPLC, which is a cross-domain linker cookie hashed from the FPID cookie that is appended to the URL, which allows domain B to read the FPID cookie and link the two sessions without ITP being able to set expiration dates on it.  Does Adobe have anything similar?

Thank you for your help with this!

Liam

[Dave_Hamel_2024]

Hi Jennifer, 

Sorry to flog what might be a dead horse but I really want to make sure I am understanding correctly.  On this page, "Identity Data in Web SDK | Adobe Data Collection" it reads:

"When a new user arrives on your website, Adobe Experience Cloud Identity Service attempts to set a device identification cookie for that user. For first-time visitors, an ECID is generated and returned in the first response from the Adobe Experience Platform Edge Network. For repeat visitors, the ECID is retrieved from the kndctr_{YOUR-ORG-ID}_AdobeOrg_identity cookie and added to the payload by the Edge Network."

If I have a user who comes to quote.com an ECID is set and stored in kndctr_{YOUR-ORG-ID}_AdobeOrg_identity cookie. If they subsequently come to application.com it checks and sees our organization cookie, kndctr_{YOUR-ORG-ID}_AdobeOrg_identity, already exists so it uses the ECID from that? 

[Jennifer_Dungan]

Not a problem @Dave_Hamel_2024 

That is the theory yes... Adobe tries its best to re-identify the same user and to set the same ECID value for both domains. Does it work in all scenarios, probably not (users who clear all cache and cookies when they shut down their browser, or browsers that actively delete cookies, etc would be harder to identify, particularly across different visits..)

But direct traffic from "quote.com" to "application.com" should be a lot more stable, without having to add a lot of extra tagging (like passing the ECID), but only testing would be able to determine the behaviour.

Keep in mind, if quote.com and application.com already have ECIDs, and they don't match, then they will likely keep using their unique IDs and not stitch the user. That is one benefit to passing the ECID...

@liamevans11 I missed your last comment, that's odd that your journey isn't recognized across the two sites... I have 30 "domains" with multiple sub-domains per sites and I can see flows between the main domains within the same visit. You do have all the possible domains coded as "internal urls" in both the suite, and in the analytics extension "Never Track as Exit Link":

I've noticed that if you trigger an exit link it can cause some oddities in the journey...