Undesired behavior when using Personalized URLs PURLs

[Dan_Stevens_]

I had some members of my team participate in a series of PURL test and came up with the following findings: 

1. If the user has been previously cookied AND known, but enters a PURL intended for someone else, Marketo will correctly identify the user based on their cookied data and NOT based on the PURL.
2. If the user has been previously cookied (and known), when they enter the PURL, they will be identified using the data in their lead record in Marketo - and a personalized landing page experience can be used.
3. [EDIT 11/20/2017]: If the user has an associated cookie on their browser (e.g., visited your Munchkin-enabled web page) but is not yet KNOWN, when they access their PURL-enabled LP, the page will not be personalized (tokens will remain blank) - even though a lead record had been created in Marketo to support the creation of their PURL.
4. If the user has does not have an associated cookie on their browser, when they enter their PURL, the personalized tokens will render properly on the LP.
   
   

1, 2 and 4 is the desired behavior.  And our desire for #3 would be to have the user identified by the data that was used to create the PURL.  Does Marketo have any plans to improve upon this?  We're using this approach for a direct mail campaign - and as a result of #3's outcome, I don't think we can rely on Marketo PURLs for appropriate tracking purposes and personalization via tokens.

[Dan_Stevens_]

Let's say we include a PURL in an email and the user has never been cookied (but is a lead in Marketo).  Can anyone confirm if the LP - regardless if the lead has been cookied before - would display the personalized content as desired.  My thought here is - for those leads that have never been cookied, will be, when they click the tracking link in the email.

Also, Sandy, can you identify the inaccuracies that you noted in my original post?  I'd be happy to modify this so that it reflects accurate behavior.

Sanford Whiteman​

[SanfordWhiteman]

I'd like to avoid the expression "user has [never] been cookied" because it isn't clear whether that means "known lead has been assoicated" or something else.

Using the the expression "browser has never had a Munchkin cookie" will probably be clearer.

If the browser has no Munchkin cookie at the time the pURL is rendered, the page will render in the context of the Marketo Lead, including tokens, snippets, etc. Note such a cookie wouldn't have to have been set by a Marketo-hosted LP, let alone by the pURL LP itself.  It could've been set by your 3rd-party website.  In any case if there is no cookie, the pURL operates as desired.

However, if there is a cookie, even an anonymous cookie -- and if Munchkin is enabled on the pURL LP, there will be a cookie immediately ​after​ the first view -- then the pURL will not operate as needed/desired. As I phrased it on another thread, the pURL pathname extension (Marketo Unique Code) is a "weak associator": in the absence of any other associated/unassociated session info, it'll help you out, but once any other info is available, it shows its weakness.

So the solution to the pURL problem -- and it can be done even now -- involves "archiving" the existing cookie before sending people to the pURL page, then restoring it later.

[Anonymous]

Hello,

I'm looking into this and doing an assessment of the various scenarios. There is actually a security risk...I'll explain. We know, a lead has to be known in order for the PURL to be generated (therefore the PURL has that person's information associated to it.) Referring to #3 above, in an ideal case, if a user has not been cooked and is anonymous, when they enter their own PURL they should see their information on that page pulled from the known lead record in Marketo. This will include any pre-filled out form fields (possible PII)

Say you have a malicious user who is not cookied and is anonymous. If they get ahold of your PURL, or guess the format and hack into other's, that person will see the PII of the lead associated to the PURL. Hence the risk. So it does depend on what you will have on the LP.

Now, it might not be a big risk if you don't have a lot of personal info (or nothing you'd consider PII) but wanted to call that out. Please let me know if you have other comments about this. I will follow-up once I have more information from my side. At this time I'm trying to understand the effort involved into making PURL a usable feature.

Tatsuya Nitta​

[Dan_Stevens_]

Hi Christina Fuentealba, back when we talked prior to this past year's Marketo Summit (April 2017), you mentioned that your team was going to enhance this process (achieving the expected outcome in scenario #3 above) by restricting the personalization to just a few attributes (name, company, country, etc.).  The planned deployment date would be shortly after Summit (in the Spring).  Can you provide us with an update on this?

