During one of my sessions at Marketo Summit, it was mentioned that the new GCP Platform introduced a new SSL product just in time for GDPR Compliance and Chrome 68 warning users of non-HTTPS sites. During that session it was mentioned that, at that time, the email editor was not ready to automatically convert HTTPS links to the tracking domain. This meant that token links that use HTTPS would not get converted to tracking links.
Doing some further research, I found a few instances of Marketo Nation threads that detail exactly that:
The Editor looks for HTML code that matches href=”http:// to automatically convert links not created by the WYSIWYG editor (I.E., links in Tokens). If a token value for a link uses https://, it will not be recognized automatically and thus, not get converted to a tracking link.
HOWEVER, in my recent testing, this has not been the case. Inserted HTTPS links into our tokens are in fact getting converted to tracking links.
Am I missing something? Was an update done to the email editor to allow this to work, or does my scenario not apply to the href=”http:// restriction?
Solved! Go to Solution.
I think the information was poorly communicated.
There has been a restriction that even if you had an SSL cert on your tracking domain (call it https://go.example.com) the links would be rewritten to http://go.example.com instead. HSTS could then take care of redirecting people from the http:// site to the https:// site, but that's not as secure (a first-time connection can be intercepted in that case).
In other words, this didn't have to do with the protocol of the original link target but the protocol of the rewritten link.
I think the information was poorly communicated.
There has been a restriction that even if you had an SSL cert on your tracking domain (call it https://go.example.com) the links would be rewritten to http://go.example.com instead. HSTS could then take care of redirecting people from the http:// site to the https:// site, but that's not as secure (a first-time connection can be intercepted in that case).
In other words, this didn't have to do with the protocol of the original link target but the protocol of the rewritten link.
I understand, I must have misunderstood the original conversation then.
If I implement an SSL on my landing pages subdomain, I can use the https links for my landing pages in tokens or the WYSIWYG and they will get converted to http://tracking.domain.com.
If I implement an SSL on the tracking subdomain, the email editor will only convert to http://tracking.domain.com, instead of https://tracking.domain.com. Having HSTS implemented at the domain level will resolve this for users after the initial request from a browser.
Follow up question for you:
I do see some forum threads that talk about the structure for using token based links, like this thread:
How to Track Tokenized Links in Email Assets
&&
Can you use URLs in Tokens? YES - here's how.
Currently, my templates are following the the "Bad" Example in the second link by having the entire URL be placed in the token instead of the URN, and yet mine are working just fine and getting converted to tracking links.
Could this "bad" example only refer to Marketo variables from outside the email scope, or has this issue been resolved?
Currently, my templates are following the the "Bad" Example in the second link by having the entire URL be placed in the token instead of the URN, and yet mine are working just fine and getting converted to tracking links.
Could this "bad" example only refer to Marketo variables from outside the email scope, or has this issue been resolved?
This has traditionally been a global restriction (not, it should be noted, on variables but on tokens). Not aware of it having changed, in fact quite recently there was a thread here where someone was doing it the "bad" way and needed to fix it up.
There is an exception: when you use a Velocity token, you should output the entire <a> tag (not just the path/page/querystring, nor the full href including the protocol, but the entire <a> including closing </a> and inner content).
I use the bullet proof buttons, and implemented your advice from a previous post about changing the <v:rect> elements to <a:rect> to ensure they get picked up automatically.
<code>
<!--[if mso]>
<a:rect xmlns:a="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word" href="${primarytextbutton_button_link}" style="height:50px;v-text-anchor:middle;width:${primarytextbutton_button_width}px;" arcsize="16%" strokecolor="${primarytextbutton_button_color}" fill="t">
<a:fill type="tile" color="${primarytextbutton_button_color}"/>
<w:anchorlock/>
<center style="color:#ffffff;font-family:Arial, sans-serif;font-size:14px;font-weight:bold;">${primarytextbutton_button_text}</center>
</a:rect>
<div style="width:0px; height:0px; overflow:hidden; display:none; visibility:hidden; mso-hide:all;">
<![endif]-->
<div style="margin: 0 auto;mso-hide:all;">
<table align="center" cellpadding="0" cellspacing="0" height="50" width="${primarytextbutton_button_width}" style="line-height:50px; margin:0 auto; mso-hide:all;">
<tbody>
<tr>
<td align="center" valign="middle" bgcolor="${primarytextbutton_button_color}" height="50" style="vertical-align:middle;color: #ffffff; display: block;background-color:${primarytextbutton_button_color};border:1px solid ${primarytextbutton_button_color};mso-hide:all;" width="${primarytextbutton_button_width}">
<a class="cta_button" href="${primarytextbutton_button_link}" style="font-size:16px;-webkit-text-size-adjust:none; font-weight: bold; font-family:sans-serif; text-decoration: none; line-height:50px; width:${primarytextbutton_button_width}px; display:inline-block;" title="${primarytextbutton_button_text}">
<span style="font-family: Arial, sans-serif; font-size:16px; color:#ffffff">${primarytextbutton_button_text}</span>
</a>
</td>
</tr>
</tbody>
</table>
</div>
</code>
All of the href instances explicitly use href="${token_button_link}" which should be the "Bad" Example and not get picked up and converted.
BUT, when they come through via email, both Outlook and other clients receive a http://tracking.domain.com link.
Truly weird! Hoping this isn't a fluke and that these buttons start failing to get tracking links later on.
My original questions has been, answered, thanks for your help Sanford!
Those are variables, not tokens, though. So that doesn't have the restriction (different order-of-operations).
My original questions has been, answered, thanks for your help Sanford!
Cool, mark my first answer as Correct, thanks!