Re: Forms 2.0 and Not Rendering with Embed

SanfordWhiteman
Level 10 - Community Moderator

Re: Forms 2.0 and Not Rendering with Embed

What's the URL?

Justin_Cooperm2
Level 10

Re: Forms 2.0 and Not Rendering with Embed

One of our engineers has seen this with a few customers in the past. Here is some guidance:

*.marketo.com urls are often blocked by spam filters / adblock etc, because they (correctly) identify what marketo does as tracking.  This has happened for a long time with certain adblockers we've came across, and it seems like maybe some firewalls are now doing it too.

The easiest/best workaround is to change those urls to your CNAME instead.  For instance if your CNAME was go.company.com, the original embed script:

<script src="//app-aba.marketo.com/js/forms2/js/forms2.min.js"></script>

<form id="mktoForm_1"></form>

<script>MktoForms2.loadForm("//app-aba.marketo.com", "XXX-XXX-XXX", 1);</script>

Would become:

<script src="http://go.company.com/js/forms2/js/forms2.min.js"></script>

<form id="mktoForm_1"></form>

<script>MktoForms2.loadForm("http://go.company.com", "XXX-XXX-XXX", 1);</script>

This has the advantage that your domain will not be filtered out by things that are filtering out Marketo includes. It does have the disadvantage that it does not use a CDN to serve the JS assets, so it can potentially be slower to load.  Another disadvantage is that you may not have a https cert for your CNAME, in which case the embed script wouldn't work on https pages.

SanfordWhiteman
Level 10 - Community Moderator

Re: Forms 2.0 and Not Rendering with Embed

If you look at the AdBlock Easy Privacy List, you'll see mktoresp.com but not marketo.com.

I'd venture that if someone is trying to block marketo.com via privacy plug-ins or proxies, it isn't because they think the form post itself is bad, but because they consider Marketo bad guys in general (because of Mkto's separate use of tracking pixels and/or as an ESP).  Any attempt to evade that technology is counter to the user's (or IT group's) wishes and IMO ethically questionable.

Perhaps just as important, as Justin notes, using the CNAME will be way slower to load.  It's already hard enough to handle form posts and *.mktoresp.com Munchkin hits internationally; if you can't even load the core scripts via CDN you're going to feel that hit.  So I think the wider solution, leaving aside ethics concerns, is either to [a] steer go.company.com through your own CDN or [b] fall back to the CNAME only if forms2.js didn't load.  Easy to check for the existence of the MktoForms2 ​object and retry w/CNAME if it's not found.