Hi Sanford,
Unfortunately we still can't seem to get it working... my developer added this code to Domain A:
<script>
$( document ).ready(function() {
//Get all links from the page
$('a').each(function() {
//Get the exist URL
var existUrl = $(this).attr('href');
if(existUrl == 'https://Domain B'){
//Change the existing URL to new one
$(this).attr('href', 'https://Domain B&munchkinCookie=cookieValue');
}
});
});
</script>
But I'm not sure this is correct for picking up the cookie value, because there are two instances of Marketo Munchkins on Domain A (one for prod and the other for test), and this code doesn't specify which one it should pick up...
We currently have cross domain tracking working for Google analytics set up by a previous employee so all links leaving Domain A to Domain B is tagged like https://Domain B?_ga=1.0000000.0000000000.0000000000 so it is do-able but I just don't have access to that person to see how it was done.
That code is kinda clunky -- you only need one *= attribute selector to find the <A>s you need -- but that's cosmetic.
The thing is, you are passing the Munchkin cookie value to Domain B, but I'm guessing you aren't doing anything with it! Just having a query param munchkinCookie doesn't do anything. I mean, it's a requirement, but it's not enough. You also need to init() with that value as the visitorToken.
Why don't you PM me and then we can solve it offline? I suspect you're almost there but your Domain B dev isn't implementing the other side.
Also, I hope your Domain A dev didn't literally put
'&munchkinCookie=cookieValue'
but rather more like
'&munchkinCookie=' + cookieValue
otherwise, they aren't even passing the value over. So I hope that isn't the verbatim code.
Sanford,
We are trying to do something similar but we might need your expertise. Would you be willing to help us out and have some time to talk with us about it?
Hi Chloe,
Just remember one thing : reading a cookie from domain A when the lead is navigating in domain B is considered as a Cross-Scripting (XSS) technique and is considered as extremely bad practices, if not illegal, in many countries even if the 2 domains belong to the same company.
At some point, development is not everything. You may need to have people to fill out a form in each domain, so that Marketo can automatically merge the 2 leads based on email address. In order to create a Marketo LP in a second domain, you can use domain aliases (Add Additional Landing Page CNAMEs - Marketo Docs - Product Docs )
There is a lot said here as well :
-Greg
Just remember one thing : reading a cookie from domain A when the lead is navigating in domain B is considered as a Cross-Scripting (XSS) technique
Reading a first-party cookie is not illegal in any country. At no time are you reading a third-party cookie, which is technically impossible in all modern browsers.
Note that every single Munchkin hit and Marketo form post transport a first-party cookie from your domain to Marketo's domain.
Compliance with EU cookie law is ensured by prompting for consent on any main document regardless of shared data control. This is not mutually exclusive with transporting cookie values. It means that the person needs to consent on domain A and on domain B.
Believe me when I say that working in a highly regulated international financial company, we have vetted cookie policies.
At some point, development is not everything. You may need to have people to fill out a form in each domain, so that Marketo can automatically merge the 2 leads based on email address.
No, custom development fixes this problem just fine.
Hi Sanford,
I understand here that the issue is that, as the web site and the portal are on separate domains, the need it to have the Marketo known lead reconciled to 2 cookies (the website one and the portal one).
I understand that :
I just wanted to point out that reading the website cookie from the portal is invalid, because they are separate domains.
-Greg
Reading the cookie values *as cookies* cross-domain -- that is, peeking into the browser's cookie database directly -- is expected to be impossible. This restriction is enforced by the browser itself. To attempt to circumvent it means exploiting unfixed browser bugs or vulnerable plugins, so it's obviously unethical, not to mention unreliable.
But this really has nothing to do with how you properly transmit cookie values *as strings* across domains. There are numerous technologies that allow sharing text values this way, all of them perfectly legal and technically reliable. No webhooks required.
- have a wrong cookie value, if people send their URL to someone else.
That's why, if you were choosing this method, you either use a POST (like Marketo does to share session cookies); GET and redirect the user to a page without the query param; or replace the querystring or hash using JavaScript immediately when the page renders.
- If you want to reconcile both the website cookie and the portal cookie, which what is intended here, you will have to combine the 2 approaches above. This means that you will have to store the 2 cookies (the one from the portal, the one collected from the URL parameter) in 2 separate fields and call the webhook twice (or create a webhook that can handle 2 cookies).
You have to transmit the cookie values as strings across domains.
Also note: whenever you switch from the Marketo Admin UI to the Marketo Designer (two different domains) your session cookie is transported cross-domain using HTTP POST. I have no problem with that as it's one of several common solutions. I have a feeling you're not aware of how often you and the sites you use are actually using such methods!