Hi - I am reaching out to the Marketo Community because my team has been experiencing an issue with email tracking and page load errors for weeks.
When the radio button to "Track Link" is selected for links in any email, clicking on the live OR test email link causes this message to appear in Google Chrome, regardless of the page the link directs to -- I've redacted my company name and URLs in the image below to preserve some privacy:
I simply want to know if anyone else is experiencing this issue or if it's happening because of firewalls/proxy settings of the email recipient? This is happening to our team internally, so I am assuming it's happening to external folks who get our marketing emails.
To give you an idea of the scale of the issue, Marketo is telling me 80+ people clicked on a link in my email but Google Analytics is telling me 24 people hit the page. This is a major disparity, so I need to understand why this is happening. And, if the issue is proxy settings and firewalls, is the only solution to remove tracking , and thus lose the data on email link performance?
Any help the community can provide is greatly appreciated.
Solved! Go to Solution.
Okay - understood.... So in theory, if I have an old cached HSTS entry and I cannot reach the page, it's likely that others receiving my email also cannot reach the page?
It's hard to say if others are affected. Best case scenario: your IT department accidentally had an includeSubDomains policy in place for a very short while, say an hour, before they realized their mistake. Internal users were more likely to be affected in the normal course of work; real world users would only have been affected if they visited the main site during that period.
Not-best case: the policy was out in the wild for a week. That naturally would affect exponentially more people, who will have the cached bad entry.
The current HSTS header is not a problem. The question is how long the old HSTS header was out there for people to cache. If it was out there for a long time and thousands of high-value leads can't click your emails, then you're going to have to add SSL to your Marketo account, there's no way to "fix" it.
Hi @Jackie_Mccarthy ,
It seems the issue is not related to the mkt_tok parameter, it is related to using non secure email domain for Marketo.
The screenshot you shared is having the url in https (secure), but seems your email domain is non-secure, but when Marketo converts the url into a tracking url, the secure url converts into a non-existent secure email tracking url.
Now when any user try to open the converted non-secure link from their email, due to strict browser security policy the non-existent secure url created by Marketo won't open and throws the error you see.
1) Purchase secure email domain package from Marketo (recommended)
2) Don't convert the links to be a tracking url
Arun, I don't think you can say for sure that this is HSTS-related because you don't know the actual domain(s) in question.
If the branding domain is email.info.boardex.com then there's no parent or local HSTS policy governing that domain.
Furthermore, even if HSTS were forcing a connection over SSL, you wouldn't see a Connection Refused error: email.info.boardex.com does support SSL, but the cert (for *.marketo.com) doesn't have a matching hostname, which is a different error.
Hi everyone - My apologies for a delayed reply on this.
Here are the links:
This is the link I am trying to send individuals to:
But when the link is clicked, it does pass through email.info.boardex.com before going directly to the page.
So would it then make sense that @Arun_Sharma9 's response is plausible?
Please let me know what you all think. I really appreciate your help on this.
We need the URL that Marketo renders in the real email when you put that URL in the email editor w/tracking enabled. (That is, the link that goes to your branding domain.)
OK. Nothing's wrong with that link and HSTS doesn't apply. See this batch of screenshots: https://app.crossbrowsertesting.com/public/i75b45d927357249/screenshots/z6eb732aed282246a7c1
Are you able to reproduce the behavior only when behind, for example, your corporate firewall?