For most B2B companies, integrating Website Forms with marketing automation solutions often proves challenging, as it’s usually an afterthought that arises from implementing a new marketing automation solution rather than a jointly planned effort that takes into consideration the needs of different business stakeholders.
Most companies already have forms in place before selecting a Marketing Automation Platform (MAP), leading to a big question of “Now what?” in the implementation phase – Do we replace Website Forms with the ones supplied by the MAP? Do we integrate Website Forms with the MAP using website development resources? Do we use a third party platform to integrate the two?
In this post I wish to address the pros and cons of each possibility, alongside discussing specific common marketing needs and my recommended solution for those specific cases. Please note that while the examples supplied are for HubSpot – this is equally applicable to Marketo Forms and most MAP Native Forms.
Native Or Non-Native?
Marketing Automation Platforms usually provide their own form-building tools. You can design a form within the MAP, and “embed” that form on your website. This makes it easier for a non-developer to setup new forms, to be used within different digital assets (website, landing pages).
“Native Forms” – embeddable forms by your Marketing Automation Platform (MAP)
| Native Forms | Forms offered by the Marketing Automation Platform form-building tools and are embeddable using a small piece of code provided by the Marketing Automation Platforms. They are easy to create, easy to manage and duplicate – but they have some strong advantages and disadvantages. |
| Advantages | 😄 It’s very easy to create and use Native Forms 🌟 Native Forms offers unique solutions – such as progressive filling, pre-filled or pre-hidden fields, etc. 🎨 it’s easy to design these forms, but the design itself is often not very flexible. 🛠️ “Out of the box” experience tracks visitors correctly without additional configuration. |
| Disadvantages | 🛠️ Limited Customization: Native Form builders do not offer the level of visual customization available by code, and without additional development work – might differ from existing forms in your website. 🚧 Dependency on the MAP: Any issue with the MAP or its embedded scripts could affect form loading on your website. 📉 They might pose an SEO Impact: Embedded forms may sometimes affect your page load speed, which can impact SEO. |
Website Forms or “Non-Native Forms” – forms that are not a part of your Marketing Automation Platforms
These types of forms vary between:
• 🖹 Website Forms custom-made by a web-developer
• 💻Website Forms supplied by a CMS (think WordPress, WIX, etc.) or by a Theme or by a Plugin (for example, the popular “Contact Form 7” WordPress plugin, or Forms that are a part of “Elementor” theme).
• 🥉Third Party Form building platforms such as Typeform
We can look at Website Forms that are custom-made by web developers and CMS forms as a part of the same “Bucket” – as they both usually fall under the responsibility of the website development team:
| Developer Made and CMS/Theme/Plugin forms | Both custom-made forms made by a website developer or forms supplied by your Content Management System – are choices usually made by the developers of your website. Website developers will often prefer to use CMS based forms and to further customize them according to need as these already contain many features that do not have to be developed from scratch. |
| Advantages | 😄 Full Customization – These forms are built specifically to the website design goals and UX. 🚀 Better Performance – These forms are usually a part of the website codebase and load seamlessly. 🛠️These forms are flexible – they can be built to connect to multiple systems and/or your product. They can be made to perform tasks that are usually outside the realm of Native Form builders in marketing automation platforms (include data from external resources, collect sensitive data, etc.) |
| Disadvantages | 💻 Developer Dependency. These usually require web development resources for creation and maintenance. ⌛ It takes longer to set up compared to Native Forms. 🛠️ Improper Implementation will pass partial data to the MAP, excluding visitor token (“cookie”) from the submission and disallowing the MAP to properly track the lead website visits. |
Third Party Form building platforms, however, differ a bit, as they can be often set and maintained by non-developers:
| 🥉Third Party Form building platforms | Third party form building platforms are purposely built to do what Marketing Automation tools can’t – provide the easiest way to create powerful, flexible tools that connect to multiple systems and provide advanced features |
| Advantages | 🔄 Seamless Integration – It’s easy to connect these platforms to other platforms – and usually they can connect to multiple target-platforms together: Send data to your MAP, CRM, Email etc. 🚀 Quick and Easy: they are faster to implement and require no-code or less-code than using either Native Forms or Website Forms. 🌐 They are easy to maintain, modify and extend in capabilities. They support features often not supported by Native Forms and offer better design flexibility compared to Native Forms. |
| Disadvantages | 🛠️ Adding Additional Stack Complexities– these are often an afterthought and purchased for specific need, so they are not taken into account when budgeting. 🚧 Dependency on a 3rd party platform – as these are an additional point of potential failure sitting between your website and your target platform (MAP/CRM etc.) their reliability is a concern. |
✋So What Should We Use ⁉️
Well, it depends… on the use-case. Let’s examine some common scenarios:
I work at a small to medium size business, we recently purchased HubSpot – should we replace our website forms to native HubSpot forms?
Great question. If you already have a well-design website, which is not set to change soon in design language, the easiest thing for you to do is to connect your existing Website Forms, to HubSpot.
This will assure the following:
1. Your website User Experience will remain the same
2. You will not impact your website performance metrics or create any concerns for SEO, Usability etc.
3. any existing functionality the Website Forms already provide will not need to be replicated with another system – so if you already have these forms connected to your product (trial-registration for example) – this will continue to work as it always had.
Please note that the Website Forms will still have to be integrated properly with your HubSpot account (Form-API endpoint, HubSpot Token and all sort of technicalities that matter ALOT for your attribution needs).
For the purpose of going live quickly – this is the right call.
But you’ll also lose some functionalities – for example, progressive form filling is a feature supported on Native Forms in many MAPs – where the form dynamically adjust questions based on known user information. So marketeers can gradually gain more information about a lead over time. Pre-filled forms, for known users, also won’t be supported (unless you built a user-management system on your website, just for the sake of marketing-forms – and that probably won’t happen).
In the above-mentioned situation, a hybrid approach is also possible:
* A Website Contact-Us form can be executed using website-forms – is it usually not a form used by returning visitors often
* A Gated Content form can be executed using Native Forms – as it value in user-experience is great – imagine a lead having to fill his details five times, just to download an five gated e-books, instead of having to fill his details one time, and then be shown a “download now” button or a pre-filled form. And as the Native Forms can be easily created by the marketing team – it would be easier to deploy new forms and content-related workflows without website developer assistance.
I work in a small startup and we chose HubSpot to be our CRM and MAP – we are currently building our website – what forms should I use for my website and what should I use for my landing pages?
As you start fresh, there should be no problem in using HubSpot Native Forms in your website. Your Website Developers can overcome the design limitations by applying their own ‘code’ on them (CSS) and make the forms look and behave exactly as your designer wishes them to be. the added benefits are great: you’ll be able to edit these forms from within HubSpot interface (if you wish to add or subtract a field for example, or change a label), you’ll be able to use features like pre-filled forms.
For landing pages – the question depends on whether you use HubSpot to host your landing pages, or whether you use an external platform, or your CMS to host these pages.
For HubSpot landing pages, Native Forms are basically the way to go – they work best that way. But you will be limited in terms of design, to whatever design the landing page template supports – this is great if you have several templates ready for repeating, predictable campaigns (gated resources, webinar invitations, etc.).
If you use a landing page building platform (example – Unbounce) – it comes with it’s own forms. It can be connected to your MAP, but tracking is often hindered. I recommend against using landing page building platforms unless your marketing team needs to launch many type of landing pages, with different designs, which differs greatly between each individual page, and they wish to do so without the assistance of professional designers and developers. i.e. variation is more important that consistency. In any other case, either use HubSpot directly or your website CMS to host said pages.
If you do use the website to host the landing pages, Native Forms are still the best. Your website developers can create several landing page themes, and setting new pages and setting the HubSpot forms on them can be made very easy to manage on the back-end.
🤔When should you use 3rd Party Form Builders? (if at all)
• You have a small marketing team and smaller budget, you need to lunch varied campaigns quickly – and your forms are rather complex (multi-page forms, questioners, complex logic)
• Your integration needs changes rapidly, and you need to push data to different systems, quickly.
I would still discourage using 3rd party form builders unless from big brands with proven-track record of availability and compliancy. Remember – when you use a 3rd party platform to collect data for you, and push it to your MAP and CRM – you effectively put the data of your users, in the hands of that third party. You also, add another potential point of failure between the website and your data destination (MAP/CRM).
Does the above matter in real life? ‼️ YES ‼️.
It matters from a legal and regulatory point of view (Think Data retention policies, GDPR etc.) And from a technical perspective – Let’s take one example of why an additional point of failure can create unforeseen issues:
• If your 3rd party form platform failed to load entirely – a website visitor will not see the form. This can happen, and it’s bad, but at least the visitor did not expect anything – i.e. – the visitor did not submit a form, and expected an answer.
• If your 3rd party form platform loaded the form successfully – a website visitor will see the form and submit it. But if the push from the 3rd party form was unsuccessful due to an error, the visitor still saw a successful form-fill from his point of view, and expect a rep to return to him. In actuality, data never arrived to your MAP/CRM – lead routing was not completed, and maybe – NO ONE KNOWS ABOUT IT. This is worse than bad – it’s a major f-up – and you might be surprised how many cases I’ve seen over the years of this happening with multiple platforms within organizations of different sizes. Said error might not be the cause of the 3rd party platform – it may be an error related to the target end-point (MAP/CRM) – but the end-result is the same.
If you are a tech-savvy individual, you might realize that the issue I just mentioned with 3rd party forms also applicable to Website Forms that are integrated to your MAP. Data-Connectivity can break there as well. This is true. But there are some differences making the former use case happen more often that the latter suggestion:
A. The Website is often owned by a team within the company, or a vendor working closely with them.
B. The third-party vendor is not affiliated with your company, it’s a generic platform which cannot commit to fix errors *for you*. Especially if the source of those issues are related to configuration errors or errors within the MAP/CRM.
There are many more considerations when it comes to form-building, devising a viable process of campaign-building, website-development choices related to forms and a combination of all the above. I hope this post gave a good overview of the things you need to consider when deciding what type of forms to use with your MAP.
Feel free to contact me for further assistance or share some thoughts.
Update (06th August 24) – HubSpot recently added more capabilities to their built-in form editor, shifting the balance a bit in favor of native forms depending on your exact use-case. Check them out here [1, 2]
Cheers,
