Server Side Cross Domain Tracking | Community
Skip to main content
Level 2
April 20, 2023
Solved

Server Side Cross Domain Tracking

  • April 20, 2023
  • 2 replies
  • 5467 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Krishna_Musku

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

 

 

2 replies

Krishna_Musku
Community Advisor and Adobe Champion
Krishna_MuskuCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
April 20, 2023

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

 

 

- Krishna Musku (Adobe Champion & Community Advisor)
Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
April 20, 2023

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.html?lang=en

 

Level 2
April 24, 2023

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
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
July 25, 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? 

 


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...