Undesired behavior when using Personalized URLs PURLs | Community
Skip to main content
Dan_Stevens_
Dan_Stevens_
Level 10
March 18, 2014
Question

Undesired behavior when using Personalized URLs PURLs

  • March 18, 2014
  • 14 replies
  • 9698 views

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.

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

    14 replies

    Show previous replies
    A
    Anonymous
    April 30, 2016

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

    SanfordWhiteman
    SanfordWhiteman
    Level 10
    April 30, 2016

    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).

    Grégoire_Miche2
    Grégoire_Miche2
    Level 10
    April 30, 2016

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

    in the bug section.

      A
      Anonymous
      August 4, 2016

      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​

      SanfordWhiteman
      SanfordWhiteman
      Level 10
      August 4, 2016

      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
      Abaran
      Level 5
      August 22, 2016

      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

      Dan_Stevens_
      Dan_Stevens_Author
      Level 10
      September 16, 2016

      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
      SanfordWhiteman
      Level 10
      September 17, 2016

      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.

        Terms & ConditionsAccessibility statement

        Loading footer...