Google Analytics vs. MKTO Tracking

[SanfordWhiteman]

If your tracked links work at all, it's very unlikely that you have anything wrong with your branding domain.

What I'd like to see and don't see explicitly in this thread (I can't watch the ScreenCast as it reqs Flash) is exactly how this URL appears once rewritten to go to the branding domain, i.e. go.example.com/294hdueidk83jduwhdhj8383....

[Anonymous]

When I apply this link
https://www.halocigs.com/?utm_source=inhouse&utm_medium=email&utm_campaign=2017halohumpday&utm_term=...​

and turn on the MKTO tracking and I send myself a test email and click on the link, this happens:

(Please see this image not video): https://www.screencast.com/t/1FJy8Rnd​

I hope this clears up any confusion?

[Anonymous]

I just checked the branding domain (em.halocigs.com) and everything appears to be good there. You can check this at https://mxtoolbox.com/SuperTool.aspx?action=mx%3aem.halocigs.com&run=toolpage​. That means we should be able to rule that out as a potential cause.

I did notice that when I visit your page using the native link with the UTM parameters, the page appears to redirect, stripping the UTM parameters from the URL. Do you have some sort of a site redirect going on for home page visits that have URM parameters?

[Anonymous]

Its not a redirect. After the page loads we use javascript code to strip the UTM parameters from the URL.

[Anonymous]

This javascript is likely the culprit then. I've seen this exact issue happen with redirects as well. It's possible that your javascript is interfering with the page loading properly. I would recommend creating a test page without the javascript and seeing if you get the same error. If you don't get the same error, there's your culprit.

[SanfordWhiteman]

No, that's not it. It's not JS-related, GA-related nor even directly Marketo-related.

Angel​ the problem is you have HSTS enabled on your main domain (www.halocigs.com) and that site's webmaster​ has unfortunately forced SSL connections for all subdomains of halocigs.com.

This was a really poorly thought out move, because em.halocigs.com is such a subdomain, yet you don't -- though you certainly may, and IMO should -- have an SSL cert on your Marketo-hosted site(s).

Thus your branding domain doesn't support SSL, but anyone who visits your main domain is told that they may only connect over SSL to that same domain. This is a clear conflict, and HSTS always wins in this situation. So the browser throws an error.

[SanfordWhiteman]

I just checked the branding domain (em.halocigs.com) and everything appears to be good there. You can check this at https://mxtoolbox.com/SuperTool.aspx?action=mx%3aem.halocigs.com&run=toolpage. That means we should be able to rule that out as a potential cause.

Looking up the MX record for a hostname doesn't shed light on the web side, actually.

And in this case, the lookup in MX Toolbox isn't successful from an MX perspective.  It shows the domain is an alias -- as required for Market-hosted branding domains -- and can't appear as the label of an MX record for exactly that reason.

A successful MX lookup and a successful CNAME lookup are basically mutually exclusive for today's purposes.

In general (outside of Marketo's environs) an MX lookup doesn't say anything about whether a hostname is set up correctly to receive web traffic. If I have an MX record for www.example.com that doesn't mean http​://www.example.com will work, let alone http​s://www.example.com.

[SanfordWhiteman]

Like I said, can't watch the video. Please post the rewritten URL here.

[Anonymous]

Its not a video, its an image.

[SanfordWhiteman]

I need the text here, on the thread, to test. An image just means I need to transcribe it.