These days, anything is up for debate, it seems: there are even mkt_tok denialists!
An IT team claimed the all-important mkt_tok query param✱ wasn’t being attached to Marketo links, even though they redirected from Marketo’s click tracking server (a.k.a. branding domain) to the right page. We knew this was vanishingly unlikely, but how to prove it?
Granted, mkt_tok can be confusing on a Marketo LP because there’s system-managed JavaScript that strips the param when the page loads, moving it to a JS variable for security reasons. The mkt_tok is still in the location bar for an instant, but you might miss it.
However, in the current case the target was their corporate website, where that mkt_tok-stripping code wouldn’t be present.✱✱
So we gotta bring back an old-school technique. Copy the link from the received email, prepend view-source:, and open it. You can see the mkt_tok is there as expected:
Turned out in this case their webserver was redirecting people again from https://www.example.com/preferencecenter to https://example.com/en/preferences but was stripping all query params except those beginning with utm_! Solved.
Notes
✱ In case you forgot, without the mkt_tok Munchkin can’t associate anonymous web sessions, so Visited Web Page and Clicked Link won’t be logged. Clicked Email doesn’t use Munchkin, so isn’t directly affected.
✱✱ Note if someone has Firefox’s Query Parameter Stripping enabled, that’ll strip mkt_tok at the browser level. However, this is a Chrome-centric shop and that’s a non-default FF setting anyway.