Is a PURL like a vanity URL?

[Jamie_Barclay]

I'm wondering if a PURL is like a vanity URL?  We have a print-based camapign that we want to bring to a Marketo landing page.  So I need a (vanity) url to include in the postcard.  Would a PURL be used?

[SanfordWhiteman · Accepted solution]

Yes, pURLs are lead-specific variants of a landing page.  They are expressly for situations like direct mail or print.

However, they have a few oddities that can only be fixed with custom JS code. Principally, they are designed for leads who have never visited your site before, even anonymously.  As I usually put it, the pURL is a "weak associator" to the named Marketo lead -- weaker than the association between a Munchkin session and an anonymous Marketo lead. So it can't override the latter out-of-the-box.

[Dan_Stevens_]

It's also worth pointing out that if the desire is to use PURLs to provide a personalized experience on the landing page, that can only be done if the user's browser has a Munchkin cookie associated to him/her.  See this thread for more info: Undesired behavior when using Personalized URLs PURLs

[SanfordWhiteman]

... that can only be done if the user's browser has a Munchkin cookie associated to him/her...

Or if they have no cookie at all. That's the hitch. Either an already-associated session, or no session (neither anonymous nor associated) at the time they request the pURL.

[Dan_Stevens_]

Can you elaborate, Sandy?  In all of our tests, if the lead didn't have a cookie on their browser, none of the personalization features (e.g., tokens) were accessible.

[SanfordWhiteman]

Open an Incognito/Private window and visit this link.

[Dan_Stevens_]

I get this.  So if you had this info associated with the lead record associated with this PURL, how were you able to pre-populate with tokens?

[SanfordWhiteman]

Them's just tokens, man.

FN: {{Lead.First Name}}

LN: {{Lead.Last Name}}

[Dan_Stevens_]

I realize that.  But when we tried this in our environment, if the lead accessing the PURL didn't have a cookie on their browser (or never cookied from visiting a page containing Munchkin), their tokens did not render on the page.  The token placeholders were blank - even though the records we created in Marketo were populated with values.

[SanfordWhiteman]

All you're looking at on that page is a pURL-enabled LP with a couple of tokens -- no magic!  Note that if you refresh the page (because there's no JS customization on that one, it's just vanilla aFree-form LP) the tokens will no longer render because that second time, since a Munchkin cookie -- an anonymous one -- is written by the page when it loads.

I don't know what you could be doing to make this behave differently, since this was always been the behavior I've seen.

[Dan_Stevens_]

Just did some more tests on our end and it seems to be working differently than when we tested this several months ago.  The tokens did indeed populate based on the data that was contained in the lead record of the pURL we were testing - even in incognito mode.  However, when accessing the page with a cookied browser - and using someone else's pURL - the tokens resolved to my data (instead of the that of the pURL lead record).

When I included a form on that page, the form pre-fill did not populate the respective fields.

[SanfordWhiteman]

Just did some more tests on our end and it seems to be working differently than when we tested this several months ago. The tokens did indeed populate based on the data that was contained in the lead record of the pURL we were testing - even in incognito mode. However, when accessing the page with a cookied browser - and using someone else's pURL - the tokens resolved to my data (instead of the that of the pURL lead record).

Right, this is what I mean by the pURL (that is, the Marketo Unique ID) being a "weak associator."  It can't override the associated cookie nor even an unassociated anonymous cookie. But if it is the only associator present, it will work as desired.

When I included a form on that page, the form pre-fill did not populate the respective fields.

When the pURL associator is the active association, then Prefill will work.  I added a form to the above link to show this.

[Dan_Stevens_]

When I tested this in an incognito window, I got this:

In my own pURL tests that I created, I couldn't get the form to pre-fill.  Did you use a different approach than simply selecting the "pre-fill" checkbox in the form editor?

When I tested this using my browser that had a known Marketo cookie, I got this:

Shouldn't my known information have been populated here - even though I used the same link as above?

[SanfordWhiteman]

In my own pURL tests that I created, I couldn't get the form to pre-fill. Did you use a different approach than simply selecting the "pre-fill" checkbox in the form editor?

Actually, I did (in my defense I created that demo long ago, so I didn't look at the form setup). In this case it uses tokens as the default values instead of PreFill: PreFill proper does not work in this case. But tokens offer a superset of what PreFill can do, so you are fine with tokens instead.

Shouldn't my known information have been populated here - even though I used the same link as above?

You have a cookie associated with a known lead on my test instance?

[Dan_Stevens_]

You have a cookie associated with a known lead on my test instance?

I do not.  So this is one of the issues, correct.  If a user has a Marketo cookie on their browser - not necessarily associated with the site being accessed - Marketo will not render any of the tokens per user accessing the page.

[SanfordWhiteman]

I do not. So this is one of the issues, correct. If a user has a Marketo cookie on their browser - not necessarily associated with the site being accessed - Marketo will not render any of the tokens per user accessing the page.

No, the cookie has to be from the site being accessed or else it will never be visible in the browser.

But if it is an anonymous cookie, that anonymity will override the pURL -- again, the pURL is a weak associator and cannot override any existing positive or negative association.

[Dan_Stevens_]

That helps. So in a nutshell, using pURLs for the purpose of personalizing the user experience, can be very inconsistent based on the different types of users who may visit a tokenized page (existing known cookie, existing anonymous cookie, no cookie, etc.).

I'm definitely interested in seeing what sort of progress has been made to making the pURL experience more consistent (and usable) - based on Christina Fuentealba​'s comment in this thread: Undesired behavior when using Personalized URLs PURLs 

[Jamie_Barclay]

Thank you for the clarification. 

Question: we generate our vanity URLs internally (i.e., campaign@blueshieldca.com).  I'm looking for a recommendation of creating vanity URLs for marketo landing pages.

[Dan_Stevens_]

Vanity URLs can be created by creating a new "redirect rule" in ADMIN > LANDING PAGES > RULES

[Jamie_Barclay]

Thanks Dan - I'll look into this - seems logical.

[SanfordWhiteman]

campaign@blueshield.ca is an email address.

I don't understand the connection to vanity URLs (http://lp.example.com/page/{user id}).