Thanks Dan for that last note. The back and forth on Non-trackable landing page is still identifying me was quite a read; I'll have a to give a try to see if I correctly understood all the fine points.
Here, let me simplify this for you:
Place this code in the <HEAD> of the LP template, just below the META tags:
<!-- CREATE EMPTY MUNCHKIN COOKIE - TO ESSENTIALLY MAKE THE PAGE UNTRACKABLE -->
<script>document.cookie = "_mkto_trk=;path=/;domain="+".YOURDOMAIN.com"+";expires=0"</script>
<!-- END -->
Be sure to modify ".YOURDOMAIN.com" for your domain. This is the only customization that necessary here.
And then place this script directly on the LP in design view (we still use the older LP framework - not guided - for some of our internal/operational LPs due to the ease of placing code like this directly on the page):
<!-- Clear the Marketo tracking cookie value on submission of the form, without having to delete the cookie itself from the user’s browser. -->
<script>// <![CDATA[
//add a callback to the first ready form on the page
MktoForms2.whenReady( function(form){
//add the tracking field to be submitted
form.addHiddenFields({"_mkt_trk":""});
//clear the value during the onSubmit event to prevent tracking association
form.onSubmit( function(form){
form.vals({"_mkt_trk":""});
})
})
// ]]></script>
<!-- END -->
We've created the code above as a snippet and just drag the snippet onto any page that we want to prevent Munchkin tracking (while use the no-tracking LP template):
Note Robert Kelen the first part of the code above should only be used if you want the *entire session* untracked -- that is to say, that none of the program owner's web activities need to be tracked in Marketo.
For internal users, this is usually the case. But a counterexample would be when you use Marketo to monitor use of some internal pages, like HR or scheduling apps, etc. In such cases, you don't want to delete the cookie because then you'll get anonymous activities again (until they are next associated by clicking an email or via an associateLead call).
A MktoForms2.whenReady listener is sufficient to no-track the form submit without no-tracking the whole sesh.
Good points, Sandy. So in other words, just including the script directly within the LP (and not using a dedicated "no track" LP template - with the script to create the empty Munchkin cookie) will suffice here - correct?
I don't think there's anything with using a dedicated template w/Munchkin off, but as documentation more than as a technical measure.
The <script> to clear the current cookie value, though, has those possibly unwanted side effects.
How do these extra steps (the MktoForms2.whenReady listener, and the empty cookie) differ from the built-in "Disable Munchkin Tracking" template action? Thanks.
They serve distinctly different -- sometimes complementary, sometimes conflicting -- purposes.
This is the option that is frequently misinterpreted as "no-track" when actually it means "no-new-track," if you will. And because not everyone will have an existing cookie, it can appear to work, like if you're testing in Incognito/InPrivate windows (which is a good idea in general). But in reality it doesn't suffice to create a Referral Form, and can actually make things worse, because it makes it harder to track the use of the referral form itself by salespeople/partners etc.
Note that the code above doesn't actually delete the cookie, it empties it but the cookie still exists for the duration of the page view and maybe much longer. The cookie is set to delete only when the browser closes (expires=0). While the cookie is empty, whether it's considered de facto nonexistent depends on the JavaScript code that's used. Some code will say an empty cookie is as good as nonexistent, others won't.
This difference in behavior means you really shouldn't use that code but rather this:
document.cookie="empty=;path=/;domain=.example.com;expires=" + new Date(0).toGMTString();
The code above truly removes the cookie (immediately). If indeed that's what you want to do.
The go-to code for this (Dan posted it above) is kinda quirky, relying on undocumented Forms 2.0 behavior, but totally works.
Thanks Sanford!
Edited to add some color just now.