Tokenized URL in Email

[Hank_Hansen]

I've read a number of tokenizing articles but couldn't find the answer to this question. I'd like to tokenize the URL for links within emails but have the flexibility of showing different link text. I therefore don't want to tokenize the link text and the URL - I only want to tokenize the URL. How do I do this?

[Grégoire_Miche2 · Accepted solution]

<a href="{{token here}}">your text here</a>

You can use a lead, account or my (program) token.

-Greg

[Hank_Hansen]

Great - thanks. It would be nice if a token selector was an user-preference option provided for the URL field in the V1 email editor.

[Grégoire_Miche2]

Hi Hank,

in fact, if it is in an email and you want the clicks to be tracked in the link, make it:

<a href="http:://{{token here}}">your text</a>

and strip the "http://" from the token value.

-Greg

[Hank_Hansen]

Got it - thanks!

[Lucas_Metherall]

What about adding a person's name token into a URL?

Our donation page can listen for ?firstname=, and then insert that value onto the page.

We use a custom field {{lead.wap_alias name}} as our preferred salutation, could i create a URL with

https://www.a.b.com?firstname={{lead.wap_alias name}} and the URL would then take that value to the donation page?

[SanfordWhiteman]

If you are sure (100% sure, which is rare) that the value will not include any characters that need to be escaped in a URL, then yes.

Otherwise, you must use Velocity to construct the link, as VTL can escape the field.

[Lucas_Metherall]

By escaped do you mean the example I experienced when I wanted to insert a dollar value into a token but ${{lead.details}} did not work?

Is there a short list of characters I can check against in the intended email audience?

[SanfordWhiteman]

There are 2 different types of restrictions, and both are always in effect.

(1) The only characters allowed in a URL at all are

uppercase A-Z

lowercase a-z

numbers 0-9

and the symbols - . _ ~ : / ? # [ ] @ ! $ & ' ( ) * + , ; =

All other characters must be URL-encoded (a.k.a. percent-encoded). For example, double-quote " must be %22. Curly apostrophe ’ must be %E2%80%99.

(2) Even the symbols in (1) that are generally allowed are must be URL-encoded when they would otherwise have a special meaning in a URL. For example, plain ampersand & is allowed in general. But it also is used to separate query parameters. So if a query param (name or value) includes &, it must be encoded as %26.

If it seems like I'm trying to scare you... I am! It's exceedingly rare to be able to guarantee that user-supplied data will not need to be encoded.

Even a seeming exception like Phone cannot be trusted in reality, unless it's already been sanitized to not contain a + sign. Email addresses cannot be trusted because they may contain several characters, however basic, that need to be encoded.

And that's before we even get to non-ASCII characters. Unless you're dealing with an audience that can be guaranteed to not have any accented Latin-1 characters in their first or last names, let alone any non-Latin-1 characters — and can't think of any country where that's true — you can't just send the native value in a URL.

You can see why it's so rare to actually be able to guarantee that you won't need escaping.

[Lucas_Metherall]

Thanks Sanford, let's pump the brakes on that little project.