-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sanford Whiteman Jan 31, 2016 10:47 PM (in response to Grégoire Michel)1 of 1 people found this helpfulQuestion 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.
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Grégoire Michel Feb 1, 2016 12:39 AM (in response to Sanford Whiteman)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 Jan 31, 2016 1:11 PM (in response to Grégoire Michel)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 Jan 31, 2016 1:15 PM (in response to Sanford Whiteman)Hi again Sanford,
So it's really bugged!
-Greg
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sanford Whiteman Jan 31, 2016 10:48 PM (in response to Grégoire Michel)5 of 5 people found this helpfulYes, 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.
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Grégoire Michel Jan 31, 2016 3:59 PM (in response to Sanford Whiteman)That's a comprehensive answer!
Would indeed be worth a blog post.
Thanks very much.
-Greg
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sanford Whiteman Jan 31, 2016 4:09 PM (in response to Grégoire Michel)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.
-
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Grégoire Michel Jan 31, 2016 4:09 PM (in response to Sanford Whiteman)1 of 1 people found this helpfulThe 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
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Grégoire Michel Jan 31, 2016 4:10 PM (in response to Sanford Whiteman)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
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sanford Whiteman Jan 31, 2016 4:24 PM (in response to Grégoire Michel)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.
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sanford Whiteman Jan 31, 2016 9:53 PM (in response to Grégoire Michel)1 of 1 people found this helpfulGreg, 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.
-
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sanford Whiteman Jan 31, 2016 6:58 PM (in response to Sanford Whiteman)Courtney Grimes Robb Barrett in your international wheelhouses
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sean Richards Oct 4, 2018 9:10 PM (in response to Sanford Whiteman)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!
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sanford Whiteman Oct 4, 2018 9:29 PM (in response to Sean Richards).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.
-
-
-
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sanford Whiteman Jan 31, 2016 10:43 PM (in response to Grégoire Michel)1 of 1 people found this helpful- 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.
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
cb9b70945297c4c5a9a00fb338056db9890c4316 Jul 17, 2017 3:10 PM (in response to Grégoire Michel)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
Sanford Whiteman Sep 30, 2016 2:17 PM (in response to Grégoire Michel)Grégoire I finally pubbed this stuff on my blog: http://blog.teknkl.com/munchkin-2-letter-tlds-broken/
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sheila Baker (247) Nov 21, 2017 6:54 AM (in response to 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 Nov 21, 2017 2:33 PM (in response to Sheila Baker (247))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 Nov 21, 2017 2:49 PM (in response to Grégoire Michel)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
Sanford Whiteman Nov 21, 2017 3:01 PM (in response to Grégoire Michel)Sheila wants it at 247.ai, though.
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Grégoire Michel Nov 21, 2017 3:28 PM (in response to Sanford Whiteman)Ho, my bad I probably need to go to bed...
-Greg
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sheila Baker (247) Nov 27, 2017 11:03 AM (in response to Sanford Whiteman)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 Nov 27, 2017 9:57 PM (in response to Sheila Baker (247))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.
-
Re: Effect and usage of the domainlevel munchkin Initialization Parameter
Sheila Baker (247) Nov 28, 2017 8:09 AM (in response to Sanford Whiteman)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
-
-
-
-
-
-
-