AnsweredAssumed Answered

Effect and usage of the domainlevel munchkin Initialization Parameter

Question asked by Grégoire Michel on Jan 31, 2016
Latest reply on Oct 4, 2018 by Sanford Whiteman

Like • Show 1 Like1
Comment • 27

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

Sanford Whiteman Jan 31, 2016 10:47 PM

Correct Answer

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

The doc is more correct, but the overall picture is more complex (and has major bugs).

When computed dynamically, the domainLevel does take into account the number of letters in the TLD. The effort is to intuit the registered domain (the highest level at which the browser will let you set cookies) but it clearly does not always work.

When you set it statically, the domainLevel doesn't have any direct relationship to the number of letters in any component. You should set it to the true level at which you want to set the cookie, even if the domain is my www.example.somereallylongtld.

Question 2: [O]n a mydomain.com domain, the default value is 2. Is this correct ?

When specifically on an example.com domain, yes.

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

No, because it will dynamically set to 3 but I would set it manually anyway.

See the reply in context

No one else had this question

Outcomes

27 Replies

Sanford Whiteman Jan 31, 2016 10:47 PM
Unmark Correct
Correct Answer
```
Question 1: Who is right, the support or the doc ?
```
The doc is more correct, but the overall picture is more complex (and has major bugs).

When computed dynamically, the domainLevel does take into account the number of letters in the TLD. The effort is to intuit the registered domain (the highest level at which the browser will let you set cookies) but it clearly does not always work.

