Be aware of decodeURIComponent() limitations (with any 1ˢᵗ or 3ʳᵈ party JS, not just Marketo forms)

You’re one unencoded/mis-encoded query param away from a broken form.

MktoForms2.whenReady() is always non-blocking (plus: what is and isn’t a race condition)

I’m indeed obsessed with Marketo form events. But if you ignore details and don’t test against worst cases, that’s how “randomly” broken forms happen.

Tip: Add a initial row number to Bulk Lead Import CSVs for useful failure reports

Pre-flighting CSVs before putting sending them to the Bulk Import API averts this bug. But most of you, I have a feeling, aren’t pre-flighting.

No, you don’t need a Wait step after Sync Person to SFDC: sync-related updates are immediate (i.e. synchronous)

Don’t let paranoia get the better of you: the Marketo-SFDC connector is very smart about order of operations.

Marketo click tracking only works because 2 JavaScript bugs cancel each other out

Code that works by luck rather than by design? Yikes. A brief code review would’ve caught this one.

Deleting the non-deletable: clear an overridden {{my.token}} using the Marketo API

You don’t need to accept “Token is already in use” as a permanent condition.

Why you 𝒅𝒐𝒏’𝒕 need to check if GTM’s window.dataLayer was blocked by an ad blocker

An exceptional case where you’d think code isn’t resilient, but it mysteriously is!

Check out my colleague Jo Pitts’s blog, too

Jo & I are kindred spirits (and collaborators) and the revived MoTaM blog is highly recommended.