Cross Domain Tracking

Filipe,

Have you deployed the Marketing Cloud ID Service on either of these sites or are you using the legacy Analytics tracking? If you have deployed the MCID, are both sites deployed using the same Marketing Cloud Org ID (Please do not post the Org ID here)?

Thanks,
Jantzen

Hi Jantzen,

Still use the legacy implementation, deployed through DTM.

If you're using legacy Analytics tracking, your visitors are being identified with the aid value stored in the s_vi cookie by default. You can overwrite that value with the s.visitorID variable. If neither of these are present or fail to be set, there is a fall back ID called the s_fid.

A few questions will help me understand how we might accomplish this:

• When you mention site one uses fall back Visitor ID, which of the above ids are you referring to?
• For site 2, I assume you are using the s.visitorID value?
• Is there ever a scenario where a visitor might visit portions of site 2 before visiting site 1?

Accomplishing what you're asking using custom IDs will be difficult with the legacy Analytics tracking. This is because the s.visitorID value is used as the primary ID in Analytics. This can lead to cliffing visitors if they are fist identified with an aid and later a visitorID. I'd highly recommend looking into the Marketing Cloud ID Service. The ID service does really well with cross domain tracking out of the box and sets you up to use powerful integrations between products. You can also still set Customer IDs to give the same experience targeting across multiple devices. Best of all, your already using DTM so deployment is easy. Here is some documentation in case you want to get started.

Hi,

Seems it is using s_fid on site 1 and yes for site we are setting our own visitorID.

Overall a visitor can go to site 2, login and visit that page and this is fine because this page is indeed part of site 2.

What we really need is to track those who come from site 1 to this page on site 2 and tie back any event they might take on this page to e.g.: any EXM tracking code set on site 1.

In the end of the day each site has its own Analytics implementation and its own report suite in Omniture. So is there a way to "transfer" the cookie information from site 1 to site 2 (on this page only), so 2 cookies will be set with s_fid sent to site 1 report suite and custom visitorID sent to site 2 report suite.

Thanks for the documentation, this will be probably something we will aim to go for the future but now is not resource possible.

BS

Filipe

Filipe,

Thanks for the additional details. It's a bit concerning that site one is using s_fid as that is to be used as a last resort ID. I'd contact Analytics customer care and see if they can figure out why your not getting s_vi cookies on that site.

I'm sure what your asking is possible, it just might not be a supported Adobe implementation. Essentially, you'd need two isolated instances of Analytics code on the pages you wanted to track on site 2 that report back to site 1. These instances would have to use different object variables (s object is default) so that the would not conflict with each other. Having the two separate instances would allow you to send separate server calls for the various report suites and have different IDs for the visitor.

You'd also need to find a way to pass the id being used on site 1 over to the page on site 2. You might be able to do this as a query string parameter that is then read and written to the cookie used by the second Analytics instance. This solution would only work if the visitor is clicking a link on site 1 that takes them directly to the site 2 page that should be tracked.

If there were use cases where visitors on site 2 would also hit that page without coming from site 1 first, you may want to find a way to suppress the second Analytics instance. Perhaps using some logic to check if the query string param exists might work.

Again, this wouldn't be a supported Adobe implementation, so Client Care would be limited in what they could help troubleshoot. I'm just trying to think of options in case you feel confident in trying them on your own.

With that being said, I'd still recommend looking into the ID service. Something like this could be done a lot easier with sites that had the ID service deployed. Implementing the solution I purposed above will likely take a fair amount of development work. It's also development work that will be lost if you later move to the ID service. It might be advantageous to use that development work to start migrating to the ID service.

Best of luck,
Jantzen

I'm glad I was able to help! Thanks for participating in the community! 

Cheers,
Jantzen