When you set it statically, the domainLevel doesn't have any direct relationship to the number of letters in any component. You should set it to the true level at which you want to set the cookie, even if the domain is my www.example.somereallylongtld.
```
Question 2: [O]n a mydomain.com domain, the default value is 2. Is this correct ?
```
When specifically on an example.com domain, yes.
```
Question 3: [D]o I have to change it on a Marketo LP that is hosted in a mydomain.com.br ?
```
No, because it will dynamically set to 3 but I would set it manually anyway.
1 person found this helpful
Like • Show 0 Likes0
Actions
- Grégoire Michel @ Sanford Whiteman on Feb 1, 2016 12:39 AM
  Mark Correct
  Correct Answer
  Hi Sanford,
  
  Thx, that is much clearer.
  
  So, for anyone else involved in an International roll-out and reading this post (Please Sanford correct me if I am wrong) :
  on mydomain.com and any domain with a 3 letters TLD, ..., you should leave the default value and use the munchkin code as provided by Marketo, unless you observe tracking failure (look at Marketo _mkto_trk cookie and see at which domain it is set)
  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 ALSO REPLACE DEFAULT Marketo MUNCHKIN ON LP templates
  on mydomain.co.uk, mydomain.com.br, you should force {domainlevel:3} parameter and also add manually the changed munchkin code to your Marketo landing page templates.
  
  -Greg
  
  EDIT : corrections made following Sanford's comments below.
  Like • Show 1 Like1
  Actions
  - Sanford Whiteman @ Grégoire Michel on Jan 31, 2016 1:11 PM
    Mark Correct
    Correct Answer
    Ah, not quite! Notice I bolded ".com" in my response because that's what you were spec'ly asking about. The same does not apply to other TLDs. Even when the registered domain is, factually, the second-level domain, if the TLD has 2 letters Munchkin makes erroneous assumptions about the registered domain.
    
    So actually .fr is treated like .com.br which obviously is incorrect. Munchkin default works for the latter, as I said, but not the former.
    
    I'll write more later as I had to step out for a bit and mobile is not the way to post...
    Like • Show 0 Likes0
    Actions
    - Grégoire Michel @ Sanford Whiteman on Jan 31, 2016 1:15 PM
      Mark Correct
      Correct Answer
      Hi again Sanford,
      
      So it's really bugged!
      
      -Greg
      Like • Show 0 Likes0
      Actions
      - Sanford Whiteman @ Grégoire Michel on Jan 31, 2016 10:48 PM
        Mark Correct
        Correct Answer
        Yes, it is quite buggy. Luckily -- due largely to coincidence -- most sites will not encounter the bugs. Yet because they've dodged the bugs due to luck as opposed to deliberate configuration, a seemingly minor change to site architecture can wreak havoc on tracking. And there are some sites that are dealing with the bugs right now: they're missing Munchkin activities and they don't why.
        
        First, some info about the modern web, domains, and cookies:
        
        It is no longer traditional to have a site's canonical user-facing address be http(s)://www.{{zone apex of registered domain}} as opposed to http(s)://{{zone apex of registered domain}}, redirecting people from http://example.com to http://www.example.com. While many sites have stuck with the old model, many huge and/or new sites use the reverse model: Twitter is a great example, as their canonical site is https://twitter.com, not https://www.twitter.com. The reasons for this change are many, including 140-character length restrictions and improvements to modern CDNs to embrace zone apexes. The end result is that you can't predict, without actually visiting a site, whether it uses the old or new style.
        It is no longer safe to assume that private organizations registering under a 2-letter ccTLD will be forced to register a 3rd-level domain (3LD) instead of a 2nd-level domain (2LD) right off the TLD. Frankly, such an assumption was always deeply risky: .fr is a good example of a venerable 2-letter public domain with privately registered domains hanging right off it. But it was at least less risky in the past, when .uk implied .co.uk and .jp implied .co.jp. Now, ccTLD operators are openly inviting private, foreign organizations to register 2LDs, such as .io and .ly, which have become "cool" for cloud companies. With enough money and/or a locally incorporated entity, it's now easy to register right under a 2-letter TLD.
        Most sites will want to track visits across all subdomains, meaning they want to set Munchkin cookies on .{{zone apex of registered domain}}. The level of the registered domain, however, is utterly impossible to derive using just the length of the TLD. For subsume.io the registered domain is an 2LD; for subsume.co.jp the registered domain is a 3LD. There are no rules that can help you here, only a human-curated list like the Public Suffix List. If the latest PSL or equivalent is incorporated into your browser, an accurate method is to see how high up you can write and read a cookie -- though the result will be different depending on the version of the PSL and old browsers will let you set higher than newer ones (in fairness, this can be okay as long that same browser never gets updated).
        A small minority of sites may want to lock the cookie to only the current origin, such as only tracking hits to www.example.com and not pages.example.com. While small, this factor also complicates magically figuring out the best domain without deliberate configuration.
        
        The principal problem is that Munchkin believes the length of the TLD is meaningful for predicting the registered domain when, as you can see in [2] above, this is plainly untrue. For example, I can register figureone.mx. If I go to http://www.figureone.mx Munchkin assumes the registered domain is the 3LD www.figureone.mx and sets a cookie accordingly. If I go to http://info.figureone.mx Munchkin assumes the registered domain is the 3LD info.figureone.mx and sets a new cookie accordingly. I'm sure you can see that can create a very difficult to troubleshoot situation... a tracking disaster.
        
        The reason I mentioned that example.com works without further config is that Munchkin's intuition works for .com. It also works for example.com.br because .br requires registrants to have a 3LD (3LD.{{mandatory public suffix SLD}}.TLD).
        
        Adding additional confusion is that if your main site uses the new-style http://{{zone apex}} as in [1] with a TLD like .io, you can get different results depending on whether someone hits your main site first or your Marketo-hosted LPs!
        
        Bottom line: must set your domainLevel if you are using any 2-letter TLD, should set your domainLevel always.
        5 people found this helpful
        Like • Show 1 Like1
        Actions
        Grégoire Michel @ Sanford Whiteman on Jan 31, 2016 3:59 PM
        Mark Correct
        Correct Answer
        That's a comprehensive answer!
        
        Would indeed be worth a blog post.
        
        Thanks very much.
        -Greg
        Like • Show 0 Likes0
        Actions
        Sanford Whiteman @ Grégoire Michel on Jan 31, 2016 4:09 PM
        Mark Correct
        Correct Answer
        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.
        Like • Show 0 Likes0
        Actions
        Grégoire Michel @ Sanford Whiteman on Jan 31, 2016 4:09 PM
        Mark Correct
        Correct Answer
        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:
        edit the template
        on menu Template actions -> Disable munchkin tracking
        add the munchkin code (from admin -> munchkin) with the {domainlevel:2} just before the </body>
        approve the template
        
        -Greg
        1 person found this helpful
        Like • Show 0 Likes0
        Actions
        Grégoire Michel @ Sanford Whiteman on Jan 31, 2016 4:10 PM
        Mark Correct
        Correct Answer
        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
        Like • Show 0 Likes0
        Actions
        Sanford Whiteman @ Grégoire Michel on Jan 31, 2016 4:24 PM
        Mark Correct
        Correct Answer
        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.
        Like • Show 1 Like1
        Actions
        Sanford Whiteman @ Grégoire Michel on Jan 31, 2016 9:53 PM
        Mark Correct
        Correct Answer
        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.
        1 person found this helpful
        Like • Show 0 Likes0
        Actions
        Sanford Whiteman @ Sanford Whiteman on Jan 31, 2016 6:58 PM
        Mark Correct
        Correct Answer
        Courtney Grimes Robb Barrett in your international wheelhouses
        Like • Show 0 Likes0
        Actions
        Sean Richards @ Sanford Whiteman on Oct 4, 2018 9:10 PM
        Mark Correct
        Correct Answer
        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!
        Like • Show 0 Likes0
        Actions
        Sanford Whiteman @ Sean Richards on Oct 4, 2018 9:29 PM
        Mark Correct
        Correct Answer
        .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.
        Like • Show 0 Likes0
        Actions
  - Sanford Whiteman @ Grégoire Michel on Jan 31, 2016 10:43 PM
    Mark Correct
    Correct Answer
    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.
    1 person found this helpful
    Like • Show 0 Likes0
    Actions
  - cb9b70945297c4c5a9a00fb338056db9890c4316 @ Grégoire Michel on Jul 17, 2017 3:10 PM
    Mark Correct
    Correct Answer
    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.
    Like • Show 0 Likes0
    Actions
    - Grégoire Michel @ cb9b70945297c4c5a9a00fb338056db9890c4316 on Jul 18, 2017 2:36 PM
      Mark Correct
      Correct Answer
      You are welcome
      
      Vote here: Automate management of 2 letter top domains in munchkin
      
      -Greg
      Like • Show 0 Likes0
      Actions
