Token encoding in Follow-Up URL

[Anonymous]

I'm trying to use tokens in the follow up URL from a form, and I'm having mixed results.

So, for example, I'm trying to redirect the user to a URL:

http://example.com/?foo={{system.munchkinId}}

and from this I'm getting:

http://example.com/?foo=&=&aliId=21#53;32-QQU-051

What appears to be happening is that the value of the token is using HTML escape codes (ampersand encoding), presumably to avoid script injection. Because of the #’s, the majority of the string is being interpreted as a hashtag in the URL (the alild parameter is part of the analytics tracking, as described here).

To make things even more complicated, when I try to use the token in the foliow-up URL in the form itself, the token isn’t even replaced, but when I put it in the follow-up URL on the landing page as I insert the form, the token is replaced and encoded as I have described.

When I use a custom token (e.g. {{my.Example Token}}) the value comes through unencoded (per this question), but unfortunately I need dynamic information that’s only available as either system tokens or lead tokens.

I also experience the same problem when I attempt to to put an HTML block on a landing page that could potentially act as a redirect. Example:

<script type=“text/javascript”>
window.location = “http://example.com/?foo={{system.munchkinId}}”;
</script>

Does anyone have any experience with this? Is there a way to specify if the value of a toke should be encoded?

[Anonymous]

Marketo, is there a way to avoid this odd encoding issue in the Follow-up page URL when the Form is submitted?  It doesn't seem to occur with Forms 1.0.

 

[Anonymous]

Hi Michael,

No, we never did get around the encoding issue directly.

I came up with a couple work arounds.

The first workaround I described in my previous response. We had a landing page that the lead was directed to after filling out the form. We used the tag in a script tag, in a JavaScript string, and then used JavaScript to decode the value and trigger the redirect.

With the advent of Forms 2.0 we were able to avoid using the follow up landing page entirely. Instead, we leveraged the onSuccess callback for the form:

<script>
function update_form_onsuccess() {
    var form = MktoForms2.getForm(1234);
    
    if(!form) {
        window.setTimeout(update_form_onsuccess, 100);
        return;
    }

    form.onSuccess(function(values, followUpUrl) {
        if(followUpUrl.indexOf('?') === -1) {
            window.location = followUpUrl + '?' /* extract needed info from values here */;
        } else {
            window.location = followUpUrl + '&' /* extract needed info from values here */;
        }
        return false;
    });
}

window.setTimeout(update_form_onsuccess, 100);
</script>

You'll notice in the above code that we have to leverage a repeated callback based on a timer in order to figure out when the Forms JavaScript API is initialized and ready (the API seems to be centered around embedding the form on your own page, not with manipulating the form on an existing landing page).

Once we've hacked our way into having access to the form, the onSuccess function gets passed the values that are available from the form submission. Not sure if your value would be available there, but if it is available when the landing page is rendered, you could use a combination of the two approaches I've described and render down the promo code in string as JavaScript variable, decode it in JavaScript, and then correctly append it in the onSuccess function.

The above code also uses 1234 for the id of the form. You will need to get the id for your form. The full details of this second approach are available here.

[Anonymous]

Hi Ryan,

Did you ever get this token in the follow up url working?

Wondering if anyone has a solution for hte following:

I have a Marketo form that populates one of the hidden fields (promocode) from the url parameter upon submission ie:
www.example.com/?promocode=SamplePromocode 

When the form submits, it follows up to a 3rd party application form, which we need to pass the promocode value to the followup URL, eg:
www.applicationform.com/?promocode=SamplePromocode


So in the form settings, I've set the form's follow up url using a token:
www.applicationform.com/?promocode={{lead.Promocode}}

But the redirect url that I get is:
www.applicationform.com/initiate.aspx?pcode=%7B%7Blead.FORM_Promocode%7D%7D&aliId=2882835

Can anyone throw any light on this?
Thanks in advance
Mike

[Anonymous]

Hey Raj,

Thanks for your feedback.

So what you are saying is that system tokens are encoded but custom tokens are not? When you say system tokens, do you mean all tokens that are built into Marketo, or do you mean those that are prefixed with "system" (i.e {{system.YYY}}).

You are correct in that if you have the raw value in code you can decode that value, however in my case I want to use the token as part of a URL and what's happening here is the generated URL has different semantics because of the enoding. Part of the token value ends up as a hashtag on the URL which I can't interpresent from the server side receiving the request.

Further, this is going beyond standard HTML encoding which normally would cover characters like &, <, > etc that would cause problems in HTML. The above string that has been encoded to the URL is '532-QQU-051', none of these characters would cause problems in HTML.

Can you comment at all about my experience about tokens being ignored when set in the follow up URL on the form, but respected in the follow up URL on the landing page?

As an aside, the encoded can also be decoded using JavaScript.

Using jQuery:

$("<some hidden element for decoding>").html("<encoded string>").text()

or with straight JavaScript:

document.getElementById("<id of element for decoding>").innerHtml = "<encoded string>"
var unencoded = document.getElementById("<id of element for decoding>").innerText

But again, this assumes that you can manipulate the value in code before it is used, whereas I would like to use it directy in the follow up URL without manipulation.

[Anonymous]

No, we always encode the system tokens.  It is relatively easy to extract the token value.  Here's java code to do so -

String realValue = org.apache.commons.lang.StringEscapeUtils.unescapeHtml(encodedValue);