Dear all analytics professionals,
I was trying my best to track cross-domain tracking but I guess I ran into a deadlock.
Here is my case:
I have a domain A. Several pages have iframed(?) form in the page sourcing from Domain B.
In other words, a page has domain A url but its form contents are coming from Domain B.
I am using DTM and I placed same DTM embed code between Domain A and Domain B.
Now I can implement Adobe Analytics tags to Domain B's forms' submit button but this click call does not include mid value.
( I installed Experience Cloud ID Service too.) The submit data is collected but I need to map them by a unique ID.
What I found out was AppendVisitorIDsTo (Cross-Domain Tracking) but when I install this rule in DTM,
Has it to be all page rules? I published the rule but the site had an error, all pages were not loaded. T.T
Please help me out!!
Note sure whether AppendVisitorIDsTo will help for iframes.
Also, i don't understand your statement "I placed same DTM embed code between Domain A and Domain B".
You should place DTM code both in Domain A and Domain B so that the codes work properly.
Yes I did place DTM code both in Domain A and Domain B.
My problem is the server call from Domain B has no cookie value matching to the one from Domain A.
If that is the case, make sure you ask these questions.
1. Is the the cookiedomain set properly for both the domains?
2. The namespace for the tracking is the same on both domains?
3. Are the trackingservers set to be the same across both domains?
I set the same tracking servers and experience id service.
But I don't know what you mean by namespace for the tracking' and the cookiedomain set.
Have validated the Domains as given internally.
Domain A is having cookie period : 2.
By default, cookie domain period is set to 2 and thus you don't want to set this explicitly in your base code within DTM.
So, it supported the cookie : Below the screen grab.
Domain B is having cookie period : 3. Since you didn't add the cookie domain variable, the domain didn't support. Check your debugger. It will be showing 'N' against the variable i shown above : Below the screen grab.
Your fix now is to set cookie domain period to 3 in your base code under configuration variable. Checkout the link : s.cookieDomainPeriods . It should be set only for Domain B.
If you are using same base code for Domain A and Domain B, use 'if' condition or dynamic data layer to set the same dynamically.
I really appreciate your sincere support. I solved the cookieDomainPeriods problem and now I see "Y" in cookie supported on domain B too. But Domain A is generating mid, which is experience cloud id but Domain B is generating s_fid, which is fallback id.
Now should I tag AppendVisitorIDsTo ?
Sorry for the late revert.
Actually AppendVisitorIDsTo is needed only if your browser/domain didn't allow third party cookie.
Even for us, in UAT, the visitor ID didn't match and fallback id is generated for one of two domains. But when we pushed it live, it worked.
Might be due to UAT/Firewall restrictions on the internal network. Push the tag to live for an URL and verify it.
Thank you for your advice. I checked raw data from Data Warehouse but different visitorID generated for each domain. I will use this raw data to DMP implementation so I really need to identify unique visitors across 2 different domains by one unique ID value. Is there any solution for this?
If your browser supports 3rd party cookie, it should solve your case : See How the Experience Cloud ID Service Requests and Sets IDs.
Also, please ensure that you have also set Cookie Domain Periods within MCID Tool using Dynamic Data Layer Value under Settings Tab:
If everything is done, I am pretty not sure on the solution. Let's wait for others advice.
Did you mean this?
1) Create data element which returns DomainA and DomainB
2) In Settings
cookieDomain = %data element%
I set this and get experience ID from DomainB too but they still don't match.
A few things I can think of:
Yes. I meant the same.
If you still didn't see, you should consider the comments from Gigazelle. Or else reach customer care for debugging.