With GDPR in effect shortly, this is becoming critical. Illumina has enabled the use of Beta munchkin. When we test using marketo_opt_out=true, the cookie mkto_opt_out being set but associated with the subdomain the page is on rather than with the top/root domain. However, _mko_trk is properly being set to the top domain so this isn't something fundamentally wrong with the domain level. The problem with this is if the cookie is dropped on a www.illumina.com page - only www.illumina.com pages stop being tracked. The Marketo landing pages at mkt.illumina.com are still tracked. The same issue happens the other way as well - if the query parameter is added to an mkt.illumina.com page, then we'll stop tracking those pages but not the www.illumina.com pages. There are numerous other subdomains associated with Illumina as well so really need the cookie to be associated with illumina.com so that pages across all the subdomains stop being tracked.
Here are a few example pages to try:
When examining the cookies, you'll see that _mkto_trk is associated with .illlumina.com but mkto_opt_out ends up associated with the subdomain of either www.illumina.com or mkt.illumina.com depending on which page you used. Conversly, you have to set marketo_opt_out=false on each of the subdomain pages in order to have it removed from each subdomain it is on.
Is anyone else experiencing this problem with the Marketo Opt Out functionality? I have submitted this to Support but I thought I would ask on the community for any insights as well.
Ha, I was just working on a blog post on this:
Your observations are accurate. The mkto_opt_out cookie does not obey the Munchkin domainLevel setting (whether manually or automatically set).
The "good" news is that the use of the querystring for this was flawed anyway. (The use of a no-track cookie itself is sound, but I'm talking about how it's set.)
Most people are not going to understand how to add to the querystring before Munchkin initialiizes for the very first time. Even if they know (which is rare on the web side, let alone the marketing side) how to use replaceState, they're not going to change the querystring on the first hit, instead waiting for cookie opt-in to complete and then refreshing the page with the &marketo_opt_out=true appended. As a result, they're still going to track the first hit (with or without the lead's consent) and they're also going to create duplicate pageviews for any other analytics package, and duplicate traffic to their server. Kind of a lose-lose-lose.
So the way to use this functionality is to set the mkto_opt_opt cookie at the topmost private domain yourself, and do it before any calls to Munchkin.init(). Of course you can use findPrivateSuffix to automatically figure out the appropriate domain.
Thank you Sanford Whiteman for confirming that I'm not nuts. I was checking out your blog but I don't see that your article has been posted - at least it's not visible to me. As usual, I gain so much from reading your blog posts. I'm looking forward to reading this one!
Sanford Whiteman One more thing to note.... On emea.illumina.com the web team is already setting the marketo_opt_out cookie at the .illumina.com top-level. However, Marketo is then adding another cookie to emea.illumina.som so they are ending up with two cookies. And if they view a page with an iframe of a Marketo landing page or a full Marketo landing pages (mkt.illumina.com) the opt_out cookie also gets set on .mkt.illumina.com. If they then want to opt in, they need to figure out how to delete the cookies from all of the subdomains, not just .illumina.com since it doesn't work to remove just the cookie from .illumina.com. It gets difficult to work across subdomains to delete cookies so that's one of the issues with how to make this work.
This seems to me like things are really broken with the marketo_opt_out cookie. I have a Support ticket in but not sure how long it will be before anyone responds.
This is why you shouldn't modify the querystring at all. Only set the cookie manually at the correct domain.
If you have unwanted cookies to clean up, use the climbDomains script from here: https://blog.teknkl.com/forms-bug-multiple-munchkin-cookies/
Yeah, we bumped into this issue just last week while trying to get our OneTrust cookie preference center deployed - which is another story in itself in that it's not all that it's cracked up to be. In summary, it's more or less just a cookie scanning and categorization solution. There is still some custom dev work required to get it to properly enable/disable cookies like Munchkin.
Dan, thanks for your comments on OneTrust. I had the same impression when working with them for another client.