Difference between progressive profiling and pre-fill function

[Natalie_Ng]

Hi there, I was wondering if you could please provide me with more information on what is the difference between progressive profiling and pre-fill? What recommendations would you provide to put in a form on a landing page collecting information?

[SanfordWhiteman]

Progressive profiling means your forms are divided into Always-On fields (shown every time) and ProgPro fields.

When someone returns to your form, the Always-On fields are there no matter what (perhaps PreFilled, as described below) but already-filled fields from the ProgPro block are hidden, and up to a certain amount of additional empty ProgPro fields are shown in their place.  The form thus changes its shape each time they fill it out, and you gradually build out their profile without overwhelming them with all fields at once. Note they must have an associated web session for this to work -- a new anonymous session in a new device or browser won't work, because the session won't know who they are.

Pre-Fill means the values they previously entered in the form are loaded into the corresponding form fields. This again depends having an associated web session (i.e. a session in which they either filled out a Marketo form or clicked a link in a Marketo email, and in which Marketo's tracking cookie is enabled). The lead can change Pre-Filled field values, or they can leave them as-is and the form will submit.

An all-too-common misunderstanding (which has led to absolutely wrong, yet sadly uncorrected, blog posts) is that ProgPro in some way depends on Pre-Fill. It does not: they are independent features. Fields in the ProgPro block are only identified as "empty" or "non-empty." Their data values are not important to the operation of ProgPro, which determines whether to show/hide based on whether they have a value. It's for this reason that ProgPro works on embedded Marketo forms (on non-Marketo websites) because it doesn't represent a data leak, while Pre-Fill is, out-of-box, not possible on unknown websites because it would mean anyone could read fields from your Marketo database.

What recommendations would you provide to put in a form on a landing page collecting information?

You mean what fields to put on the form? That's a really broad question that I don't think anyone could definitively answer without knowledge of your business. If you have specific questions about general-purpose fields, perhaps phrase your question to concentrate on "I was going to put A, B, C, and D and these are my business reasons" and we can give some feedback.

* This is, in fairness, also possible using more crafty techniques, but Pre-Fill can be used/abused by anyone regardless of skill.

[Natalie_Ng]

Hi Sanford, thanks for coming back to me!

Sorry i should have been more clear in my second question - what i meant to ask is, what recommendations you would provide when choosing between progressive profilling and pre-fill option in a form. And in what circumstances each function works better. 

[SanfordWhiteman]

what recommendations you would provide when choosing between progressive profilling and pre-fill option in a form

It's more than just "choosing between."

You can Pre-Fill any field that you want to let the user change. First Name and Last Name are obvious candidates.

Having Email Address be Pre-Filled is actually a bad idea (despite the fact that people do it all the time) because Marketo forms don't allow an end-user to change their email address out-of-box. They will instead create a new lead, which is not what you want. On the other hand, having Email Address be ProgPro can make it harder to handle the JavaScript necessary to allow a change of address.  So in this case you want yet a third option, which is a form that only shows (the Self-Hiding Field pattern) if it has no value Pre-Filled.

You can add any field to the ProgPro block, but if it falls "below the fold" the first time somebody sees the form, you might never get it filled out, since they have to see the form again in order to add more info (though of course the form could be on another page). So you you can't ProgPro fields that are critical to external profiling.

You can also have the same field be in a ProgPro block on one form, and be in the Always-On block on another form, and completely left off or hidden on a third form.

So like I said, this is a very case-by-case question.

[Natalie_Ng]

Thanks Sanford! Much appreciated!!

[Paul_Hughes]

It seems to me like presenting the email address pre-filled is the lesser of a few evils.

Let's say I send an email, and the recipient forwards it to a friend. That friend clicks the link, but is tracked as the person who had forwarded it. If I display the email address pre-filled, this grants the opportunity to create a new lead. If I don't, then this person will simply change the first and last name of the existing lead, which will corrupt the existing lead information.

It seems easier to deal with merges than it is to deal with separating out cases like the above, even if it ends up happening more frequently.

[SanfordWhiteman]

No, you should still draw a distinction between "Change my email address" and "Not me."

Merges are only simple if you know you need them.

[Paul_Hughes]

Is there any way to implement that distinction without managing JS on all pages where the form appears?

[SanfordWhiteman]

It requires JS-based extension of native form behavior. The code can be stored in external script, but yes, that <script> would need to be included on your templates.

[Paul_Hughes]

If you're drawing the distinction between "Change my email address" and "Not me", how do you avoid the scenario I described above? How is the "Not me" option implemented?

Do you provide a link that, if clicked, runs a script to clear your tracking information and reload the form?