Skip navigation
All Places > New York User Group > Blog > Author: Sanford Whiteman

Marketo's Known Visitor HTML feature (KV HTML in my shorthand) is a great way to streamline a lead's experience if they've already filled out a form.

KV HTML has quirks and guidelines that deserve another post, but in brief:

  • Use it to hide the usual form entirely if you already know who someone is, essentially letting somebody “jump the gate” to your content.
  • A Filled Out Form activity is still logged — a good thing for reporting!
  • KV HTML is not the same as Progressive Profiling (similar, but in fact mutually exclusive w/ProgPro).

Another cool thing KV HTML supports is a session regeneration link. This is the special {{form.notYou}} token.

When clicked, this link cleanly breaks the connection to a previously associated lead and resets the form, while leaving previously logged activities as-is.



Read the full post on TEKNKL :: Blog →

You probably don't realize that Munchkin ignores clicks, by default and by design, on 6 different types of links:

  1. (1) links whose destination appears to be a hash (fragment) on the current page:
  2. (2) mailto: links
  3. (3) javascript: links
  4. (4) AREA links
  5. (5) links with the special class mchNoDecorate (more on this another time)
  6. (6) links that aren't, well, links (like clickable DIVs, an IMG not wrapped in an A, etc)

With all those exceptions, chances are good that you have at least one prominently featured link that is not tracked.

In an unscientific survey of 10 sites running Munchkin (grabbed out of my browser history), 7 had an untracked link on their home page (and of course this is about more than home pages!).


Read the full post on TEKNKL :: Blog →

I've written before about conditionally loading Munchkin based on IP ranges (which isn't a native feature), and about adding custom Munchkin options on Marketo LPs (where Munchkin is injected automatically with special options).

As Community user GF points out, anti-cookie/anti-tracking legislation like GDPR requires a combo of these earlier approaches:

  1. (1) the end user must consent before Munchkin runs on Marketo LPs
  2. (2) you need to preserve the LP-specific special options if they do consent
  3. (3) you may need to add custom options, most often domainLevel

To get this working, we need to hack around Munchkin's hard-coded load-and-run logic on Marketo LPs. Luckily, it's not horrendously complex, though it'll look obscure to people inexperienced with such shenanigans.


Read the full post on TEKNKL :: Blog →

File under Things You Thought Already Worked.

For awhile, I too thought multiple Marketo forms on the same page worked as long as they had different form IDs (though I always knew there was a problem with 2 or more of the same form).

But no, even different forms don't really work. The only multi-form scenario that works out-of-the-box is different forms that have zero visible fields in common. Since Email Address is found on almost all forms, it's almost certain that multiple forms won't be fully functional without the fix below.

The problems with multiple forms all relate to the HTML ID attribute.



Read the full post on TEKNKL :: Blog →

    With an assist from Velocity, your emails can have time-responsive content.  (And I don't just mean Happy ${day_of_week}, ${first_name}!)

  • When the same email is resent with different primary content (e.g. a weekly newsletter) Velocity can customize secondary content based on the day: like reader PW, you can show a special promo only in the first send of the month, every month.
  • Like user GM, you can pre-create a series of different content blocks, in effect creating a drip campaign from just one asset.
  • If a triggered email is sent off-hours, you can notify the recipient that they'll hear from Sales on the next business day.
  • Or lots of other adventures!

    To run the snippets below, set common variables at the top of the script (or in a global script) like so:

#set( $defaultTimeZone = $date.getTimeZone().getTimeZone("America/New_York") )
#set( $defaultLocale = $date.getLocale() )
#set( $calNow = $date.getCalendar() )
#set( $ret = $calNow.setTimeZone($defaultTimeZone) )
#set( $calConst = $$calNow) )
#set( $ISO8601 = "yyyy-MM-dd'T'HH:mm:ss" )



Read the full post on TEKNKL :: Blog →

     Since version 1.6 (i.e. a long time ago) Java has had a built-in JavaScript engine. Called Rhino in Java 1.6-1.7 and replaced by Nashorn in 1.8, the JS engine has always been reliable (it’s the user-facing script language of numerous Java-based commercial apps) even if its function set and performance lags behind browsers’ JS engines.

This means if you have a ready-made JS snippet that does what you want, and you don't want to learn Velocity and/or translate your JS into native Java methods (hint: you eventually should learn how to tie Velocity in with raw Java, you'll be more productive for it) then you can sneak JS inside your Velocity token and get your cool email personalizations out the door.

