25 Replies Latest reply on Nov 28, 2017 8:09 AM by Sheila Baker (247)

    Effect and usage of the domainlevel munchkin Initialization Parameter

    Grégoire Michel

      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

        • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
          Sanford Whiteman

          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 of 1 people found this helpful
            • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
              Grégoire Michel

              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.

                • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                  Sanford Whiteman

                  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...

                    • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                      Grégoire Michel

                      Hi again Sanford,

                       

                      So it's really bugged!

                       

                      -Greg

                        • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                          Sanford Whiteman

                          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:

                           

                          1. 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.
                          2. 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.
                          3. 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).
                          4. 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 of 5 people found this helpful
                      • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                        Sanford Whiteman
                        • 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 of 1 people found this helpful
                        • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                          Uday Devineni

                          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.

                        • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                          Sheila Baker (247)

                          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

                            • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                              Grégoire Michel

                              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

                                • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                                  Sanford Whiteman

                                  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});
                                  
                                    • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                                      Grégoire Michel

                                      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

                                          • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                                            Grégoire Michel

                                            Ho, my bad I probably need to go to bed...

                                             

                                            -Greg

                                            • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                                              Sheila Baker (247)

                                              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

                                                • Re: Effect and usage of the domainlevel munchkin Initialization Parameter
                                                  Sanford Whiteman

                                                  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.