iframe forms into Wordpress?

[SanfordWhiteman]

In order for the 'fills out form' trigger to be 'functional' I would say it needs to be able to allow me to add a constraint about the web page the form is filled out on.

With embedded forms, you constrain the Fills Out Form trigger by the Referrer not by Web Page.  In much the same way that an IFRAME's document.referrer is its parent document's href, the Referrer of an embedded form is the page that hosts the form object. It is functional!

P.S. This intersects with a feature natively supported w/embedded forms that needs to be adapted for IFRAMEd forms: autofilling hidden fields.  Autofilling from referrer params wll not work automatically; query params on the host document become referrer params on the IFRAMEd form. You can use simple code to copy the desired data onto the IFRAME's src and treat it all as query params.  There's also autofill from cookies: this will work seamlessly if the domains share an SLD but otherwise has to be shimmed in via src or other means.  These gaps can all be filled but it's not plug-and-play.

[Grégoire_Miche2]

Hi Christina,

amongst other things, iFrame are not recommended because (non limitative list) :

• They are slow
• They are very difficult to adapt to responsive design
• They look bad for search engines
• They will provide 2 page views instead of 1 (one for the page, one for the embedded page) and temper the scoring
• ...

-Greg

[SanfordWhiteman]

Wowzers, that is super-inaccurate. Pierce Ujjainwalla​ Jason Hamilton you should fix that up!

[Pierce_Ujjainw3]

We apologize that we overlooked 1 item on this infographic that was made over 2 years ago - but we'll make sure that we fix it up so everyone can make the right decision on their Marketo form implementation.

[Pierce_Ujjainw3]

Coming in on this late - let me add my two cents:

Personally, what I find important when it comes to Marketo forms is getting a high conversion rate and tracking my conversion. Form embeds don't prefill data (lowering conversion rates) and don't allow you to track said conversion rates.

With a little bit of coding and CSS knowledge it is easy to make iFramed Marketo forms responsive and styled to match your parent page. Marketo's form embed has some big gaps, so we never recommend it to any of our clients.

We built this table because we could not find this information anywhere, including from Marketo. At the time we built this, almost 2 years ago, we built this to the best information at the time. We can certainly update it with any new functionality that was not present at the time of publishing, but our recommendations will stay the same, if you are not using Marketo landing pages with Marketo forms, you should iFrame Marketo forms onto your page.

I don't like using the hide form option since it typically leaves you with major data quality problems. For example, lets say your first form that someone fills out only requires email address - well guess what, you start using the 'hide form' and you're never getting more information from your prospects.

For this reason, I continue to stand behind iFraming Marketo forms into non-Marketo pages.

[Kenny_Elkington]

My advice would be to avoid the use of iframed forms.  They are generally more difficult to make look nice, and offer nothing over the standard form embed code other than form prefill.  You can find the normal embed code by following these directions: Embed a Form on Your Website - Marketo Docs - Product Docs

[Pierce_Ujjainw3]

Hey Kenny,

Other than styling, which will require coding regardless of if its in an iFrame or not to truly match the parent page exactly, what is the hesitation to the iFrame method? I am curious...

Prefill is a pretty major feature requirement for forms IMO, and the fact that you cannot use the webpage constraint on the fills out form trigger will have some big implications to the setup of forms and number of forms required in Marketo.

[SanfordWhiteman]

Prefill is a pretty major feature requirement for forms IMO

For some, yes. In many cases, for legal reasons, it's strictly forbidden, so it isn't missed!

Nevertheless since last August I've been mentioning that I developed a cool workaround, which I even demoed at our local MUG.  Almost no one has pinged me back to show interest. This leads me to think it isn't really as major as it seems (I've responded on threads that were opened to complain about it and the OP hasn't contacted me!).

I'm sure people underestimate the inherent security risks (which my workaround doesn't share) if embedded forms were only tweaked to enable prefill (as in: that's the only change made to the code).  Let's see how awesome that would be for the owner of Malice, Inc:

• add YourCo's Munchkin code, generating a fresh 1st-party cookie
• get the lead's email address with a friendly form
• post the form to YourCo's Marketo instance, associating the cookie
• embed one of YourCo's forms, hidden of course, and grab any prefilled fields
• post the prefilled fields to Malice's db

Granted, this process can be simulated now with the assistance of server-side code (which is kind of why prefill makes me feel icky even now).  But being able to do this solely client-side makes this abuse much harder to catch.  You're essentially having leads hack themselves: all the actions are originating from the lead's machine, as opposed to from an intermediate server.  Of course there's still a server out there collecting the data, but that could be just putting stuff on a DMCA-protected Pastebin type site.

So you need to do more than simply letting lead data flow offsite, you need measures like origin verification against a user-maintained list of allowed domains (the same thing that could be done with Munchkin, but hasn't yet).

But before "prefill everywhere," what I'd rather have is the option for more secure self-service.  A passcode -- maybe just a 4-digit PIN, we don't need to approach this with ultimate seriousness, and anything is better than nothing -- required for reads and writes, and email confirmation before a lead is activated.  I know for most marketers this would seem punitive, but I also come from the financial sector where even salespeople get creeped out by unauthenticated self-service. The counterargument is made that if the data is considered updateable by the lead, by definition it isn't a corporate secret.  That's true: if I let somebody view and modify "their" age and annual income, it's not like I'm leaking the lead scoring that goes along with that.  But unless you make sure that you never prefill any PII, you're leaking a combination of data that a lot of malicious people would loooove to get their hands on.

[Pierce_Ujjainw3]

You have legal requirements not to prefill information? Not sure I see the correlation to we're talking about here. There are many other ways to satisfy that requirement... and legal almost always ruins a good user experience!

[SanfordWhiteman]

I have clients in many industries, from highly regulated (finance) to largely unfettered (book publishing). And I see a wide range of reactions to form prefill, from "it's cool" to "kill it with fire."  I'm illustrating that prefill as a "major" feature requirement for forms is not universal and that those "kill it with fire" reactions could explain the low interest I've seen in my workaround.