[SanfordWhiteman]

You saw my pURL fix, right, Dan?

[Dan_Stevens_]

Yes, Sandy (assuming you're referring to this: http://blog.teknkl.com/fixing-marketo-purls.  Unfortunately, for us to use your FormsPlus base library, we would have to go through a comprehensive privacy/security review with our IT/InfoSec teams.  So the desire is to have this natively work as expected within Marketo.  And supposedly Marketo was going to fix this back in the spring/summer - based on my conversations with Christina just before (and during) Summit. 

BTW, I revised the scenarios up top, in my original post.  This issue - like you've clarified many times - is when the users has an associated cookie (e.g., anonymously visiting a Munchkin-enabled page) AND THEN tries to access a PURL-enabled URL for them, the personalized tokens render blank (even though there is a lead record in Marketo with this data).

[SanfordWhiteman]

There's no more security risk here than on any LP with prefilled fields. If you don't want people peeking at others' PII, don't include that information on a page that only requires an email for "authentication." If I want somebody's PII and I know their email, I'm not going to try to guess their Marketo unique code, since I can already impersonate them.

[Abaran]

Has anyone have an update on this? We are facing the same issue. Asked Marketo today and they confirmed pre-population does not work on PURLs.

I read on here that we could use tokens within the forms as default values.Has anyone tried it? Here is the thread: https://nation.marketo.com/message/95599#comment-95599

Thanks

Axel

[Grégoire_Miche2]

Added there: Just do it! Marketo so-called minor missing features

in the bug section.

[Anonymous]

My guess is that the Marketo Product Team fears this as a security issue.

[SanfordWhiteman]

There's no security issue.  It's simply an incomplete -- or, from a generous angle, minimalist -- implementation compared to marketers' expectations. (If you test, Dan's summary is not quite accurate, though there are equivalent major frustrations involved.)

Fixes and workarounds exist, but unlike other areas, you need to use a developer to get the basic expected functionality (as opposed to advanced functionality).

[Ayan_Talukder]

Was this ever resolved by the Marketo team? We're about to run a direct mail campaign and want to try this exact same scenario. It seems if they are not cookied there is no point running the campaign.

One way around this I have found (which is slightly manual and not Marketo related) is to mass generate short URLs using a bit.ly API. You can export the results from bit.ly to see how many times a link has been "clicked". Pivoting the results in Excel will show you which URLs were actioned upon but these results cannot be added into Marketo.

This is one idea for Marketo perhaps? To obtain the data on which anonymous leads accessed the link, it can track which link was clicked and track that individual? I'm sure it's more complex than that but it seems like a foundation to start from perhaps. It would just be crucial to ensure the wrong links don't get clicked by the incorrect individual.

[Dan_Stevens_]

Marketo has not fixed this - I'm not even sure they consider this a bug. We too scrapped all PURL-based DM campaigns in Marketo. If we can't offer a personalized experience when the user arrives to a Marketo landing page, there's no sense in using PURLs to begin with.

[Anonymous]

Has anyone ever tried this for an email campaign?

[SanfordWhiteman]

Lindsey, I don't know if you saw this recent discussion but there are effective workarounds that apply equally to email (I suppose you mean if you are sending from outside Marketo).

[Anonymous]

Has there been an update on this issue?

[Sean_McCombs]

Unfortunately this is a Product issue that is still being addressed by Product Management.

[Anonymous]

Is there an update from product development on this? Curious to know if this has officially been addressed as we're about to start a campaign where we will be implementing the PURL process.

[Dan_Stevens_]

Please keep this thread updated if you receive any new information.  I agree, it is a shame that Marketo doesn't want to enhance the capabilities to support the direct mail channel.

[Anonymous]

Thanks Dan!  We'll call Marketo support and double check.  That's dissapointing if they didn't update this.