If I have PURLs enabled for a landing page, shouldn't the form on my landing page prepopulate?

[Justin_Cooperm2]

Here is the current behavior (although we are actually considering changing it):

Assume you are not cookied at all (you've never visited a landing page):

• When you go to a pURL the tokens on the page WILL be replaced with the value for the lead the pURL corresponds to.
• Forms will NOT pre-fill (forms only pre-fill based on the user's cookie). We do not pre-fill a form simply because the user navigated to a pURL in the address bar.
• There is a workaround for forms by making the "Default Value" of your fields a lead token. So, you could make First Name's default value {{lead.First Name}} and it will essentially "prefill" but it's not using Marketo's out-of-the-box prefill functionality.
• "Visited Webpage" will NOT be logged unless the user fills out and submits a form on the page. Just hitting the page will not log this activity for the lead corresponding to the pURL.

Assume you are already cookied:

• When you go to a pURL the tokens on the page WILL be replaced with the value from the cookie (NOT the lead linked to the pURL). The cookie always wins.
• Forms WILL pre-fill (since forms pre-fill based on the user's cookie) with the values corresponding to the cookied lead (NOT the lead linked to the pURL).
• "Visited Webpage" WILL be logged for the cookied lead (NOT the lead linked to the pURL), even if they don't submit a form.

[SanfordWhiteman]

• There is a workaround for forms by making the "Default Value" of your fields a lead token. So, you could make First Name's default value {{lead.First Name}} and it will essentially "prefill" but it's not using Marketo's out-of-the-box prefill functionality.

And you can create mktoPreFillFields using tokens.  Which is why there are 2, rather than 0, ways to prefill forms on a previously uncookied visit to a pURL, both of which are easy and indistinguishable from regular prefill. That's not the part that can't be done.

The part of pURLs that is definitively broken (as opposed to mildly annoying) is that an anonymous cookie overrides the known lead's Marketo Unique Code/Name.  That's what leads people to think they just plain don't work.  The solution -- which I'll blog about when I get a chance -- involves clearing the cookie before redirecting to the pURL, then associating the old activities.

[Justin_Cooperm2]

Yeah, I agree with that. That's not great behavior for already cookied ANONYMOUS leads. We'll look into all this and see if there's some improvements we can make.

[Abaran]

Thanks all for the feedback.

Marketo support has confirmed to me that token load on the pURL page only once. If you reload the page it the tokens will be blank. It is an Issue they are working on. No ETA.

Regarding the pURL - it seems to me this is going against logic. If we do pURLs, the key word is personalized so loading the records details would seem the right thing to do.

Thoughts?

[SanfordWhiteman]

Marketo support has confirmed to me that token load on the pURL page only once. If you reload the page it the tokens will be blank. It is an Issue they are working on. No ETA.

They are miscommunicating (or misunderstanding).  The reason this appears to be true is that the pURL associator (Unique Code/Unique Name) cannot override an existing anonymous cookie, which is exactly what Justin and I are talking about.  The cookie exists after the first load. In fact if you delete the cookie, it works fine on every load.  You can already do this, and that's part of getting around the pURL problems. Problems which, again, do exist but are almost never communicated correctly.

Regarding the pURL - it seems to me this is going against logic. If we do pURLs, the key word is personalized so loading the records details would seem the right thing to do.

It's counterintuitive. I'm not arguing with you there. The Marketo Unique Code/Unique Name were essentially made "weak attractors" compared to other forms of lead-to-session association.  Being weaker is not necessarily a problem, because there have to be differing priorities, or conflicts cannot be resolved (just as there are rules about whether a mkt_tok from a clicked link has higher priority than a cookied known lead).  The problem is that the pURL associators were made weakest, weaker than even anonymous cookies.

[Abaran]

Thanks for the clarification.

[Tracey_Bartz1]

Assume you are not cookied at all (you've never visited a landing page):

• "Visited Webpage" will NOT be logged unless the user fills out and submits a form on the page. Just hitting the page will not log this activity for the lead corresponding to the pURL.

I just want to confirm that no one has found a workaround for this. I'm hoping to direct people to a landing page via pURL that would have ungated links to content. I would like to use clicks on that content as smart campaign triggers, but if the landing page visit isn't tied to the person, then I wouldn't be able to accomplish what I'm looking for. The only option would seem to be to gate all the content behind forms so I can be sure that the visits and downloads are tied to the individual people.

[SanfordWhiteman]

Why use a pURL for this? An unadvertised, unindexed LP has the desired behavior.

[Tracey_Bartz1]

Because we're driving people to it via direct mail.

[SanfordWhiteman]

OK. Well, the idea behind opting-in to tracking with a pURL is that direct mail can be physically rerouted very easily (i.e. given to/taken by a colleague). If you're ready to take the risk, you can hide the form and submit it automatically, then refresh the page. Then everything is logged by Munchkin.