Unfortunately, few Marketo experts understand browser networking, and fewer still understand how Munchkin works.
I've written about this several times, though not yet officially at http://blog.teknkl.com. There's no mystery about why web analytics loaders, libraries, and tracking pixels are hurt by increasing layers of indirection (asynchronous and non-guaranteed loading). When you push analytics into the background and say, "I don't care if it completes, as long as the page is quickly interactive," you're calling analytics disposable. But when the CMO expects accurate reports, it's suddenly mission-critical. It can't be both "nice to have" and "must have" at the same time: this collision of interests is the heart of the problem.
When you use GTM, you force all of its dependent scripts to load asynchronously. That means the Munchkin bootstrapper, the Munchkin library, and the request phase of the tracking hit (XHR) all must complete before unfriendly network conditions are encountered (3G+4G being the biggest offenders) and/or the user navigates away from the page. This is the difference between 99.9% tracking accuracy and 99%. A difference that's negligible when a lead abandons anyway, but terrible when you miss an interesting moment.
The impact is felt far less with Google Analytics under Chrome and Firefox, and I have an adapter that greatly improves Munchkin reliability in those same browsers. Users of the adapter have reported a 50-150% improvement -- yes, they were losing more hits than they were getting -- in first-touch tracking w/unprimed browsers. Nothing, however, can be done for other browsers at this point, except for not making mistakes like GTM.
I'd never claim to be a master at program and campaign design, as technical performance and reliability is my wheelhouse. Every day, I fix Marketo "best practices" so they actually work!
Adchoices