Munchkin Code Not Tracking

SanfordWhiteman
Level 10 - Community Moderator

Re: Munchkin Code Not Tracking

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.

Anonymous
Not applicable

Re: Munchkin Code Not Tracking

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
Level 10 - Community Moderator

Re: Munchkin Code Not Tracking

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.