Make your form embeds happier and more productive by loading from your LP domain (not //app-something.marketo.com)

Level 10 - Community Moderator

Update 2019-11-07: This tip must be paired with the HTML and JS hints in this newer post to fully avoid accidental blocking by Tracking Protection.

Buried in a bunch of my Nation responses is this ginormously important guideline: whenever possible, use your Marketo LP domain in your form embed code instead of the default //app-something.marketo.com.

 

That is, if the embed code in the Marketo UI is:

 

<script src="//app-sj01.marketo.com/js/forms2/js/forms2.min.js"></script>
<form id="mktoForm_999"></form>
<script>MktoForms2.loadForm("//app-sj01.marketo.com", "123-ABC-456", 999);</script>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

 

and your primary Marketo LP Domain (or a Domain Alias) is:

 

https://pages.example.com‍‍‍‍‍‍

 

then edit the embed code (after pasting on your external site) to be:

 

<script src="//pages.example.com/js/forms2/js/forms2.min.js"></script>
<form id="mktoForm_999"></form>
<script>MktoForms2.loadForm("//pages.example.com", "123-ABC-456", 999);</script>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

 

 

The only and I mean only reason to avoid this change is if your external site requires SSL (https:) but your Marketo subscription does not yet include Marketo's SSL add-on. (Built-in browser security won't allow forms to load if you're in this unfortunate situation.)

 

In all other cases, you can and should switch over. Like, yesterday. That includes (1) when your external domain and Marketo LP domain both run over SSL (best practice in 2019); (2) when neither uses SSL (eh, it works); and (3) when the external site doesn't, but the Marketo domain does use SSL (strange but possible).

 

What's this about?

It's about tracking protection. If someone browses your site using Firefox with TP turned on, or with Ghostery or a similar plugin, they will not be able to load forms from app-*.marketo.com, because they can't load anything from domains matching *.marketo.*.

 

It makes sense that Munchkin (from munchkin.marketo.net) would be blocked, of course. That's what anti-tracking features/plugins are designed to do. But forms can be thrown out with the bathwater, if you will.

 

Yes, it's not really fair for all that matters! because form submissions require deliberate user action, and they don't inherently “track” anything but the Filled Out Form activity itself (assuming Munchkin cookies are blocked and all existing cookies were deleted).

 

But it's something we have to live with: Munchkin is fairly described as a tracker, Munchkin comes from the domain marketo.something and the major marketo.{tld} domains are of course all owned by Marketo. So, fair or not, privacy wins out... even if that means forms leave a blank space on your page for some end users.

 

By loading from your Marketo LP domain instead, you fully comply with the anti-tracking plugin (since you aren't dropping any new cookies or logging any more pageviews/clicks with Munchkin blocked) but also allow forms to be seen and be filled out. So do it!

 

Why isn't it the default?

Because of the SSL exception described above. Apparently, the Embed Code textbox in the UI and the underlying domain setup can't communicate. So the LP domain can't safely be the default, as not everyone can use it.

 

We're in the process of getting SSL on our Marketo LPs, but not sure if it's ready

If you have a pending order with Marketo, you can quick-check the state of affairs (for the purposes of this blog post) by loading the Forms 2.0 forms2.min.js in your browser. Here's Firefox's way of saying your custom cert isn't installed yet:

pastedImage_12.png

8 Comments
Level 6 - Champion

Similarly -- If you're experiencing issues with "Fills Out Form" activities being logged in Marketo for some cookied users (a difficult problem to diagnose I know), this is the solution.

Weeks ago, our team was pulling our hair out trying to figure out why - when a certain sample of internal users - filled out any of our web forms, NO activity was logged in Marketo. Their user activity history had no record of the form fill.

Swapping out for subdomain.example.com instead of app-xxx.marketo.com resolved the issue permanently. This is now best practice for our team.

Kudos to Sanford Whiteman for helping me and my team diagnose our original issue and identify the solution!

Level 2 - Champion

This is really helpful, so glad that someone put this together, thank you! This was the solution that we had to use as well, for any of our forms to show up in the Brave browser.

Level 10 - Community Moderator

Yep, Brendan is even stricter than his former employer.

(In fairness, nobody I know tests officially against Brave.)

Would hosting the forms2.min.js file on your external https website work? and change the embed code to this:

  1. <script src="//myhttpswebsite.com/forms2.min.js"></script> 
  2. <form id="mktoForm_999"></form> 
  3. <script>MktoForms2.loadForm("//myhttpswebsite.com", "123-ABC-456", 999);</script>
Level 10 - Community Moderator

Would hosting the forms2.min.js file on your external https website work? and change the embed code to this:

  1. <script src="//myhttpswebsite.com/forms2.min.js"></script>
  2. <form id="mktoForm_999"></form>
  3. <script>MktoForms2.loadForm("//myhttpswebsite.com", "123-ABC-456", 999);</script>

Not alone, you'd have to make several other config changes as well, and you wouldn't get fixes to the library. Wouldn't recommend this.

Level 6

Hey @SanfordWhiteman , thanks again for yet another useful post. But, the top link around "HTML and JS tips in this newer post" seems to be broken - it takes me to the homepage. Could you update the link?

 

Thanks! 

Level 10 - Community Moderator

Thanks, must've been lost in the forum changeover. It's supposed be to https://nation.marketo.com/t5/Product-Blogs/Really-finally-winning-the-Marketo-Forms-vs-Tracking-Pro...

Level 6

Thank you kindly!