I keep some Marketo factoids close to the vest (hey, gotta get paid for something!) but if you read the fine print of my Community responses, you'll see allusions to longstanding bugs that I've never detailed.
Case in point is this thread where I casually mentioned that on pages with multiple downloadable assets (like PDFs), you must add target="_blank" to every download link in order for all Clicked Link events to appear. Guess it's time I explained why.
First, Munchkin assumes that all links to new documents are exit links. I'm defining “new document” as a link that changes anything other than the document's #hash, and “exit link” as a link that leads to either (a) a URL on an external domain that does not load your Munchkin code; (b) a page on your domain that has Munchkin deliberately turned off; or (c) a binary asset on your domain, like a PDF or XLS, that cannot run Munchkin.
This assumption has other ramifications that are due for their own blog post, but to stick with the matter at hand, as long as Munchkin can log that a lead downloaded http://pages.example.com/rs/aaa-bbb-ccc/whitepaper1.pdf, it won't care one way or the other about the lead downloading http://pages.example.com/rs/aaa-bbb-ccc/whitepaper2.pdf from the same page. So consider a Whitepaper Center page like this:
Unless you take specific steps, Munchkin will only log only the first click on a Download Now button, whichever one that is, even if clicking that button keeps the displayed page as-is.
See, when a link to a Marketo-hosted asset doesn't have target="_blank", the browser might either: save the file to the lead's hard drive; save it automatically and open it in a 3rd-party viewer; or open the PDF in the same browser tab. (Which one of these options is used depends on the lead's browser type, browser config, and/or PDF viewer config, and cannot be controlled by you, the page author. On my machine, Firefox opens PDFs in the external Adobe Reader app, but from Chrome they open in the same tab using Chrome's reader, and only I can change those settings!)
If the browser does open the PDF in the same browser tab, then no harm done: the displayed page is totally unloaded and replaced by the PDF content, so they wouldn't be able to click any more links on that page anyway.
But if the browser saves the PDF to disk, or opens the PDF in another app, the page is still open in the browser with the other buttons ready for a-clickin'. Additional assets will still download. But Munchkin won't log those other clicks because it erroneously considers the page to have unloaded. It will even fail to log any non-asset clicks on the same page (like a link back to your homepage or in a nav menu).
To be clear, it's not that Munchkin purposely ignores the second, third, and later links on a multi-asset page. Nor does Munchkin always refuse to log multiple exit clicks. But the concept in my intro — that any external link is an exit link — represents an overarching design sentiment that reveals Munchkin's at times... er... indelicate treatment of links in general.
The technical reason that links stop being logged is actually a browser quirk that in turn bubbles over to Munchkin to cause the error. When a browser detects that you clicked an <A>, it checks the attributes of the link to determine whether the page is about to unload or not:
- In browsers that support the
downloadattribute (not all modern browsers do, so I'm not recommending it as a fix) that attribute tells the browser the current page will stay as-is. - With a local
targetname (note the generictarget="_top"is local), the browser assumes that following the link will replace the entire current page, so it fires the unload event. - With no
targetattribute at all, the browser also assumes that following the link will replace the entire current page and fires unload. - If the
targetis a custom window name like<A target="PDF_download_window">that doesn't exist in the current tab, or is the generictarget="_blank", the browser knows that it will be opening the target of the link in a different tab, so it does not fire unload.
So, if you've made it this far, you now realize that Munchkin unloads when the browser thinks the page is unloading — even if the browser's intuition is wrong and the page isn't going anywhere.
The reason Munchkin bothers to unload (“unload” means “remove its click listeners,” since you can't actually unload code that's already run) is to prevent memory leaks, though this really is not necessary in modern browsers. But what's important is that it not unload by mistake. So that's why you want to add target="blank" to your asset links, because then the browser will never accidentally disable Munchkin on a page that is still available for additional navigation.
And yes, this means your PDFs always create a new window, even when a lead's OS/browser/viewer config prompts the user to save the file to disk (meaning the blank window sticks around until they X it out). A more elegant solution is to switch to a JS-powered design, so you can open the new download window and close it down afterward. But that can be a dramatic overhaul for your current pages, so at least in the short term, add target="_blank" to avoid mysterious gaps in click tracking.