Sanford Whiteman Sep 30, 2016 2:17 PM
Mark Correct
Correct Answer
Grégoire I finally pubbed this stuff on my blog: http://blog.teknkl.com/munchkin-2-letter-tlds-broken/
Like • Show 0 Likes0
Actions
- Sheila Baker (247) @ Sanford Whiteman on Nov 21, 2017 6:54 AM
  Mark Correct
  Correct Answer
  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
  Like • Show 0 Likes0
  Actions
  - Grégoire Michel @ Sheila Baker (247) on Nov 21, 2017 2:33 PM
    Mark Correct
    Correct Answer
    Hi Sheila,
    
    No, you do not have to activate Muchkin Beta.
    
    The code on your page works fine and the cookie is posted to the domain, not the sub domain.
    
    If you have old cookies in your browser, from previous navigations, clean before testing.
    
    But you munchkin call are at the bottom of the body and you are using a synchronous version.
    
    You should rather use an unsynchronous version of the code and post it before the </head> tag.
    
    -Greg
    Like • Show 0 Likes0
    Actions
    - Sanford Whiteman @ Grégoire Michel on Nov 21, 2017 2:49 PM
      Mark Correct
      Correct Answer
      The code on your page works fine and the cookie is posted to the domain, not the sub domain.
      Actually, Sheila's right. It's setting at .info.247.ai.
      
      The reason is the code needs to look like this:
      
      var tldinfo = findPrivateSuffix({cache:false}).domainLevel;
      
      not just
      
      var tldinfo = findPrivateSuffix({cache:false});
      Like • Show 0 Likes0
      Actions
      - Grégoire Michel @ Sanford Whiteman on Nov 21, 2017 2:53 PM
        Mark Correct
        Correct Answer
        HI Sanford,
        
        Weird, on my Mac, it appears to be set correctly
        
        May be it's because my computer is so used to 2 letters TLD that it now automatically fixes the bug If only this could be true.
        
        -Greg
        Like • Show 0 Likes0
        Actions
        Sanford Whiteman @ Grégoire Michel on Nov 21, 2017 3:01 PM
        Mark Correct
        Correct Answer
        Sheila wants it at 247.ai, though.
        Like • Show 0 Likes0
        Actions
        Grégoire Michel @ Sanford Whiteman on Nov 21, 2017 3:28 PM
        Mark Correct
        Correct Answer
        Ho, my bad I probably need to go to bed...
        
        -Greg
        Like • Show 0 Likes0
        Actions
        Sheila Baker (247) @ Sanford Whiteman on Nov 27, 2017 11:03 AM
        Mark Correct
        Correct Answer
        Now that I'm back from Thanksgiving... hope you both took a few days off too.
        
        Thanks for responding. I made the fix on the page and I'm getting it set to .247.ai now.
        
        Just to make sure I'm clear, without implementing your nifty code, _mkt_trk is being set to .info.247.ai on the Marketo landing pages and .www.247.ai on the main website. Only the info.247.ai has forms making it the only place for a lead to become known. This means we are loosing the activities from the main website which is the whole reason to go to the trouble of adding in your nifty code. I'm a bit confused as to what is happening once the person becomes known... there are comments at the bottom of your blog post that indicate that once they become known, we'll loose all previous activities but that moving forward the activites for both will be logged in Marketo. Am I interrpurting this correctly?
        
        Also, there is a comment "rest assured that there's a way to merge the activities and it's not too difficult. I'll put up a follow-up post w/the recipe." Did that follow-up post happen? I've looked for it but didn't find it. Did you ever create the follow-up post?
        
        Lastly, would you recommend that I implement the climbDomains routine to clear out the other sub-domains? If so, does it matter where on the page I put it - specifically before or after call to findPrivateSuffix?
        
        Thanks again! You are awesome.
        Sheila
        Like • Show 0 Likes0
        Actions
        Sanford Whiteman @ Sheila Baker (247) on Nov 27, 2017 9:57 PM
        Mark Correct
        Correct Answer
        Just to make sure I'm clear, without implementing your nifty code, _mkt_trk is being set to .info.247.ai on the Marketo landing pages and .www.247.ai on the main website. Only the info.247.ai has forms making it the only place for a lead to become known.
        Actually, they could become known on www.247.ai if they clicks email links to your main website. But regardless of the method used to make the session associated, that association cannot carry across sites unless the cookie is set at the shared parent domain.
        
        there are comments at the bottom of your blog post that indicate that once they become known, we'll loose all previous activities but that moving forward the activites for both will be logged in Marketo. Am I interrpurting this correctly?
        It's not that once they become known you'll lose previous activities. It's that once you set the cookie at the correct parent domain and delete the old cookie:
        
        If they had an existing anonymous cookie at the wrong domain, then anonymous activities logged previously will not be part of the new session, since their cookie will have been regenerated for the right domain. And when the new session becomes associated (by link click or form fillout) those old activities will not be merged into the Activity Log.
        If they had an existing associated cookie at the wrong domain, then their previous activities will remain in their Activity Log. They won't go anywhere. But the freshly generated cookie at the right domain will be anonymous until it, too, is associated.
        
        Also, there is a comment "rest assured that there's a way to merge the activities and it's not too difficult. I'll put up a follow-up post w/the recipe." Did that follow-up post happen? I've looked for it but didn't find it. Did you ever create the follow-up post?
        I did not blog it yet. It's actually not as easy as originally thought, so decided to play it close to the vest on that one... clients only for now!
        
        Lastly, would you recommend that I implement the climbDomains routine to clear out the other sub-domains? If so, does it matter where on the page I put it - specifically before or after call to findPrivateSuffix?
        It doesn't really matter -- I recall it runs totally standalone. You just need to ensure (test!) that you put 247.ai as the domain to skip over.
        
        And you should run climbDomains because on pages that have forms. That's where it matters because forms are confused by multiple cookies.
        Like • Show 0 Likes0
        Actions
        Sheila Baker (247) @ Sanford Whiteman on Nov 28, 2017 8:09 AM
        Mark Correct
        Correct Answer
        Thanks so much for your explanations Sanford. I implemented and tested the climbDomains and it works like a champ. Yes, I tested!
        
        Thanks for always for being so willing to share your knowledge and help others out!
        Regards,
        Sheila
        Like • Show 0 Likes0
        Actions

Effect and usage of the domainlevel munchkin Initialization Parameter

Outcomes

Related Content

Recommended Content

Incoming Links