Is there a way to suppress Branded Domain urls from being added to email links?

[Mark_Kalamaridi]

Hi. Is there any way to suppress the Branded Domain url from being added to email links when sent out?

I tried adding "mktNoTrack" and "mktNoTok" to the <a> tag and didn't work.

#It's causing a click-to-call link to redirect to a new page.

[SanfordWhiteman]

You're doing the right thing. (You only need class="mktNoTrack" however.)

Are you sure you've approved the email?

Can you show the HTML for your <a> tag? (Syntax highlighted please.)

[Mark_Kalamaridi]

Hi Sanford

Thanks for the quick response.

Here is the HTML. Email was approved

<a class="click-to-call mktNoTrack" href="tel:+18777525933" style="text-decoration:none; outline:none; color:#52227d; display:none;"><strong>1-877-752-5933 (press 2)</strong></a>‍‍‍

[SanfordWhiteman]

Can you take out the click-to-call class and try it again?

[Mark_Kalamaridi]

Hi. Removing the click-to-call class didn't work. The phone# didn't link out at all.

[SanfordWhiteman]

Something's not adding up here. The CSS class has nothing to do with the link opening the telephone app: that's entirely dictated by the tel: protocol.

Why do you have display: none on that link?

What is the final HTML in your email client (not in Preview or w/Send Sample but a real email)?

[Mark_Kalamaridi]

The CSS class was being used to suppress the phone link in non-mobile clients through a media query. Thus the display:none in the link. There is a second non-link phone # displayed for non-mobile.

What I think is happening is the clients I am testing with (Gmail and Yahoo Mail mobile apps) don't support the tel: protocol and the link conversion to the Branded Domain url is enabling the link since it redirects to a webpage. So natively it won't work on these clients. Other mobile clients such as Samsung Mail it works. To make things even more confusing, if I remove the tel: link and leave as just text. The Yahoo Mail app converts the text phone number to a link that does work correctly.

[SanfordWhiteman · Accepted solution]

The CSS class was being used to suppress the phone link in non-mobile clients through a media query. Thus the display:none in the link.

Then that would explain why you didn't see the link when you removed the special CSS class that happened to control the display: style in your email. But it doesn't have to do with the rendering of the href itself. I was asking you to remove that class to ensure that Marketo sees its mktNoTrack first. (Note that the DOM parser used on the back end is not as sophisticated as a modern browser parser.)

There's only one link sent from Marketo. So even if a browser/device combo doesnt support tel: they will still have the same link, it won't change to an http: tracked link on the fly on the browser side.

Bottom line, the mktNoTrack CSS class changes -- or should be changing -- the link to an untracked link for all recipients.

Here's another way to create an untracked link: put the entire URL (including tel: protocol) in a Text {{my.token}}.

[Mark_Kalamaridi]

I removed the "display:none" from the tag along with the custom class, so the tel: link was rendering in the email. Having the custom class before the "mktNoTrack" class was the problem. So like you mentioned, the same tel: link was getting sent out without tracking which is what I was looking for. 

But I noticed that the tel: link in Yahoo Mail mobile app wasn't clickable. Other clients such as Samsung Mail it did work.

When I removed the tel: link and kept the phone # as just html text, the Yahoo app converted the # to a link that works for the app. I'll just need to find a workaround to deliver in text format for this particular client.

Also, thanks for the token idea. I may try that.

[SanfordWhiteman]

Yep, it makes sense (given past experience) that the Marketo-specific class needs to come first. It's not so much a CSS class (i.e. =~-compatible list of strings) in this context, more like a single string.

When I removed the tel: link and kept the phone # as just html text, the Yahoo app converted the # to a link that works for the app. I'll just need to find a workaround to deliver in text format for this particular client.

Strange/interesting break in that client! Is that on both Android and iOS?

Also, thanks for the token idea. I may try that.

It might be confusing if you did it for this one goal (someone else looking at your tokens might think you accidentally included the protocol). Would only do it if there were no other choice.