You'll be running JavaScript, inside Velocity, inside Java, all inside Marketo: it's pretty darn cool, even if not something to lean on permanently.

Here's an example Velocity script which has JS do the heavy lifting…



Read the full post on TEKNKL :: Blog →

User BJ asked in this Nation threadabout changing mktoVideo dimensions from the default 420 x 315.

Even though I don't typically use mktoVideo, preferring 3rd-party players, I started probing the CrowdFactory API (CF being the real name of the “Marketo Social” widget that powers video elements).

After reverse-engineering for a bit, I had working code, but obviously someone must have tried to do this before, right? Um, yeah: me. Searching the Nation, I was disturbed to find I'd posted almost exactly the same codea year ago!

At least it wasn't exactly the same code. I did do a better job today (and edited the earlier post accordingly), so my li'l memory glitch had an upside. Anyway, now it's here for posterity.

All you need to do is add a couple of variables (you could also hard-code, but this is more flexible).




Read the full post on TEKNKL :: Blog →

It's well-known that Marketo's pURL feature, out-of-the-box, has a fatal (and kinda fascinating) shortcoming. If someone has visited your site before — meaning either an anonymous or associated Munchkin session— then pURL-enabled pages aren't functional.

When there's an existing anonymous session, the server ignores the personalized part of the URL (the Marketo Unique Name /JillSmith02 or Unique Code /XYZPDQ) and serves up default/empty content.

On the other hand, if the person has never been to your site on their current device, pURLs work fine.

Unfortunately, then, pURLs work only for people who either [a] just got a new PC or phone or [b] have been living under a relative rock. Not exactly the widest audience!

Luckily, it's always been possible to fix the strange session behavior with a little JavaScript.



Read the full post on TEKNKL :: Blog →

     As some have rightly complained, once you set a Mask Input pattern on a Forms 2.0 field, the Form Editor doesn't let you switch the pattern based on other fields' values — for example, country-specific phone numbers.

