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 · Accepted solution]

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.

[Grégoire_Miche2]

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.

[SanfordWhiteman]

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

[Grégoire_Miche2]

Hi again Sanford,

So it's really bugged!

-Greg

[SanfordWhiteman]

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.

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

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

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