Adding Munchkin to GTM

[Anonymous]

At the end of our Marketo landing pages, we have a parameterized Munchkin init function:

<script type="text/javascript" src="//munchkin.marketo.net//munchkin.js"></script><script>Munchkin.init('123-xxx-456', {parameter1: 'foo', parameter2: 'bar'});
</script>

We use Google Tag Manager across our sites (including our Marketo landing pages), and we would like to include the Munchkin code snippet in it, ie:

<script type="text/javascript">
(function() {
  var didInit = false;
  function initMunchkin() {
    if(didInit === false) {
      didInit = true;
      Munchkin.init('123-xxx-456');
    }
  }
  var s = document.createElement('script');
  s.type = 'text/javascript';
  s.async = true;
  s.src = '//munchkin.marketo.net/munchkin.js';
  s.onreadystatechange = function() {
    if (this.readyState == 'complete' || this.readyState == 'loaded') {
      initMunchkin();
    }
  };
  s.onload = initMunchkin;
  document.getElementsByTagName('head')[0].appendChild(s);
})();
</script>

Would that override/break the parameterized Munchkin code that is already being included on our pages?

Thanks in advance!

Mary

[Kenny_Elkington]

It's highly recommended that you do not use GTM for munchkin on your Marketo LPs.  You will lose the ability to filter web page visits on your landing pages names if you do so.

[Dan_Stevens_]

Hi Kenny Elkington​ - we use GTM on our Marketo LPs and are able to filter/trigger on the Marketo LP name (vs. the URL) in our smart lists.  For example:

Are you referring to something different?

[Dan_Stevens_]

I just ran another test using a simple filter:

...and all Marketo LP URLs were identified as invalid (vs. using the actual program.pagename like I have above).  Is this a result of using GTM on our Marketo LPs?

Sanford Whiteman​

Kenny Elkington​

[SanfordWhiteman]

Looks like it, yes, because you don't get the customName populated when you officially disable Munchkin.  There's a way around this, though.  When I get back from clients tomorrow I can tell you about it...

[Dan_Stevens_]

I'm actually having one of the members of my team simply disable Munchkin from GTM on all of our Marketo LPs (we'll still use GTM for other tracking code like DemandBase and GA) - and instead use the default Munchkin code that Marketo already includes on all LPs.  That should fix it, no?

[SanfordWhiteman]

Yep!

[Dan_Stevens_]

To my surprise, we haven't been using GTM for Munchkin on Marketo LPs - we've always excluded Munchkin.  Which begs the question, why only 4 (out of hundreds) LP URLs available in the filter drop-down?  The internal page names show up fine, but not the actual URLs (and yes, we make sure to pre-load them well ahead of time so that Marketo can index the values). Any thoughts?

[Anonymous]

Thanks Kenny, we have decided to use GTM to serve Munchkin everywhere except our Marketo landing pages - it seemed to be the most intuitive solution.

[SanfordWhiteman]

I don't recommend using GTM for Munchkin in either case if you want the greatest tracking accuracy.  You may be dealing with the difference between 99.9% accuracy and 99.99% -- but with high-traffic sites that difference is significant.

Outside of GTM, it is sometimes necessary to remove Munchkin from Marketo LPs and re-add it manually in order for tracking to work as expected. To do this safely (without losing friendly names as Kenny mentions) requires a little hackwork that maybe I should blog about sometime.

[Anonymous]

I probably understand why you say you don't recommend it, but the appeal of managing it all under one roof has a strong appeal - is it worth possibly losing the 0.09% accuracy? Maybe yes, maybe no - guess it depends who you ask. A post on that hackish (ie., poetic!) solution would be an interesting read. Although, I have resolved to the fact that munchkin gets added to the Landing Pages by unicorn magic and if there's one thing life has taught me, it's not to mess with the unicorns.

[SanfordWhiteman]

If you get 10000 unique visitors a day, you could be losing source information for 9 of them; if you get 100,000 unique page views per day, you could be missing 90 of them from your Marketo logs, triggers, etc.  (The actual numbers can be significantly higher depending on the geographic distribution of your leads.)

Now, the optimist decides those you can't see would be the ones you wouldn't want to see (by pure coincidence, of course, as there's no relationship!). The pessimist says there's no way to know this.

[Grégoire_Miche2]

Hi Sanford Whiteman and Kenny Elkington

I observe that more and more companies will want to use GTM to handle the munchkin in order to comply with the cookie opt-in directives: GTM handles it and either activate or deactivate all cookies, including Marketo's, when the visitor chooses to opt-out.

-Greg

[SanfordWhiteman]

I know they are!  They're not thinking about the impact, though, piling on the ill-advised notion of "indirection everywhere." Then they wonder why they lose data! Of course if you use my Munchkin Enhanced adapter you can deal with a lot of that...

[Grégoire_Miche2]

I should have known you also had this one covered

You need to tell us more on this now. It's either too much or too little...

-Greg

[SanfordWhiteman]

If only someone else cared besides you, Greg!

[Liliana_Cheng1]

Hey Sanford Whiteman​, I'm interested in hearing more about GTM disadvantages. We don't use Marketo LPs at all, only wordpress and GTM, but we are considering hardcoding the munchkin and removing GTM. Would like to understand the benefits and disadvantages before we make the move though.

[SanfordWhiteman]

There's no accuracy advantage to running Munchkin via GTM, only disadvantages.  There are (to some people) manageability advantages, but I care about accuracy first.

What people fail to reason through when adding analytics scripts (I detest the term "tags") is that if analytics is mission-critical -- and every CMO says it is -- pageviews, especially the first pageview on a device, must be logged before the lead navigates away from the page.  Yet the more preconditions and dependencies you add before Munchkin can finally load its tracking pixel, the less seriously you're taking analytics.

So these are clearly conflicting priorities.  If you want processes to complete before the person leaves the page, you want them closer to the synchronous, must-complete foreground.  If you don't want scripts to ever interfere with page rendering, nor vice versa, then you want them in the asychronous, best-effort background. You can't have it both ways.

There's rarely a practical problem on high-speed, low-latency connections, though.  The devil is in low-speed, high-latency connections.  The 3G connection, the train in a tunnel, the spotty shared wifi, long geographic distances. Built-in network limitations of mobile devices make it even worse.  If you serve 30 asynchronous scripts to a smart phone on a low-quality connection, don't expect all the tags to their jobs.

GA has some techniques that make background analytics more reliable (but then GA's servers are more reliable in general).  My Munchkin Enhanced library adds some of those extensions to Munchkin, but it can't cover all the bases. I always recommend that my clients use the simple embed code (which removes only one async layer -- there are still two required async calls), or, even better, load the tracking pixel directly (this requires server-side coordination).

In all, we may be talking about the difference between 99.99% and 99.999% of requests not completing.  However, if you're generating 100K requests per day, that's 900 misses, and the failures are going to be weighted toward first-time visitors with unprimed caches -- people you definitely want to see.

Look, it's not the end of the world, but I think once you're aware of the risks, you want to mitigate them.

[Liliana_Cheng1]

Thanks, Sanford. Helpful as usual!

[Grégoire_Miche2]

Hi Sanford,

The reason people most often use to justify the use of GTM to run munchkin is that they use GTM to control cookie opt-in and therefore will want to also control munchkin with the same cookie opt-in controller.

We do not want to have 2 cookie opt-in mechanisms and prompts, obviously, one for the Marketo munchkin and another one for the other cookies.

How would you approach this then?

-Greg

[SanfordWhiteman]

The mechanism is still using a cookie or the Storage API to persist the opt-in/opt-out value, right? So trigger on that value directly.