Hello all,
I understand that, form prefill doesn't work when embedding a form on webpage.
Isn't there any way? really?
TIA.
Syed
Solved! Go to Solution.
Here's one workaround: http://developers.marketo.com/blog/external-page-prefill/
Is anybody seeing a 30-40 second delay from when a user first clicks through an email to when the Marketo Cookie is associated to a lead (You can make rest API queries and you'll get empty results until 30-40 seconds have past)?
The article is great, but the prefill doesn't work for first time users. Works for repeat though
Like I said, I'm seeing a 30-40 second delay before the REST cookie query will return with a match. Associating a cookie value to a lead is taking Marketo way to long.
I've opened a case. Really if Marketo can provide you with a cookie value you should be able to do a query on it immediately and get results. If not, its just plain poor engineering/systems.
The cookie is generated entirely on the browser, so there's no correspondence between its availability on the client and its association with a named lead (or even its logging of activities to an anonymous lead).
Association is always asynchronous, and 30s latency happens. Merging with existing leads can't be expected to be complete by the next pageview.
Ok. I assumed Marketo generated a unique cookie value.
But now I'm curious, If the cookie is generated entirely from the browser, how does Marketo ensure that a cookie value is unique then and won't give false matches in the case that an identical cookie value is assigned to more than one device (Probably fairly unlikely, but possible)?
So here is what I think I'm going to do to enable prepop:
1.) Create a webhook that will preface the Marketo lead ID with a random string. Return this new value in a custom field. Run this each time a new lead is created. This new field will be used as a lookup field (This is necessary. You could use the email as a lookup value, but that will cause privacy/security issues. You could use the marketo lead id, but that would leave you open to security issues, where someone could iterate through IDs quite easily and gain access to customer/lead information.)
2.) Merge this custom field as a parameter in email links
3.) When a user hits a landing page with a form, get the value from the URL. If it exists and do a lookup to get the necessary fields to prefill the form. If the value does not exist in the URL, do a lookup based on the cookie for the necessary fields to prefill the form.
...how does Marketo ensure that a cookie value is unique then and won't give false matches in the case that an identical cookie value is assigned to more than one device?
Analytics libraries always create session cookies client-side. There's no guarantee of crypto-grade uniqueness (i.e. v4 GUID) across browsers in any case, since some browsers only have Math.random(), but Marketo's algo definitely is less than perfect: between the timestamp in milliseconds + random 5-digit suffix it's extremely unlikely, but not impossible, to have a duplicate. You can set your own cookie value if this is a deep concern (add more entropy to the timestamp portion).
1.) Create a webhook that will preface the Marketo lead ID with a random string. Return this new value in a custom field. Run this each time a new lead is created. This new field will be used as a lookup field
OK -- you'd just need to left-pad the Lead ID to a fixed length for this to work, unless you're using only alpha characters.
3.) When a user hits a landing page with a form, get the value from the URL. If it exists and do a lookup to get the necessary fields to prefill the form. If the value does not exist in the URL, do a lookup based on the cookie for the necessary fields to prefill the form.
I would never, ever implement this because of the clear DoS vulnerability. But it'll work up until that point.
Kara Pietrykowski Dan's reply (that you just marked as helpful) is actually incorrect. Clicking Submit on the reduced-footprint form on the Known Lead HTML is still a form fillout.
Hi Sanford,
So the article linked is incorrect for form pre-fill? http://developers.marketo.com/blog/external-page-prefill/
I am not a developer and trying to get information that I can pass onto our external developer.
Cheers!
Actually, I may have mistaken which post you were tagging. I was actually noting that Robb's comment about the Known Lead HTML + Filled Out Form activities wasn't right.
But no, I don't think any sane person should use the method in that post, for the DoS reasons I described above.
So just to clarify
Progressive Profiling DOES NOT EQUAL pre-filled forms?
So then, what exactly is the purpose of progressive profiling?
I'm trying to make it so that if a known lead hits a landing page with a form, the info is pre-populated.
Progressive Profiling means you are changing the fields a lead is entering if they've visited the form multiple times. It helps you gain more data about someone without having them submit the same stuff over and over again. It is different from form prefill.
Form prefill fills the fields of the form when the lead visits the page with the form. It is not possible out-of-the-box on external pages but it works on Marketo landing pages. Sanford has examples of how to implement it for external pages but it takes some effort.
"Progressive Profiling means you are changing the fields a lead is entering if they've visited the form multiple times. It helps you gain more data about someone without having them submit the same stuff over and over again. It is different from form prefill."
Makes sense. Does this cross-over to multiple forms? Let's say a lead hits Landing Page 1 and fills out First and Last Name to get access to a gated content. Now the same lead visits Landing Page 2 with a new form, does progressive profiling pick up from the last form? As in, Lead 1 wouldn't have to enter First and Last Name again but instead this time around they're asked to provide email and company name?
It kinda depends on how you've structured your forms, but here is our docs page: http://docs.marketo.com/display/DOCS/Configure+Form+Progressive+Profiling
Yes, this works across multiple forms/pages. As long as the data exists within the lead record (in this case first/last), then as long as PP is activated on the other form, it will see that it does not need to surface those two fields again.
Okay, so another question.
Let's say Lead 1 has gone filled out 3 or 4 forms now, and all desired info is collected. If they hit a new LP with gated content, what will the form display since there's no additional data to collect?
Check out our forms docs. You can have some of the fields always show and some of them show conditionally (using progressive profiling). Most of our customers use a combination of the two in a form. Also, we have the "if known lead show custom HTML" feature in our forms which means if the user comes back, show them something like "Welcome back, Justin. Click here to download" or something similar.
However, doing this will not register as "Filled out Form" so if your workflow drives off that action you lose out. In fact, if you use the "Known Lead" the only way to see what happens is if they click on a link in the Known Lead HTML that drives them to the next page.
Progressive Profiling DOES NOT EQUAL pre-filled forms?
So then, what exactly is the purpose of progressive profiling?
Progressive Profiling (ProgPro) is used to gather additional information from the lead over time. For example, you ask them a couple of questions on visit 1, then a couple more questions on visit 2.
This doesn't require form data to be PreFilled, because all that matters is that the previous questions have been answered at all. The values from previous (now hidden) questions don't need to be displayed in the browser. That's why you can support ProgPro without leaking PII, but you can't support PreFill without privacy concerns.
FYI this should have been fixed Friday evening 4/8. Please let me know if you still see issues with progressive profiling or known lead behavior.
You can prefill with 2.0 by querying the Marketo API and pulling the values, then using form.vals() to populate them.
Sure, if you don't care about it (or your other integrations) functioning when you have a successful campaign -- or when a script kiddie or competitor decides they don't like you, whichever comes first.