Marketo Forms for known web users | Community
Skip to main content
A
Anonymous
November 12, 2015
Solved

Marketo Forms for known web users

  • November 12, 2015
  • 2 replies
  • 4141 views

I am very new to Marketo and trying to find the best approach to leveraging Marketo while minimizing custom development.  The first task is simply setting up subscription management within Marketo, which will later turn into a full preference center.

Since Marketo will manage the subscription status (and other attributes later), creating a form within Marketo makes sense.  What I'd like to know is how others have gone about implementing a similar solution for an authenticated user on a web site (which may also be across different domains).  Once a user logs into our website, I will know their email address, and need to set the context of the Marketo form to use that email address.

  • I have tried to work with the munchkin API, but that utilizes cookies and I ran into problems when crossing domains.
  • I am looking at the REST API to get lead information, but passing information via a URL to a landing page would present a security/data integrity concern (anybody with HTML knowledge would be able to manipulate data of another individual).

Thanks in advance for your replies!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

Don't even consider calling the REST API from the browser.  Proxying user actions hit-for-hit to the API is a DoS risk, way out in front of any data integrity risk.

I don't know how hard you've worked on the Munchkin API, but the explicit purpose of Munchkin::associateLead is to take a user identity that you've obtained via other means and link that to the current Munchkin cookie.  Once the cookie is associated, then in a form hosted on a Marketo-hosted Landing Page, you will be able to display fields from the user's lead record. In an embedded form not hosted on Marketo, existing values will not prefill, although you can still blindly give them all the options and the form post will update their lead record accordingly.

So since you obvs. have the user's email address and can confirm that they are logged in, Munchkin::associateLead should be all you need.  It's the way my clients work.  For example, checking for back-end CMS or CRM authentication and then associating the lead.

As for cross-domain issues, you should check this recent thread: Associating anonymous and known leads across different domains

2 replies

SanfordWhiteman
SanfordWhitemanAccepted solution
New Participant
November 12, 2015

Don't even consider calling the REST API from the browser.  Proxying user actions hit-for-hit to the API is a DoS risk, way out in front of any data integrity risk.

I don't know how hard you've worked on the Munchkin API, but the explicit purpose of Munchkin::associateLead is to take a user identity that you've obtained via other means and link that to the current Munchkin cookie.  Once the cookie is associated, then in a form hosted on a Marketo-hosted Landing Page, you will be able to display fields from the user's lead record. In an embedded form not hosted on Marketo, existing values will not prefill, although you can still blindly give them all the options and the form post will update their lead record accordingly.

So since you obvs. have the user's email address and can confirm that they are logged in, Munchkin::associateLead should be all you need.  It's the way my clients work.  For example, checking for back-end CMS or CRM authentication and then associating the lead.

As for cross-domain issues, you should check this recent thread: Associating anonymous and known leads across different domains

A
Anonymous
November 12, 2015

Thank you Sanford - this helps confirm I was on a good track with my initial approach which felt promising.  I replied to Greg's post above also, and would like to hear how you get around knowing the status of the Munchkin associateLead so I don't need to add a setTimeout with an uncertain delay.  From what I understand, there is no callback/promise that I can use.

SanfordWhiteman
SanfordWhiteman
New Participant
November 12, 2015

Thank you Sanford - this helps confirm I was on a good track with my initial approach which felt promising.  I replied to Greg's post above also, and would like to hear how you get around knowing the status of the Munchkin associateLead so I don't need to add a setTimeout with an uncertain delay.  From what I understand, there is no callback/promise that I can use.

Right. The association is asynchronous (on the back end, not just on the XHR level).  I wouldn't use a random setTimeout, though, but a true poll: check every 2 seconds to see if you can load the form with the lead data, and then show the IFRAME only when it's populated (with nice spinner & such).

But I must say there are some... uncertain... slopes here.  Most Marketo customers use SFDC and I find that managing subscriptions within SFDC (as the "source of truth") and then letting them sync over to Marketo is more maintainable.  After all, there is little reason for user-triggered subscription changes to take actual effect (in terms of Marketo sends) immediately as opposed to after 5-15 minutes, as long as changes can be displayed to the user in real-time.  You might think about managing your subscriptions in your own database, then flushing them over to Marketo in bulk once an hour/day. In this case using the API is safe since it's a bulk action.

Grégoire_Miche2
Grégoire_Miche2
New Participant
November 12, 2015

Hi Eric Durocher,

You may want to use multiple domain feature to publish your subscription page in each domain. See the doc here : Add Additional Landing Page CNAMEs - Marketo Docs - Product Docs

and an example here :

-Greg

A
Anonymous
November 12, 2015

Thank you Greg!  I think that will help with solving my cross domain issue.  I will look at adding the additional CNAMEs and referencing the landing pages using those.  I have a couple follow up questions on a practical implementation:

  • After a user authenticates on our web site, I will need to call an associateLead action, which I was doing using Muchkin (generating the HASH server side to protect the key).  Does that seem reasonable or should I resort to server side REST calls?  Any additional details on a working solution would be appreciated.
  • Using Munchkin, I found there is no callback after issuing the associateLead call, so I need to add an artificial pause before loading the form.  If using Munchkin, do you have a recommendation on how to know when the associate action was successful?
  • Once I issue the associateLead call based on the email address, does that take care of all my "linking" concerns?  The idea is that the only shared attribute is email, and the web and Marketo will house their own specific attributes beyond that.  From there, we just iFrame in Marketo forms where desired.

Thanks again.

SanfordWhiteman
SanfordWhiteman
New Participant
November 12, 2015

should I resort to server side REST calls? 

Use the REST and SOAP APIs only for bulk actions, not in response to individual user actions.  This should be your mantra (it kind of is mine).

Terms & ConditionsAccessibility statement

Loading footer...