Some small signals from end users — stressing some — can be disproportionately meaningful.[1] One such signal: that they started to fill out a form, so you can compare/intersect with people who eventually submitted the form.
The delta between the 2 is, of course, people who were distracted/discouraged/disengaged (or, in the interest of completeness, people who couldn’t submit the form due to forces outside their control).
Of course, we need to define our terms.
Does “started” mean “focused – either by clicking, tapping, or tabbing – a visible form field”?
Or does “started” mean “changed a value” in a visible form field? This definition might seem more exact at first, but the problems are (a) there’s no need for someone to change a value in order to submit a form – remember Pre-Fill – and (b) there’s no single DOM event that can account for all types of net changes, making the accompanying JavaScript very complex.
There are other directions you can take with “started,” and all manner of JS hooks you can build (veering quickly into way-too-much-to-be-useful). In a later post, I may feature some of those takes. But today I’m going to stick with the simple definition: Did someone move focus to the form?
Here’s how that’s done:
MktoForms2.whenReady(function(form){
var formEl = form.getFormElem()[0],
formId = form.getId();
formEl.addEventListener("focus", logFormStart, true);
function logFormStart(e){
formEl.removeEventListener("focus", logFormStart, true);
Munchkin.munchkinFunction("visitWebPage",{
"url" : document.location.pathname + "#!/inPage/startedForm/" + formId
});
}
});Then you’ll see a hit — one supplementary hit per pageview, naturally — in the Activity Log:
/startedForm also logs if they submit the form without touching any fields, because clicking Submit also fires a focus event. (This is A Good Thing.)
Note the hit will stay in the Anonymous Activity Log if the person never converts, but moves to the standard (Known Lead) Log after their session is associated. As with all Visit Web Page activities, there’s ongoing backfill.
I’ll leave it to you to come up with meaningful Smart Lists using this info. 
Why log Visit Web Page instead of Click Link?
Because Munchkin clickLink blocks the browser UI thread. And if you don’t know what that is: trust me, it’s A Bad Thing.
I’d go far as to say all custom Munchkin code that uses clickLink for in-page events (non-unloading events) instead of visitWebPage is lowkey broken – admittedly including some of my own older code. Someday I’ll get to a blog post specifically about this, but for now: trust me.
NOTES
[1] I feel strongly that logging every minor-to-meaningless page interaction is wrong. That not only creates chaff on the server side, it’s also disrespectful to users with low-quality connections. I’m in a big city, but still stuck on slow DSL, people!
In addition, Munchkin’s append-only logic is particularly ill-suited for storing a continuous spray of superseding events. The proper back end for that is one that can consolidate superseding events into one. Example: video tracking. If someone watched 60s of a video, they also watched 30s, so only the superseding value should be stored. Of course, I still use Munchkin to log YouTube plays... but I know it’s wrong in the grand scheme.
.png)