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?
Them's just tokens, man.
FN: {{Lead.First Name}}
LN: {{Lead.Last Name}}
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.
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.
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.
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.
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?
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?
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.
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.