Marketo Forms - Which application is right for you?

[Pierce_Ujjainw3]

One of the biggest questions that we hear from our clients is how they should integrate Marketo forms onto their website.  There are several different options on how to do this, and each one of them has their own pros and cons. This post will focus on each option, so that you can make an informed decision on which one is best for you.

Marketo Landing Page + Form

What I really like about Marketo’s landing page editor is it enables Marketers who may not have HTML experience to be able to quickly and easily setup a landing page for their program. Some of you will be able to relate to this next comment, and those are the ones I would especially encourage to go the route of Marketo landing pages: no more waiting weeks for your web team to create a landing page for you, and then days for them to make edits once you’ve seen it live. I personally find that Marketo Landing Pages are the best option for any pages that require a form. They give you the most flexibility and control to do what you need to as a Marketer to succeed. They also give you the most benefits, like form pre-fill, conversion rate statistics and make it easy to integrate into scoring and triggers.

Marketo Form Embedded into iFrame

Now for some of you who have really great and responsive web teams, or who are running websites using WordPress or another user friendly CMS, sometimes this option can be just as good as Option #1. You don’t really lose a lot by using Marketo forms in an iFrame, other than A/B testing of your landing pages. So, you if have an awesome landing page that is optimized for conversion and its built in WordPress, then put a Marketo form onto this page using an iFrame and you’re good to go. There are a few customizations that you will need to make to make it responsive, blend into the parent page and open the follow-up page in a new window, but you can have Marketo forms up and running on your site in no-time.

Marketo Form Embedded using Embed Code

A lot of people, especially developers, were excited when the embed code came out as it made for an ‘easy’ way to post your Marketo forms directly into an existing webpage on your website. Although it makes the integration into your existing site fairly straightforward, it comes with several drawbacks. This includes the fact that your forms will not pre-fill with known prospects data, it is impossible to track conversion rates of your forms and equally as hard to track form submissions via smart lists. Until Marketo resolves these issues, I would not advise going down this path, even if it may make implementation easy.

Non-Marketo Forms Using Marketo APIs

Marketo has a number of API’s that can be used to either call or post data from. I have worked with some clients who will use these APIs to send data to Marketo when their non-Marketo form is submitted. This typically happens when there is another back-end system linked to the form that needs to spin up a trial account or send a confirmation email with third-party information. This can almost always be done using native Marketo forms and with the API’s pushing to these other systems instead of vice versa. Although the APIs are typically an option that are most sought-after when technical people are involved in the discussion, most of the time native Marketo forms with API’s calling information back and forth in the background can be used. Again, I typically do not advise using the APIs unless there is no other way to achieve the results required with native Marketo forms (and there is almost always a way).

Non-Marketo Forms

It’s one thing to use non-Marketo forms and then use API’s to send data into Marketo, and then it is completely another question when there is no communication method into Marketo. One client we work with did not want to use Marketo forms in case the Marketo servers went down or if they ever had to switch to another Marketing Automation vendor. However, they made sure that all data coming through their forms was passed over to Marketo via API’s and clearly indicated the source of all leads. They also integrated the munchkin API into their forms so even the non-Marketo forms could pre-fill and we could grab all the inferred information. Unless you are taking your non-Marketo forms to these lengths, then I would not suggest using non-Marketo forms. It is a lot of extra work just to get them up to parity.

Salesforce Web-to-Lead Forms

Please, just please do not do this. I have yet to encounter a good use-case for this. This is a recipe for creating a lot of duplicates and losing out on all of the great benefits that come from Marketo forms.

Here is a handy cheat sheet that you can use when thinking about which option to select:

[SanfordWhiteman]

Several of those checkboxes weren't really accurate (it's not that they've been fixed, they weren't accurate at the time of posting). Unfortunately, the post wasn't updated, although there are many, many Community discussions that explain the available functionality.

"Hide form if known visitor" (Known Lead HTML) and "Use fills out form trigger, filter" in fact are usable with embedded forms.

The major difference in functionality is Form PreFill is not natively supported with embedded forms, though I have workarounds for that.

I don't consider conversion and A/B testing to be things that are missing from embedded forms because those are actually properties of the landing page, and by definition you're using another LP platform.

[Pierce_Ujjainw3]

We just updated the infographic - sorry it took so long. Was tough to find a file from so long ago.

