Say “associated Munchkin token” instead of “cookie” to be hyper-accurate
Shorthands like “anonymous Munchkin cookie” and “associated Munchkin cookie” aren’t harmful in a broad sense, and I use them often. But from a technical standpoint, they’re juuust misleading enough to be worth correcting.
When you’re debugging or extending Munchkin, thinking in terms of full cookie values can make things seem miraculous that really aren’t.
You see, what really gets associated is the token part of the cookie, not the whole cookie. The rest of the cookie value is used to determine the Marketo instance that receives new Munchkin events, but that part can actually change while the association remains.
That was likely confusing, so let's step in more slowly.
Breaking down the cookie
Check out this breakdown of a sample _mkto_trk cookie value:
As you can see, the value is formatted somewhat like a query string, with the & separating key-value pairs, although the colon : is used instead of equals =. (Presumably because = looks surprising in cookie values, although it is allowed.)
There are therefore 2 params within the cookie: id and token.
The id just contains the Munchkin ID of the target instance (136-ZZZ-639).
The token contains everything else: the domain corresponding to the Munchkin domainLevel option, the millisecond timestamp of when the cookie was first set, and a random integer to increase uniqueness.
The browser always sends the entire cookie value to the server (by definition, cookies are always sent as full values). But under certain circumstances the id is ignored but the token is still usable.
Tracking cookies are continually rewritten
You may not realize it, but the Munchkin cookie isn’t set once. It’s set every time the Munchkin library initializes — that is, on every pageview where Munchkin is running. Why? To continually extend the expiration time: every time it’s set, the expiration time is set to 2 years (by default) from the current timestamp.
See, it’s not possible to change the expiration of a cookie without resetting the entire thing: mycookie=abc that expires in 1 day is different from mycookie=abc that expires in 2 days. Even if the name mycookie and value abc are the same, if expires — or another property, like secure — needs to change, the old cookie is completely erased first.
Of course, this the way all analytics cookies must work, in order to not just disappear from the browser at an arbitrary time! It’s not a Munchkin thing.
A Munchkin ID switch changes the cookie value, but not the token part
What Munchkin does that’s mildly special is keeping only one cookie at a time per domainLevel.
For example, you might have a staging Marketo instance running on pages-staging.example.co.uk while production Marketo uses pages.example.co.uk.
Both of these would use domainLevel : 3, which means example.co.uk in both cases.
When you switch between the sites, Munchkin creates a new cookie. (After all, it’s a fresh pageview and the expires needs to be reset in any case, as you learned above.)
In addition to expires, it also changes the internal id part of the value, but doesn’t change the token part. For example, it’ll switch between
id:136-ZZZ-639&token:_mch-example.co.uk-1687464012906-74933and
id:247-AAA-528&token:_mch-example.co.uk-1687464012906-74933The critical part is that JavaScript is responsible for that switch. So the id isn’t switched until after the next page has been loaded by the browser, as that's when the JS library (munchkin.js) runs. And yet {{lead.token}} output – ergo lead association – is still functional on that page!
Site B can use what seems to be “site A’s cookie” to get the current association, and vice versa. (In fact, you can change the id to anything you want and an existing association will be picked up.)
So it’s the token that's associated within the target instance. The more you know and all that.😊
P.S. None of this means being associated in one instance transfers to the other. That wouldn’t even make sense theoretically, since the databases have totally different Lead IDs.