Malformed links?

[Cahan]

I have a malformed link in my Newsletter Link Performance report, http://${CTA-url}. When I read this (https://nation.marketo.com/t5/Knowledgebase/What-is-a-malformed-link-in-my-report/ta-p/249063#:~:tex...) explanation about malformed links, from what I understand it is due to the receiver’s email set-up, which makes it not able to trace what was clicked on. Therefore I would think that all links clicked on by that receiver would show up as malformed? However from a report that shows which links contacts have clicked on, there a several contacts that have clicked on the malformed link, but where I can also see what else they have clicked on. Like in below example.

Malformed link

[Michael_Florin]

I don't believe you're on the right track here. ${CTA-url} looks very much like a Velocity variable, defined in an email script token.

And to quote the master:

"When you use Velocity tokens, output the entire <a> tag including the closing </a> from Velocity."

Search for "velocity links" or "velocity link tracking" to get the full story.

[Casey_Grimes]

Hi Cahan,

This actually isn't a malformed link, but instead a specific setup issue: when you create an email template and choose to use variables for links (such as the CTA link) in editable areas, some problems can occur—while the majority of email clients will receive the email with the properly formed link (so http://${CTA-url} is a real link in the email), but not all. Additional issues can come up when you use both the link and the link name as variables, notably in Office 365.

I'm at the point where between the lack of copying to text versions of emails, the breaking in Office 365, and the issues it causes in links for Smart Lists/reports that I can no longer recommend anyone use this technique for links in emails. You'll need to restructure your email template so the user has to add the link in themselves.

[SanfordWhiteman]

Can you say more about the outcome in Office 365?

[Casey_Grimes]

Of course. 365 and Outlook.com are pretty fussy about links in general—in fact, if you've ever tried to do something like

<a href="">Test 1</a> or <a href="#">Test 2</a>

this used to fail and make links break up until recently. I even wound up just switching to using "#tbd" in order to get around this problem when I didn't know what a link was going to be. Basically, if the software can't understand that the link is in fact a link, it errors out and shows the end user bracketing similar to the following:

In the case of that screenshot, the link is wrapped in something very similar to

<a href="https://${ctaLink}">${ctaText}</a>

So, it was just the straw that broke the camel's back on this method for me.

[SanfordWhiteman]

So is it more the annoyance in testing when you haven't yet set the variable?

[Casey_Grimes]

Not necessarily--in this case, the variable has been set, and it's showing that to the end user. You just more typically run across 365 doing this when there's nothing set in the link.

[SanfordWhiteman]

But the final rendered HTML should be the same whether you hard-code it or it comes from the variable (provided the variable is set to the same value).  Not seeing how the value originating from a variable has a bearing on the rendering... can you show a comparison btwn. the template HTML and the final HTML?