In going through this again we originally had that you could do progressive profiling with the embedded form. However, given by nature of the form embed I got to thinking about this, how would it know who the person is in order to progressively show fields? Each time someone hits an embedded form its like it sees them as a brand new person. I'm sure Sanford will correct me on this if I'm wrong. Now that I have the Illustrator file for the graphic it will be much quicker to make updates on it.

[SanfordWhiteman]

In going through this again we originally had that you could do progressive profiling with the embedded form.

You can do ProgPro with an embedded form.  You should have a checkbox there.

You ​can ​do Known Lead HTML ("hide form if known visitor" in your chart) with an embedded form.  You should have a checkbox there.

...how would it know who the person is in order to progressively show fields? Each time someone hits an embedded form its like it sees them as a brand new person.

No, embedded forms do know what fields have been filled in by the associated lead.  They use an internal method called ​getKnownLead.  ​It isn't necessary to know what the ​values ​of those fields are, all that is necessary is that they are ​non-empty ​so the next set of ProgPro fields can be shown. 

Embedded forms are even allowed to fetch the first + last name of the associated lead: that's why they're able to show that information when you enable ​Known Lead HTML.  ​It's only the wider set of PII values that can't be natively fetched into an embedded form.

You should also change the ** note from "Must use querystring constraint" to "Use querystring or referrer constraint".  You can certainly filter embedded forms by the full URL of the web page on which they are embedded.

The salient difference between embedded forms and forms on Marketo-hosted LPs is the lack of native support for PreFill.  That's it.

[Anonymous]

Hi there!

We are using Segment.com and I noticed that when embedding a Marketo form, we lose the "identify" call in Segment. I'd like to store all activity in one place, and by adding a Marketo form we lose part of the story.

Is this a use case where we should use a non-native Marketo form, and then pass the data to Marketo?

[Pierce_Ujjainw3]

I would do a non-Marketo form before an embedded form in a heartbeat.

Just make sure you also do this: http://developers.marketo.com/blog/external-page-prefill/

[SanfordWhiteman]

For Segment? There's no reason to use a non-Marketo form -- and if you do, you lose the Marketo activity log unless you cross-post. I explained to Allison elsewhere that a Segment identify() works perfectly with the Marketo forms event model, you just need to plug it in correctly.

And I wish that blog post would curl up and disappear...

[Anonymous]

Hi... do you have any suggestions on what the easiest way to integrate an embedded marketo form into an iframe that would go into WordPress would be? I'm considering switch all of my Marketo landing pages w/ marketo forms into WordPress pages, but cannot find a step-by-step that would help me convert them.

[SanfordWhiteman]

While a form, within a landing page, within an IFRAME, within a main document can be said to be "embedded" in the outermost document, IMO it's clearer to call this method "IFRAMEd LP," since that's exactly what it is.

There's also the literal Marketo "embed code," which does not use an IFRAME to show the form, instead putting the <FORM> and all its styles and field logic in the main document HTML (technical note: this true "embedded" method does use an invisible IFRAME, but we can still call it a "non-IFRAME" method because that IFRAME doesn't affect rendering/styling or user interaction with the visible form).

Anyway, when you speak of IFRAMEs and of switching "Marketo landing pages w/Marketo forms into WordPress pages," you're really talking about creating minimal Marketo LPs whose only visible element is a <FORM>. You can't get away completely from creating LPs, because IFRAMEs contain full HTML documents, not merely document fragments or scripts. If you choose IFRAMEs (I never do unless forced) I recommend using a Guided LP template to have full control over the HTML markup, keeping it as short as possible other than adding a mktoForm element in the <BODY> that will pull in a form from your instance.

As for how to add that IFRAME onto your WordPress pages, there's no pat answer that's "easiest" but you might take advantage of a WP plugin specifically designed for IFRAMEing remote content, and which can forward query parameters from the main document, like this one.

Forwarding query parameters from the outer doc to the inner doc is useful because it allows you to continue to AutoFill form fields from query parameters, as you would on a Marketo LP, instead of having to switch to referrer params, which can be confusing.  Note the external referrer -- the next-hop referrer that brought the person to the WP page, in other words -- will not be accessible unless you deliberately pass the value from the WP LP to the Marketo LP. (Though the external referrer isn't a real solution for attribution, especially if your LP(s) aren't running over https://, it is of course a nice-to-have.)