Enabling Munchkin on Marketo Landing Pages

[SanfordWhiteman]

Dan, it can be very hard to audit/notice Munchkin issues.  I assume you're losing some actions here and there by adding another layer of indirection, since even with native embedding some analytics requests never complete (never mind the response, which doesn't matter).  Admittedly, the bigger responsibility falls on Munchkin itself, but more "callback h—l" never helps. Sorry to do this to you, but:

Granted, the view may have actually registered in Marketo, because the timeout+disconnect doesn't mean the request stage didn't complete.  But it certainly isn't fun to troubleshoot!  A few clients are using my experimental code for Chrome and Firefox and report huge improvements in analytics coverage. Perhaps when views are all registered without GTM, then I could imagine re-adding GTM for manageability.

[Dan_Stevens_]

Thanks for this, Sanford.  What exactly is this showing though.  You have me really concerned.  And i'm wondering if this is affecting some major campaigns we have active at the moment - including a targeted online advertising campaign, that has a parent program in Marketo, which then calls a campaign in another program (once the form is filled out) to capture the lead in the appropriate program that tracks online advertising.  We are very surprised that there aren't any results to-date - even though we're getting click-through reports form the agency that shows otherwise.  Could this be affecting this as well - form fill-outs?  I think it might be time to have another discussion with Support - who will probably just say "Marketo doesn't fully support GTM and there's nothing that can be done".

[Kenny_Elkington]

Your GTM is functioning correctly, otherwise the page would never get to the point of calling visitWebPage.  What's happening in Sanford's image is a reset packet being sent back by the munchkin server once the call is registered.  This is a(sometimes confusing) behavior to improve throughput on the server-side and shouldn't have any effect on whether the activity is tracked.

[SanfordWhiteman]

Kenny, the same result is seen when the XHR timeout is exceeded and it's been demonstrated by my clients that the calls are not registered in many red/canceled cases. It's easily seen with a sniffer or proxy that the client disconnects and stops waiting for a response after 350ms (by default); it's not the mktoresp server disconnecting (a proxy will still receive the full 1x1 GIF and a normal FIN).

That's the problem with trying to use something like the Chrome DevTools as a single stop for all troubleshooting.  It will show the same "bad" result regardless of what really happened on the wire, particularly for things like analytics where the response is totally disposable.

[SanfordWhiteman]

I should also add that by using a couple of different workarounds I developed, these clients were able to reduce their lost hit tracking significantly (through not to nil). 

[Kenny_Elkington]

If you've opened a ticket for this, can you PM me the case number?

[Dan_Stevens_]

This has turned into a very valuable discussion for those that use GTM.  I would love to see the conversation continue until everyone is on the same page and/or there is indeed an issue being uncovered here (by Sanford) - one that hopefully will be addressed by Marketo.

[SanfordWhiteman]

Example:

Using a synthetic delay of 350ms enforced by a proxy (Fiddler), you can easily trigger the red/canceled log line:

However, the call actually completes cleanly:

This is why I note that good and bad outcomes -- (a) exceeding the XHR timeout, but completing the request stage to mktoresp so the hit goes through; (b) exceeding the XHR timeout, but not finishing the request stage, so you lose the hit; (c) encountering some other kind of unexpected error -- will all look bad in DevTools.  Again, I think it's truly failing only in a small number of cases, but a DevTools error doesn't tell the whole story, which makes troubleshooting very annoying.

[SanfordWhiteman]

To be clear, I don't believe GTM is creating this problem, which exists on sites that use the native embedding as well.  But Munchkin is a troublesome beast (I'm giving a MUG talk next week in which I'll dig into the potential problems) and I'm not comfortable ceding control of a not-fully-trusted component to a component manager like GTM.  

The fact that GTM adds another async layer -- on top of the possibly async Munchkin bootstrapper, the async Munchkin library, and the async Munchkin visitWebPage call -- increases the possibility that someone will navigate away from the page before the hit is registered (although, as noted, "before the XHR is succesfully completed" isn't the same as "before the hit is registered," which makes troubleshooting painful as you need to check the Mkto Activity Log to know the final outcome).

In the screenshot above, the problem is is that the visitWebPage XHR is timing out before the response is complete. The response content is immaterial to whether the visit is registered in Marketo, but the timeout applies to the entire request-response cycle so you can never know (without deeper inspection using a proxy or network sniffer) at which point it timed out.

For example, if the GET request gets all the way to Mkto in 349ms, then Mkto will process the hit, even if the connection is then forcibly dropped during the response stage because the whole roundtrip takes > 350ms.  But if the GET wasn't yet complete at 350ms, then Mkto won't log the hit.  In both cases, the browser will show the request in red and "(canceled)."  But the server-side outcome could go either way.  Note the 350ms timeout can be changed -- it's one of the Munchkin init options -- but that has other complications. Also note that different browsers have different ways of starting the timer, which is yet another point of confusion.