Documentation on forms 2.0 can be found here - Forms 2.0 ยป Marketo Developers
When you say you're concerned the information won't get into Marketo, do you mean it might miss some? The form is still 'hooked' up to Marketo, so no data is going to go a stray, once submitted it's going straight into your instance. By embedding it into a page using script, you're just rendering it on page, plus with Munchkin installed on the page your cookies are going to be set as expected.
I had understood this would be a risk if I had used the web server form push option, as opposed to Forms 2.0.
My developer wants to use the web server forms push as the solution, whilst I would like to move to embedding a Marketo forms. As a result, I'm having to do a lot of research to understand the trade-offs.
My developer wants to use the web server forms push as the solution, whilst I would like to move to embedding a Marketo forms. As a result, I'm having to do a lot of research to understand the trade-offs.
I see no reason to mince words here: the trade-off is professionalism. Either your site is ready for the real world, or it shouldn't be live.
meaning that I will potentially have to do a wash to "find" anyone who didn't pass.
This may not even be possible BTW. If your back end just fails to transmit the form post, but doesn't cache the original data anywhere, there's nothing for you to look at and replay/compare.
I wouldn't use any Marketo embedded form for any real mission critical form. If something goes wrong with the clients javascript like browser extensions blocking things, the form doesn't get displayed at all. I've seen this come across plenty of times as I use Marketo forms for all my gated content. Mission critical forms like platform signups and things do not use embedded forms at all. We simply use the Marketo APIs to create leads. Something your developer can easily do on ANY form he wants and reuse the same function over and over. Its what I did at my previous company as well.
Emulating the basic functions of a Marketo form requires 2 API calls. You get 10,000 API calls a day (I'm being generous and assuming you don't have any other integrations, and that you aren't fully emulating advanced form features). In 20 minutes, an unskilled hacker will deny service to your mission-critical forms for the rest of the day. An API-based approach is even less resilient than a server-side form post, which at least requires a hacker to continually outpace the server limit of 30 posts per minute.
Properly cloaking the form library and form posts behind your own branded CNAME is not known to be vulnerable to browser tracking protection (in theory, it could be, but this has not been seen in the wild).
If your concern is about JavaScript support in general, you can't use Marketo-tracked links in your emails, since those don't function without JS. A Marketo environment is by implication a JS-enabled environment (although Marketo LPs do not require JS, you do need JS to get to them via a tracked link).