HI @Veronica !

Thanks for writing into Amplitude COmmunity! I believe we were speaking on the support ticket, did you get a chance to read through the information and resources I sent ? Regardless, I will reach out to our Engineers internally and I will see if they have an example or some other resources for you.

I will get back to you as soon as I hear word back from the Engineers!

 Hi Denis! 

Yes I did check those links but they are more generic information about how 3rd party cookies work, which I was already familiar with. Would be great to get a better sense on how to actually pass the Amplitude  ID this way (like the example you have in the dev documentation with URL params).

Thanks for any additional help! I think it would be a good enrichment to the documentation.

Hi @Veronica ,

I completely agree, it would be good to have in the documentation! I have reached out to the Engineers and I will respond on this thread as soon as I have word from them :)

Kind Regards,
Denis

 HI @Veronica ,

Engineers are still looking into this but may I ask you about what is the “nature of the experience” that would preventing a usage of URL parameters? Engineers have said that third party cookies are not the most reliable way to send the device ID considering they can be blocked easily by any user/browser and their future is uncertain. If you can make URL parameters work, that would be much better. What is it specifically about the nature of the experience that doesn’t allow parameters? Thank you!

Hi Denis, we can’t pass URL parameters as there is a third party site in the middle of our CX.

Step 1: user lands on domain. We drop Amplitude ID.

Step 2: user lands on third party website after conversion event

Step 3: user returns on subdomain, where Amplitude is also implemented. We’d like the subdomain to detect the original Amplitude ID and merge the user sessions so we can track downstream events of the same user.

We are aware third party cookies are not very reliable, especially if a long time passes between step 2 and 3, but that’s the best we’ve got according to your documentation. Open to creative suggestions.

Hi Veronica, so are the other domains under the same, single website?  If that’s true for your use cases, then you shouldn’t need 3rd party cookies because the amplitude JS SDK uses a single cookie set for the top level domain to track users. Are you passing in any custom options to the SDK that might affect how it handles the domain?

Hi @Veronica I hope all is well. I noticed that there are still some open questions here and I wanted to check in. Were you able to make progress? Please let us know if you need any support. 

Hi @Veronica, I am an Amplitude Engineer from the SDK team. @Denis Holmes provides a good solution here:

1. Both Amplitude JS and TS SDK set cookies at the most top level domain which support cookies storage. So in your case:

We're trying to implement cross-(sub)domain tracking between our marketing site (think example.com) and web app (think portal.example.com). 

You don’t have to set up third-party cookies, the SDK will handle that by default

2. If you are going to track for example “abc.com” and “xyz.com”, you will need to pass device ID to the these domains in order to track anonymous users 

We just released a new cookie guide page: https://www.docs.developers.amplitude.com/guides/cookies-consent-mgmt-guide/. Feel like that would be useful as well.

It’s highly recommended to migrate to TS SDK as JS SDK is in maintenance status and only receives bug fixes. To learn more about their differences.