Skip navigation
All Places > Products > Blog > Author: sanford.whiteman


10 Posts authored by: sanford.whiteman

     The Munchkin API function associateLead is magical and underused. It's key to synchronizing certain 3rd-party data with your Marketo database, and bizarrely enough was the first Marketo feature I ever used (well before understanding anything about campaigns and flows!).


     I have a post set to publish re: tracking engagement with non-Marketo emails, and since that post concentrates on the browser side (how to use specialized tokens in link URLs to associate leads, even when emails are sent via other ESPs) I decided to dedicate a post to how you generate those tokens.


     The info below is a must-read preface to the main post, but it'll also be useful on its own to some readers.




First, I'll tell you what it's not: it's not the Munchkin cookie, it's not the mkt_tok value that's appended to tracked URLs, and it's not a REST API access_token.



Read the full post on TEKNKL :: Blog →

Today, let's explore a questionable call made by… well, probably by every single Marketo user, ever: sending direct links to PDFs or other downloadable collateral.


I think most people understand that downloadables, on their own, can't associate web sessions with known leads: PDFs don't run Munchkin, nor do Excel spreadsheets. So if someone clicks from an email straight to your blahblah.pdf, their web session will still be anonymous unless it's been associated via other means.


Read the full post on TEKNKL :: Blog →

Just discovered another bug in Marketo forms when there's more than one form on the same page.


Symptoms: seemingly random behavior in loading the datepicker (or any other polyfill) in browsers that lack native support.


For example, Firefox does not support the native HTML <input type="date">, so the Forms 2.0 library loads a custom, JavaScript-based picker plugin (script-driven emulations of native features are called polyfills).


Read the full post on TEKNKL :: Blog →

Another one to file under More tricky than it seems. As Marketo users MS and JI note in these posts, when a lead doesn't click any of the available options for a form field, the form sends an empty string value to the server, and such a response is considered a no-op — that is, the existing value on the lead will be preserved.


(By the way, when it comes to checkboxes and radio buttons, standard HTML forms do not post anything at all not even the field name, let alone an empty string value in such cases. So we're starting off on a proprietary foot here. As I've mentioned in other posts, though Forms 2.0 uses standard HTML inputs, there's much more going on under the hood.)


So take a form like this:



If submitted as-is, neither Product Interest nor Other Interest will be updated in Marketo.


Read the full post on TEKNKL :: Blog →

Marketo user SS asked a good question about datatypes in webhook responses. Referring to the documentation provided by a 3rd-party lead enrichment service, she notes:


Because all of the custom fields created for the webhook must be string-type fields, I cannot use logic for their 'number of employees' data such as "if value is between x and y"…


Luckily for SS, the vendor docs are off-base. In fact, if a Marketo webhook returns a numeric string (that is, a JSON-encoded string value that starts with one or more numbers) you can safely map that property to a numeric field.

Read the full post on TEKNKL :: Blog →

You often see Marketo forms with an "extension" field where a lead can type an explanation for their Other/None of the Above choice.




This works well enough from the lead's perspective. You can use Visibility Rules to show the extension field only if Other is selected in the primary field. 


But there's really no reason to do it this way. I consider this an antipattern with Marketo forms for two reasons.

Read the full post on TEKNKL :: Blog →

A question from top Marketo user GM in this post led to an interesting, even disturbing, hour of troubleshooting.  Finally, I've gotten around to writing it up.


When Munchkin sees a 2-letter TLD like .io or .ly, it makes a bad guess about the proper domainLevel — the domain at which it sets the vital web activity tracking cookie.  Using TLDs like .au as a model, the code incorrectly assumes that you cannot have registered a domain directly under the TLD and automatically sets {domainLevel: 3}.

Read the full post on TEKNKL :: Blog →

A Community question from Marketo user Randall Tam about generating personalized PDF certificates (for Continuing Education classes and such) sent me back to some old bookmarks to see which service would be quickest to integrate with Marketo LPs.

The idea here is to use LPs as your PDF templates. LPs are inherently personalizable via tokens and segmentations, so they're a great base for generating per-lead PDFs. (Your designer will be using HTML and CSS, so the output may not be as awesome as what you'd get from InDesign, but it'll work great for most scenarios provided you have a skilled designer.)

Read the full post on TEKNKL :: Blog →

More fun with Munchkin domainLevel tonight. A client hired an outside design firm to work on some LPs, and the designers couldn't figure out why forms (embedded Forms 2.0) weren't posting a Munchkin cookie, even though an anonymous Visit Web Page activity was being logged (though for a new lead on every page load).

The firm was hosting the pages on for QA. I'd recommended a subdomain of the client's domain instead — otherwise, associated leads would be lost upon navigating to the Thank You URLs on the client's main site, strongly limiting real-world tests. And indeed hosting on would've sidestepped the problem. But it would've deprived us of a nice teachable moment, so it's just as well.

Read the full post on TEKNKL :: Blog →

Adding Munchkin to a Wix website

Either I was a bit overconfident in this Marketo Community Post from over a year ago about Munchkin & Wix, or Wix has changed something since. (Can't track changes on their side, not being a real Wix user myself.) Either way, as of Spring '16, Wix makes you jump through a few hoops. But Munchkin tracking can be done! I don't think this recipe is available anywhere else on the web, so let's dig in.

The problem: Custom HTML is wrapped in IFRAMEs

Unlike other "prosumer" site builders such as SquareSpace, Wix seems deathly afraid of letting you add custom HTML (including JS) directly to your managed pages. Instead, any HTML you add using the Add More » HTML Code is always wrapped in an IFRAME before insertion.

Read the full post on TEKNKL :: Blog →

Filter Blog

By date: By tag: