Enabling Munchkin on Marketo Landing Pages

[Anonymous]

I have three links on a thank you page and I want to be able to track the link clicked in Sales Insight. I'm using the Clicks Link on Web Page trigger to build out my trigger campaign but I am not able to choose any of the three links within the drop down. If I try to add them in manually I get the red line that tells me there is an error.

Is there something I'm supposed to do on the back end to fix this problem? Is there something I need to do with the munchkin code or to my template?

Thanks,

Andrew

[Kenny_Elkington]

Can you share a link to your page, Andrew?  It's hard to say what might be happening without a live example.

[Anonymous]

Hi Kenny - Here is the landing page. When you fill the form out it brings you to the thank you page that contains all 3 links - ICD-10 Education for Physicians and Nurses

When someone clicks on a link, I want to log that info into sales insight and maybe even notify the rep.

[SanfordWhiteman]

Your LP is loading Munchkin, but your TYP is not.  I presume this is because you're using GTM (which I do not advise) and did not enable Munchkin for the second URL.

[Kenny_Elkington]

Yes, the GTM isn't configured correctly to load munchkin.  Also, your first page seems to be a Marketo LP which is iframing in another Marketo LP which has a form on it.  This embedded LP is the one which is actually loading Munchkin, the parent page isn't since the GTM is failing to load Munchkin.  I would take Sanford's advice and have all of your pages load Munchkin the standard way.

[Dan_Stevens_]

We've been serving up the Munchkin code using GTM for a couple years now with no issues.

[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".

[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.

[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]

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]

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.

[Anonymous]

Thanks, guys. We had an outside developer create our landing pages, thank you pages, and forms this way to make our pages responsive pre-Marketo responsive landing pages. It's been working great for us but I didn't realize this was happening until today.

I'll take your advice and pass the message along. Thanks for your help.

[Josh_Hill13]

It should be fine because it won't appear there until someone clicks the link and is tracked the first time. So maybe you can do that with a cookied test lead. You may also need to remove "http"

[Anonymous]

I tried doing it with a cookied test lead and still don't see anything on my end. Not sure if there's a lag time or not.

[Dan_Stevens_]

For us, it sometimes takes up to an hour for the link value to be captured/indexed by Marketo - and made available within the drop-down list of the trigger.