When does _mkto_trk cookie change?

[Anonymous]

On the goshen.edu Wordpress site, I'm beginning to use the _mkto_trk cookie and the REST API to look up users by cookie and show custom calls to action, forms, etc.

The _mkto_trk cookie is often available in the initial page request, but I'm concerned about its accuracy. For instance, if Kate is cookied on her laptop, then Mark checks his email on the same laptop and clicks on a Marketo email, Mark will end up on a goshen.edu page with Kate's cookie but an appropriate mkt_tok url parameter (associated with Mark's email). In this case, I'm guessing Munchkin looks up the parameter, sees it doesn't match the cookie, and swaps out the Kate's cookie for one associated with Mark.

I would imagine Munchkin also swaps out expired cookies, and I'm not sure if they can still be used identify users (or should be). Part of the problem here is that I don't have a commented version of the Munchkin tracking code, which would be really handy.

Ultimately, my question is how to detect this sort of cookie swapping, or alternatively, can you provide the instances in which Munchkin might swap out a cookie, so I can wait to see if it happens before loading user-specific content? Thanks!

[SanfordWhiteman]

Shudder to think you're using the REST API in response to individual web actions, as this creates a DoS vulnerability.  Please consider the API for batch-based, server-to-server actions only. It's not for real-time personalization.

To your main question: you may be misunderstanding how the _mkto_trk cookie is initially assigned.  It's actually generated client-side and will be in the browser's cookie store even if you can't connect to a Marketo instance.  The cookie value itself will not change on its own, but its association with a specific lead in your Marketo instance can change. 

By default, if two leads share the same browser profile, activities on your website will be associated with the first lead to receive an association via a clicked link in an email.  This default behavior shouldn't really be surprising: if people care little enough about security that they check their email not only from the same machine but from the same browser profile, they should have no expectation that actions within that profile are isolated.  Even if they've logged out and back into GMail or whatever, that says nothing about other sites. OTOH, if the second lead clears cookies for all domains, then they might reasonably expect not to be mistaken for the first lead on other sites... but then they're disrupting the first lead's future web experience.

_mkto_trk cookies do not expire for 2 years, so I doubt that's a concern.  The actions associated with those cookies will age out of the Activity Log long before the browser stops sending the cookie.

[Anonymous]

Thanks Sanford, this is very helpful!

It's good to hear that cookies are re-associated instead of replaced. It also makes sense that all activity will be associated with the first lead to be associated with a particular cookie. I imagine the only way of making this more transparent to users would be to actually have secure profiles where they are either logged in or logged out and can see this in the UI. Otherwise, we are simply making our best guess from prior device usage.

Also, I appreciate the tip on the REST API usage. I'm not sure what alternatives I have besides RTP, which we don't have the budget for currently. I'll run this concern by our server admins and see what they say. Thanks again.

[SanfordWhiteman]

Yep, Munchkin lead association is no substitute for a real authentication layer. But it serves most purposes very well -- the rare "shared profile" case is one that would confound most web apps, let alone marketing websites. It's not unique to Marketo.

[SanfordWhiteman]

You won't have a direct alternative to the REST API from a third-party site unless you have a front-end developer who knows how to do cross-domain magic -- I do this fancy stuff so our sites can be more resilient -- but I feel it's reckless to have core functionality that breaks after 10,000 (malicious or legit) page views.  If the limit were, say, 1,000,000, it would be a different story, since you could probably predict the site would break for other reasons first, so the API isn't the weak link.