5 Replies Latest reply on Jul 13, 2016 1:32 PM by Sanford Whiteman

    Firewalls blocking pages with Marketo tracking code

    Natali Talevski

      Hi all,


      Does anyone else have issues with firewalls blocking access to webpages that have come from Marketo emails? When some recipients click through on the Marketo link (complete with tracking code) they get an error saying the page is blocked. Yet when they go to the page directly, it works fine.


      Any reason the tracking might be doing this? Is there a way around it other than removing the tracking (which I don't want to do as I want to see who clicks on what).





        • Re: Firewalls blocking pages with Marketo tracking code
          Sanford Whiteman

          If you are using a custom branding domain CNAME (i.e. go.example.com) pointing to your mkto-* host (i.e. mkto-sj010203.com) then you are doing almost everything you can to combat detection by an aggressive outbound web filter. If the filter has mkto-*.com on a blacklist then it's trivial for the filter to determine that's where your links are going.


          I say "almost everything" above because you could run your Marketo tracking domain in such a way that the web filters would never see mkto-*.com -- so they'd be unable to block based on that match.  However, whether such an approach is ethical, or even legal, is debatable if you know the web filter is trying to block connections to Marketo click tracking. In other words, if you felt that mkto-*.com was mistakenly blacklisted according to the known policies of the firm, that's one thing, but if you admit they're following an explicit anti-Marketo and/or anti-click-tracking policy and you try to subvert it, that's problematic.


          I would be curious about the exact error/reason given by the web filter.  If the reason is "we do not support click tracking redirectors" or "we hate Marketo users" it's accurately blocking your tracking domain and you have to let it ride.  But if the reason (however unlikely) is "we do not support JavaScript redirectors" then you can get around that without being unethical. Or if the reason is actually "go.example.com is seen as a malware host" or "go.example.com is inappropriate for business-day browsing" (assuming you are a legit B2B company) those would also be worthy of proactive measures (in these cases, temporarily changing your tracking domain would be a reasonable test).


          Really like to know the explicit reason given by the filter.


          Oh, and something else: if the filter doesn't block Munchkin tracking from running on the destination page (would be pretty weird to let Munchkin go if they have a general anti-tracking policy, but could be) then you could skip over Clicked Link in Email tracking, which does not use Munchkin, and still get pretty good coverage via the Munchkin events (Visit Web Page and Clicked Link on Web Page) by including the lead identifier in the query string.  This will of course not work for any assets that can only be tracked via the tracking server, like PDFs.

          1 of 1 people found this helpful