Effect and usage of the domainlevel munchkin Initialization Parameter

[SanfordWhiteman]

Oh, absolutely. I find new quirks and bugs all the time and they're not crazy edge cases by any means. Some of them affect other analytics just as much, but missing 1% of non-ID'd GA hits is less directly troubling than missing known lead hits used in trigger campaigns.

[SanfordWhiteman]

Greg, I just DM'd you some JavaScript to automatically detect the best domainLevel based on real-world cookie testing. Probably the best general approach when maintaining a ton of sites that might be visited using a number of hostnames.

The only drawback is that (as I alluded to above) it is still possible for a cookie to become invalidated if a browser is upgraded in-place with a more knowledgeable public suffix list.

For example, imagine a new TLD .zz comes out and a browser doesn't yet have a list of its reserved public suffixes.  You fire up http://gregoire.presse.zz and someone goes to your site.  A cookie can successfully be set on presse.zz, so that becomes your dynamically determined domainLevel and that's where Munchkin starts tracking. Then later the browser gets upgraded and learns that presse.zz is actually a public suffix -- meaning cookies can't be set on that domain, as they would be leaked to anyone who registers a domain under presse.zz.  The browser's safest option is to delete the existing cookie.  The next time the lead goes to http://gregoire.presse.zz, the dynamically determined domainLevel will be gregoire.presse.zz, and they won't have a cookie there yet. 

The above is a rare case, but certainly conceivable.  You could protect against it by always duplicating the current cookie value in localStorage. Then you can restore it if the browser has to "administratively" (i.e. without the user specifically asking) remove a cookie.

[SanfordWhiteman]

Courtney Grimes​ PRODUCTION Robb Barrett​ in your international wheelhouses

[Sean_Richards]

Sanford Whiteman​ I am finding this pretty hard to comprehend.

I have three three domains:

schoolbox.com.au - (main website with munchkin installed)

help.schoolbox.com.au - (subdomain for our online community with munchkin installed)

pages.schoolbox.com.au - (marketo landing pages with munchkin installed)

This list ( https://www.publicsuffix.org/list/public_suffix_list.dat ) lists .com.au as a 2LD. Am I right?

So following your previous statement "must set your domainLevel if you are using any 2-letter TLD"??

Thanks!

[SanfordWhiteman]

.au falls on the correct side of the Munchkin assumption that any 2-letter TLD implies that the public suffix will have 2 parts ("levels") and that thus the shortest private suffix will have 3 levels.

.io and .ly, for two counterexamples, fall on the incorrect side, since it's possible for those TLDs to be a one-part public suffix, and the shortest private suffix has 2 levels.

Setting the domainLevel in all cases is the best practice. It shouldn't be left to guesswork, even when the guesswork is correct.

[SanfordWhiteman]

• on mydomain.fr, mydomain.de, and any domain with a 2 letters TLD, you should force {domainlevel:2} on munchkin inserted on your web site and let Marketo do it's job on Marketo LP templates (I run it that way, and it works)

Never let Munchkin do its job with a 2-letter TLD, even on a Marketo LP.  It doesn't work. Instead, hard-code the domainLevel or use the script I sent you to dynamically detect.

As with other tracking issues, the breakage can be very hard to troubleshoot because

• you have to understand HTTP and DNS, at least to some degree, to know what's really going on
• you may have to test many permutations to find the failure point: it can seem to work in the first n cases, you're feelin' good, and it's only on the next test that you have your A-ha! moment
• the order of tests matters, so it really is permutations and not combinations
• most marketers are (understandably) unfamiliar with setting up a browser lab to test this stuff, so they end up doing live testing in their primary browser and thus confound the results -- for example, by having associated themselves on multiple domains, which is not the real-world lead experience

In the case of the Marketo LP domain pages.example.fr, the reason you may think it's working is that you have clicked multiple tracked links, one to your website and one to your LP domain. That would indeed "work" because you'd have a different associated cookie on both domains.  All activities would be properly credited to your Marketo lead, yes.  But only because you're lucky to have different cookies.  Had you only clicked on tracked links to LPs and then visited the main site, you would be anonymous on the main site.

[Anonymous]

Gregoire - We are rolling our Marketo globally and have a similar use case. The tracking doesn't seem to be working as expected and this thread was very insightful.

[Grégoire_Miche2]

You are welcome

Vote here:

-Greg

[SanfordWhiteman]

Grégoire Michel I finally pubbed this stuff on my blog: http://blog.teknkl.com/munchkin-2-letter-tlds-broken/

[Sheila_Baker__2]

Sanford Whiteman​

Thanks so much for the post on dealing with 2 letter TLDs. [24]7 ha moved from a domain of 247-inc.com to 247.ai. I'm trying to cleanup all the issues.

I've implemented your code on this page: Testing new template 

I added console.info() statements so I can see it is indeed returning 2 level and domain as .247.ai

However, the second part doesn't seem to be working _mkto_trk is still associating to info.247.ai. The only difference in the code is that we never switched to using munckin-beta. Do we have to be using munchkin-beta? If so, what other implications do we need to deal with?

Thanks so much!

Sheila