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.
Thanks in advance for your replies!
Solved! Go to Solution.
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
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
-Greg
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:
Thanks again.
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).
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
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.
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.
I was using a 2 second delay - random meaning that values doesn't have a solid reasonbesides it seems to generally work (understanding it's bad!).
"true poll: check every 2 seconds to see if you can load the form with the lead data" - I haven't looked into a way to do this yet. Any proven implementation pointers/details before I start my search?
Thanks for the advice on the "source of truth". With our current system, we store in our DB then replicate as suggested. With this transition to Marketo, there is a strong desire to allow the business to maintain these forms without IT intervention, thus the reason for proceeding as described.
You've been a tremendous help - thank you!
I was using a 2 second delay - random meaning that values doesn't have a solid reasonbesides it seems to generally work (understanding it's bad!).
The thing is, it won't always work. I steer clear of anything that is based on "that should probably be long enough." Polling every N seconds up to a certain max wait time means you aren't guessing... yes, you're still choosing a value for the max timeout like 30s, but that's based on managing the UX as opposed to guessing about the back end.
"true poll: check every 2 seconds to see if you can load the form with the lead data" - I haven't looked into a way to do this yet. Any proven implementation pointers/details before I start my search?
Have the iframe call back when the JS object mktoPreFillFields contains data. The implementation is left as an exercise for the reader.
Thanks for the advice on the "source of truth". With our current system, we store in our DB then replicate as suggested. With this transition to Marketo, there is a strong desire to allow the business to maintain these forms without IT intervention, thus the reason for proceeding as described.
Hmm, I can definitely see the appeal. It's just not a perfect fit with Marketo technology. Munchkin::associateLead is principally to associate Munchkin-logged web activities (views/clicks) with a lead when a user hasn't followed a marketing email or filled out a (Marketo) form, so if the link happens 5-30s after the call it's not a big deal because the views/clicks themselves are showing up asynchronously, too. Rarely is there a need to do what you're doing, where instead of tracking somebody's activity on the server you need to catch the client up with server activity.
I believe I have plenty of good advice for me to proceed now. Thanks again Sanford!