(File this under “Things I've never needed, but know how to do.” Not a fan of input masks on web forms in general!)

Here's how. First, in Form Editor, give the field a default Mask:


Then the rest is done with a little Forms 2.0 JS



Read the full post on TEKNKL :: Blog →

Because why not? When user AA wondered why his IFRAMEd pages (inside other pages in the same domain) seemed to be ignoring RTP reactions, I resolved to get to the bottom of it.

On the technical level, as it turns out, there's no mystery: the RTP JS library disables itself when it determines it's running in an <iframe>.

On the business level, this doesn't make any sense:

(a) it assumes an adversarial relationship between the outer domain and the IFRAMEd domain, which obviously isn't the case when you operate both domains


(b) even if the inner and outer domains don't trust each other, there's tech that already exists to solve that: the outer can use the <iframe sandbox> attribute to neuter the inner, and the inner can have an optional (as opposed to mandatory) restriction on running in a frame

Luckily, you can fix it by inserting one line of JS after the last line of the RTP embed code



Read the full post on TEKNKL :: Blog →

Hey there! Here's a workaround for another forms bug.

Wish it were really new, but it seems to have been introduced in the forms2.js dated 2017-06-23. Just tuned in to it today thanks to a DM on the Community.

The bug: unchecked required checkboxes no longer show an error message. The checkbox is focused and it does stop the form from submitting, but because of the lack of error message, users won't know why.

Compare this buggy behavior when Submit is pressed:


And this expected behavior:


It's annoying that we have to fix it, but at least it's easy


Read the full post on TEKNKL :: Blog →

     It's easier to customize a Marketo form if it's completely destyled to start. A float or margin-left that doesn't seem to respond to !important can drive a designer crazy, and time spent on CSS specificity & cascade behavior isn't well spent.

My li'l snippet for removing Marketo's built-in styles has seen a lot of use via the Community and a few code versions (now at the venerable v1.103) but it hasn't appeared on the blog before.

Here's a sample form with the Simple theme:

And here's that same form after running destyleMktoForm to reset it to browser defaults (check out the Times New Roman):


Let's dive into the destyleMktoForm function a bit, since I always insist on a teachable moment

Read the full post on TEKNKL :: Blog →

     Continuing this series thanks to a prod from user KS on the Field Limits doc:


Does URL field type have a character limit?


     Indeed it does: 255 characters.  And unlike with Integer fields this restriction is in sync with the SFDC field type of the same name, which also is limited to 255.


     This wouldn't be a problem, save for the fact that Marketo can't truncate longer URLs (including pathnames and query strings) to a guaranteed working URL.


     See, an implicitly-fully-qualified domain name like or not including any leading or trailing URL components like https:// or the /path/name?query=string must indeed be under 255 characters. (In fact it must be under 253.)


     So if you're only storing pre-parsed domain names, there's no problem with the max field length.


     But if your source could be a full Referrer URL, or a long URL from your product catalog, it's certainly possible to go over 255 characters.



Read the full post on TEKNKL :: Blog →

     If there's one official Marketo doc that needs some edits, it's the Marketo Field Limits by Field Type rundown.


     Unfortunately, that article has incorrect info and some sins-of-omission.


     Be warned: most of this post is (necessarily) dry and technical. But I always find competing claims to be interesting, almost regardless of the topic. Maybe you will too! Plus, even experienced high-level programmers (meaning languages other than C and C++) don't have this stuff at their fingertips, and may make implementation mistakes as a result. So if you're in a meeting and want to show some mild “data scientist” chops, these are good facts to drop.


     I'll be adding to this series over time. To start off...



From the doc:



Values are limited to between -9223372036854775808 and 9223372036854775807.


     This is technically correct.


     Marketo stores Integer fields as signed 64-bit integers — signed meaning they can be negative or positive — so they fall into the range of -(2^63) to +(2^63-1). It can be useful to look at the high number in an easier-to-read way:


9 223 372 036 854 775 807


     So 9 quintillion, 223 quadrillion, 372 trillion something.


     If such a number seems unimaginably high in a martech scenario, I fully agree (though don't forget the ol' Grain of Rice parable).


     But the truth is you can only safely go up to the max value if you don't integrate any other apps with Marketo. No Salesforce, no JavaScript, no 32-bit PHP apps or older databases. When you integrate, the actual limit can be a tiny fraction of that.



Read the full post on TEKNKL :: Blog →

     When you use the default Forms 2.0 embed code, the form descriptor loads asynchronously. This means the inner HTML of the <form> tag isn't rendered until after the initial scaffolding of the page is finished drawing (often immediately after, but always after).


     (The descriptor is the meat of the form config, managed in Form Editor: the fields, field order, validation rules, inter-field dependencies, custom CSS styles, all that stuff.)


     Let me take care to say that this is a totally sensible default. Marketo can't know how many other asynchronous components are present on your page. You could have multiple content panes filled via Ajax, as and a bunch of other 3rd-party asynchronous widgets. In the absence of other info, and not knowing if the site is a complex corporate website or a simple (non-Marketo) LP, it makes sense to not have the form block other parts of the page from loading.


     Nevertheless, in practice you may notice an uncomfortable reflow of other elements as the <form> builds out its content, bulging into a larger area of the page. Floats can shift to a new row and such.



Read the full post on TEKNKL :: Blog →