Link to a Landing page URL with mkt_tok

[Anonymous]

I'm setting up a landing page to serve as an email subscription center where people can chose which emails they want to sign up for. I've added an unsubscribe link in my email template footer that points to my landing page URL, which works great when the lead uses that email link to manage their subscription preferences.

https://my.example.com/email-preferences.html?mkt_unsubscribe=1&mkt_tok=##MKT_TOK##

However I also want to give our customers the ability to view this email subscription landing page from our website when they're logged into their account. The problem I'm having is that my landing page requires the  mkt_tok=##MKT_TOK## parameter to load up the lead's current preferences and save correctly.

How can I get my landing page load up correctly for a lead? Is there a way to generate a Marketo token value for my URL that is specific to a lead?

One solution I was thinking of was to possibly duplicate the landing page subscription preferences as a separate page on our website, and then send the data changes to the Marketo API as a createUpdateLead request. Then add a new webhook to my form in Marketo (somehow?) that calls a custom page on our website to keep the email preference checkboxes in sync.

[SanfordWhiteman]

You don't want (nor can you generate) a mkt_tok.

Nor do you want to use the REST API in response to individual user actions: this will create a Denial of Service vulnerability. (Also, webhooks don't work in the way you're imagining.)

What you want is a Munchkin associator token (AT), used with the Munchkin associateLead method (not to be confused with the REST associateLead).

Such tokens are designed precisely for the case where you have already identified a lead through other means and want to bring Marketo into the loop by associating the current web session with that lead. You can read about ATs here: http://blog.teknkl.com/generating-munchkin-associator-tokens-in-sfdc-apex-or-flowboost-js/

[Anonymous]

Thanks, Sanford. To confirm, are you saying that the preferred approach is to duplicate the landing page form on our website versus trying to reuse the Marketo-hosted landing page that's navigated to via email campaign unsubscribe links?

Does the below list summarize your control flow?

1. Lead submits form hosted on our site with the email list subscription preferences (each checkbox mapping to a lead field).
2. Server-side logic calculates the lead's Munchkin associator token.
3. Confirmation webpage is generated and viewed, containing a JavaScript call to the Munchkin associateLead method with the lead fields just changed.

If the above logic is correct, then I'm wondering how I can keep my website database up to date with any change to these email subscription lead fields that occur on the Marketo-hosted unsubscribe page via an unsubscribe email link. Perhaps the email subscription center Marketo landing page goes away entirely, in favor of self-hosed webpage(s) for both unauthenticated (via unsubscribe email link) and authenticated users?

[SanfordWhiteman · Accepted solution]

Thanks, Sanford. To confirm, are you saying that the preferred approach is to duplicate the landing page form on our website versus trying to reuse the Marketo-hosted landing page that's navigated to via email campaign unsubscribe links?

Mmm, no... you use the Marketo-hosted LP in all cases.

Does the below list summarize your control flow?

Nope.

When someone is identified on your site ("when they're logged into their account") you generate, on your server, the Associator Token.  Then you send that back to the browser and call the Munchkin associateLead, i.e.

Munchkin.munchkinFunction('associateLead', { Email: "steve@example.com" }, <Associator Token>);

From that point forward, their web session is associated with their Marketo lead, so when they view the Marketo LP their data will be loaded. Of course I am assuming my.example.com and www.example.com do indeed share the private domain suffix example.com, so they will have a single Munchkin cookie.

[Anonymous]

Ahhah, that makes more sense! Thanks -- I'll give that approach a go.