Associate Leads from external site to Marketo Landing Page

[Cory_Colt]

Jay Jiang, I appreciate you answering my questions here. I went through your pre-fill workaround and I can manually set the values for the fields in the form, but when I use the {{ lead.Email }} or {{ lead.Email Address }} it doesn't actually populate anything. I just want to be clear here, the user is on a separate domain and when they click on a link to view their profile they are presented with a link to "manage their subscriptions" this link takes them to a marketo landing page which contains the form I'd like to pre-fill with their data. On our domain (non-marketo) I'm making a request to associate the lead with the munchkin cookie already created. 

My question is if I'm missing a step somewhere in order for the {{ lead.Email }} to work how you have in your pre-fill workaround? Is all that's required for this to work is for me to associate the lead 'before' sending them onto the marketo landing page?

[Jay_Jiang]

I can manually set the values for the fields in the form, but when I use the {{ lead.Email }} or {{ lead.Email Address }} it doesn't actually populate anything

not clear what you mean here, are you only loading 1 field {{lead.Email Address}} from Marketo?

Nevertheless, if your top level domain for your site is different to your marketo CNAME landing pages, then you can't use the pre-fill workaround as the lead's munchkin cookie isn't preserved cross domain.

You'd have to make use of the url to carry across the data

[Cory_Colt]

Sorry, let me clarify what I meant by manually setting the values. In your JS you have something that looks like this: 

var init_fields = {
 "Email":"{{lead.Email Address}}",
 "emailPreferencesPause":"{{lead.Email Preferences - Pause}}",
 "emailPreferencesPauseUTCTimestamp":"{{lead.Email Preferences - Pause UTC Timestamp}}"
 }

By manually setting the email field I meant I did this (just to see if the JS is firing): 

var init_fields = {
 "Email":"test@testing.com",
 "emailPreferencesPause":"{{lead.Email Preferences - Pause}}",
 "emailPreferencesPauseUTCTimestamp":"{{lead.Email Preferences - Pause UTC Timestamp}}"
 }

It works when I manually set the values, so I know it's firing. Based on your last answer it sounds like this just simply isn't possible with how we're trying to do this. So then my question becomes is it better to just pull in the form into our own domain and have the user manage their subscriptions/etc through this form we're pulling in from Marketo? 

[SanfordWhiteman]

Jay's overall approach is fine, I think we're getting very confused here.

You need to pass the values the person entered in the form in the URL - no problem, you always have those values.

You need to populate fields from the URL - no problem, you need a little JS to pull them in b/c Marketo itself doesn't pull them into visible fields.

[Cory_Colt]

Sanford, hopefully this will clear up some confusion. Let me give you a bit of background. Previously on our site we kept track of all the user's subscriptions and email preferences. Recently the decision was made to offload this responsibility to Marketo, so we're having to make changes within our site to no longer track the user's subscriptions and email preferences ourselves. The effort was made to migrate this data over to Marketo, but the problem is from the end-users perspective they don't know anything has changed. Meaning, they still login to our site and can edit their profile. However, when they're editing their profile they no longer see the options for their subscriptions and email preferences (since these got moved into Marketo), so instead they'll see a link in place of where this data used to be to "click here to manage your subscriptions and email preferences" which takes them to this marketo landing page I've been discussing. 

Early on the discussion was to either keep the user on our site (on the same profile page) and just present a form to them (pulled from marketo) to allow them to manage their subscriptions/preferences here OR to create a separate landing page that we then just provide a link and send the user to a marketo landing page. 

Does this clarify some of this?

[SanfordWhiteman]

Let's discuss your exact technical requirements.

If you're ensuring they have an associated session and the page you want to Pre-Fill on is a Marketo LP, then you can use my Pre-Fill JS library, or attempt to Pre-Fill directly from {{lead.tokens}} on the LP as Jay suggests.

If you're ensuring they have an associated session but the page you want to Pre-Fill on is a non-Marketo LP, then you must use my Pre-Fill JS library.

[Jay_Jiang]

What's the reason your landing page domain can't be the same as your site?

Let's take a further step back, there's a fundamental problem here. You're saying you no longer want your site to track the person's email preferences and want Marketo to take care of this now. However, the first time a person visits the Marketo LP on an unrecognised device, or if they've never submitted the form on the LP, they won't be recognised by Marketo and their existing preferences won't pre-fill no matter what. So you can send the person's email address and details to the LP in the URL, but if you want their existing preferences to pre-fill from Marketo, you actually need to have the top level domains the same so pre-fill can work due to the shared munchkin ids - assuming you're associating them every time they log-in to your site.

[Jay_Jiang]

In a project I've previously worked on, the preference centre was managed by the site and data was stored in the site's DB. People's preferences would be pre-filled from the site's DB and where email preferences were updated and saved in the DB, the site also triggered a REST API call to Marketo to update their record. If you're already using REST API in your site, why don't you use it to update their their preferences?