Effect and usage of the domainlevel munchkin Initialization Parameter

[Grégoire_Miche2]

I was told a while ago by support that when using the munchkin tracking on a domain which top level domain had only 2 letters, we had to set the domainlevel munchkin init parameter to 2.

Reading the doc, it seems that this parameter has a totally different effect :

Sets the number of pieces from the page’s domain to use when setting the domain parameter of the cookie: domainLevel: 2 will set the domain parameter to “.example.com,” while domainLevel: 3 will set the cookie to “.www.example.com.”

Based on this doc, it seems that the use of it would be to handle situations such as mydomain.co.uk (common UK URL) or mydomain.com.br (Common Brazilian one) (in which cases it should be set to 3)

Question 1: Who is right, the support or the doc ?

Question 2: I also gather from the fact that the parameter is not usually needed when on a mydomain.com domain, the default value is 2. Is this correct ?

Question 3: do I have to change it on a Marketo LP that is hosted in a mydomain.com.br ?

-Greg

[SanfordWhiteman]

Courtney Grimes​ PRODUCTION Robb Barrett​ in your international wheelhouses

[Grégoire_Miche2]

Hi again Sanford,

And there are some sites that are dealing with the bugs right now: they're missing Munchkin activities and they don't why.

I think some sites are having tracking bugs and have not even noticed

-Greg

[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]

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.

[Grégoire_Miche2]

The subsidiary question is: how do we modify the default munchkin on a Marketo hosted LP using a guided template ?

Answer, if I'm not mistaken, is:

1. edit the template
2. on menu Template actions -> Disable munchkin tracking
3. add the munchkin code (from admin -> munchkin) with the {domainlevel:2} just before the </body>
4. approve the template

-Greg

[Grégoire_Miche2]

That's a comprehensive answer!

Would indeed be worth a blog post.

Thanks very much.

-Greg

[SanfordWhiteman]

Maybe you could make a tech space on your blog and post a translation... I'm just a lot better at blog-length answers than actual blogging.