Munchkin Code Not Tracking

Anonymous · ‎01-29-2016

Hello Marketo Community,

I am hoping someone can help with an issue related to our Munchkin Tracking Code. Over the last year we have sporadically been receiving web activity & click link activity for user who visit our website This issue has caused us to inaccurately utilize some of the features Marketo currently offers because we are unable to consistently receive web & click link activity.

Below you will find what our current implementation looks like along with our attempts at fixing the problem.

Current Munchkin Tracking Code:

$.ajax({

url: '//munchkin.marketo.net/munchkin.js',

dataType: 'script',

cache: true,

success: function() {

Munchkin.init('###-###-###', {asyncOnly: true});

}

});

</script>

Previous Issue:

XMLHttpRequest.timeout cannot be set for synchronous HTTP(S) requests made from the window context. From: munchkin.js:11

Solution:

set 'asyncOnly: true' flag

References:

We still get what looks like an XHR error when looking at the network tab for "visitWebPage" and also "clickLink".

Activity like stated before is sporadically not tracked. We connect all our forms via the API. The API originally was on a different top level domain which we changed after reading the following Marketo Document; specifically in relation to the sub-section "Domain"

http://developers.marketo.com/documentation/websites/lead-tracking-munchkin-js/

Due to this documentation we moved our forms API on a subdomain of (see below) to resolve this as a potential cause of this issue; but still receive sporadic web & click link activity.

https://api.hexarmor.com/api/marketo/

Below you will also see an instance of a known leads activity log:

As you can see the first activity recorded for the lead is filling out the form but no web or clicklink activity before or after that.

Any help you may be able to give related to this issue would be greatly appreciated. If you need more information please feel free to let me know.

- Mihkey

Anonymous · ‎02-04-2016

Sanford Whiteman has helped me identify the issues with our implementation. One of our issues is that we don't actually need our own API to submit our forms and instead are attempting to move to Forms 2.0 API. I am trying to follow the guide Kenny Elkington post https://nation.marketo.com/blogs/marketowhisperer/2015/09/30/make-a-marketo-form-submission-in-the-b... I am attempting to tackle our issues one at a time, so I have posted a more focused questions about forms 2.0 in that guide.

I would love to know if anyone has experience implementing munchkin tracker in a Rails Turbolinks project. There does not seem to be any information on this subject.

SanfordWhiteman · ‎02-04-2016

I would love to know if anyone has experience implementing munchkin tracker in a Rails Turbolinks project. There does not seem to be any information on this subject.

One of the problems with abstractions like "Turbolinks" is that they obscure the real rules by which any web app must play. In this case when Turbolinks is enabled in uplevel browsers, it's replacing (most of) the document and pushing a new URL (we talked about this on our call the other day). The easiest Turbolinks event to catch this moment is page:receive:

Turbolinks.supported && document.addEventListener('page:receive',function(e){
     Munchkin.munchkinFunction('visitWebPage',{url:e.data.url}); 
});

Note you don't need to worry about backward-compatible attachEvent because TL won't be activated in old browsers anyway.

Andy_Varshneya1 · ‎02-01-2016

Another note - your Munchkin code is towards the bottom of the body tag. Put it in the header.

Anonymous · ‎02-01-2016

Hi Andy

Marketo support told me to put munchkin at the end of <body> section.

He taught me this Docs.

Add Munchkin Tracking Code to Your Website - Marketo Docs - Product Docs

5. Place the tracking code on your web pages right before the </body> tag. New leads that visit this page will be assigned to this lead partition.

And he persisted "RIGHT BEFORE the </body> tag".

I want to know why.

SanfordWhiteman · ‎02-01-2016

When you use the part-synchronous embed code you do want that right before the </body>, because it starts with a blocking download of the bootstrapper. When you use the all-asynchronous embed code, the <head> would be better placement for the Munchkin bootstrapper, and in turn for the actual Munchkin library.

Either way, unless you have a very, very simple page, the actual analytics library is going to end up in the head.

I differ with the docs' recommendation that the all-asynchronous embed code be used by default (the Munchkin docs have factual errors, but this is more one of opinion). As I've written before, all web analytics libraries bear an inherent contradiction:

On the one hand, we mandate that analytics must not impede webpage navigation, rendering, interaction, nor exit -- a low-priority, essentially disposable component.
On the other hand, we require that analytics losslessly captures all interesting activities -- a high-priority, business-critical component of the marketer's toolkit.

These two missions cannot both be accomplished, even if you target only modern browsers. You might lean toward disposability... until you have to explain why your reports don't match with web server logs or other expectations. You might swing toward infallibility... until you see that geographically remote users are struggling with wait times.

Anyway, despite the contradiction, you can at least fit the best browser tech to the task. My Munchkin adapter (which Takehiro uses, or least used to) is one way to go about getting the best of both worlds. That doesn't always mean "async everywhere": it depends on site-specific (and sometimes page-specific) needs.

SanfordWhiteman · ‎01-29-2016

Mihkey, switching to asyncOnly is guaranteed to lose activities, especially Clicked Link.

If you follow and DM me I can supply you with our advanced Munchkin adapter which will clear up the bulk of these issues.

Kenny_Elkington · ‎01-29-2016

So a few things here. Those "aborted" requests you're seeing shouldn't affect tracking. The tracking server will sometimes send reset packets instead of a full response to improve throughput. Do you have an example page that isn't tracking? An example form?

Anonymous · ‎01-29-2016

Kenny Elkington Check out HexArmor.com for examples, this issue occurs across the entire site. Web activity is sporadic at best, and only shows up after a form is filled out if it actually shows up at all. Any ideas?

Kenny_Elkington · ‎01-29-2016

So the visits look to be registering fine. I'd bet on this being a lead association problem. Do you have an example form we could look at?

Anonymous · ‎02-01-2016

Any of the forms present on our site you can take a look at (contact, trial, quote).

SanfordWhiteman · ‎02-01-2016

You're posting to your own custom endpoint (this is risky under load) and not including the Munchkin tracking token, unless you happen to be reading from the cookie and adding it to the form data on the server. If you aren't including the token, it is no surprise at all that your new leads are not getting associated Munchkin sessions.

But that's not the only problem by any means. Even when you have known leads, you have a single-page website (in uplevel browsers) and you haven't attached Munchkin API calls to all your internal navigation events. Some of them work automatically because they also have external-like hrefs. Others do not work because they only have href="#". You would get different results depending on whether the browser is uplevel or downlevel unless you also hook the use of pushState to ensure that all visitors get a Visit Web Page activity.

SanfordWhiteman · ‎01-29-2016

Nah, I can see the lost Visits and some of the technical reasons.