簡単に言うと、フォームは Pardot 内で構築およびスタイル設定され、iFrame 経由で Web サイトに埋め込まれます。一方、フォームハンドラーはネイティブ Web サイトフォームの背後にある影のようなもので、データは Postscript 経由で Pardot に送信されると転送されます。フォームハンドラーを使用すると、フォームの構築とスタイル設定が Pardot の外部で管理されます。フォーム ハンドラーはデータのコピーのみを受信します。
たとえば、ページの URL または UTM パラメータ値を非表示のフォーム フィールドに渡すには Javascript を使用する必要があり、データを iFrame に渡すのが難しい場合があります。このため、JavaScript 要件をサポートできる開発者も必要になる場合があります。
フォーム ハンドラーを使用すると、Web 管理者が適切なフォームに追加する必要があるフォーム ハンドラーごとにスクリプトが提供されるため、実装はもう少し簡単になります。注意すべき点は、ネイティブ フォームとフォーム ハンドラーの間でフィールド API 名が一致していることを確認することです (簡単そうに思えますが、信じてください。場合によっては変化球が発生する可能性があります)。
ページ URL または UTM パラメーター値を非表示のフォーム フィールドに渡すなど、これらのことを実現するには、Web 管理者がこれを行うようにネイティブ Web サイト フォームを構成する必要があります。また、同じ Web サイトはなく、プラットフォームも異なるため、適切な Web サイトを作成するには、ある程度の試用とテストが必要になる場合があります。
プログレッシブプロファイリング
この機能はフォームでのみ利用可能で、プロスペクトのレコードに対して他のデータがすでに存在する場合にのみ特定のフィールドが表示されるようにフォームを設定できます。
たとえば、最初の変換時点ではエンドユーザーに名前と電子メール アドレスのみを入力させ、次にフォームに遭遇したときに「会社名」や「社名」などを尋ねるようにしたいとします。従業員"。初めてあなたのブランドとやり取りする人からすべての情報を探ろうとするのではなく、見込み客のプロフィールを構築します。
同様に、フィールドの事前入力もフォームでのみ可能です。ユーザー エクスペリエンスを少しでもスムーズにする、マーケターにとってもう 1 つの便利なツールです。
ビジネスおよびマーケティング戦略によっては、これが Forms が勝者であるかどうかを決定する重要な要素となる可能性があります。
多言語フォーム
フォームを使用している場合、フォームを作成する責任は通常、マーケティング チームにあります。また、フォームは (フォームごとに) 1 つの言語しかサポートできないため、言語ごとに一意のフォームを作成することになります。必要なすべての言語のフォームを作成、更新、保守する能力がチームにあるかどうかを検討する必要があります。
一方、フォーム ハンドラーは、Web フォーム自体が別の場所で作成され、Web チームに常駐する可能性が高いため、セットアップがはるかに簡単なプロセスです。多言語の観点から見ると、Web フォームの構成方法に応じて、言語ごと、フォーム タイプごとに 1 つのフォーム ハンドラーを作成する必要がある場合があります。ほとんどの場合、これはフィールド API 名に関係します。
たとえば、Web サイトが 5 つの言語をサポートしており、それぞれの言語にまったく同じフィールドを含む「お問い合わせ」フォームがある場合、ユーザーのフロントエンドではローカル言語でラベル付けされたフィールドが表示され、裏面ではフィールドが表示される可能性があります。 -end の場合、フィールドはすべて同じ API 名を維持します。API 名はフォーム ハンドラーのフィールドと一致するものであるため、Web サイトの API 名がすべて英語の場合は、5 つの「お問い合わせ」フォームすべてに対してフォーム ハンドラーを 1 つだけ使用できます。
各オプションには長所と短所があります。フォームを使用すると、マーケティング チームの責任が大きくなりますが、必要に応じてフォームを作成する自主性も高まり、Web チームにのみフォームを Web サイトに追加する権限が与えられます。フォーム ハンドラーではその逆になります。したがって、決定を下す前に、両方のチーム内のリソースを決定することが重要です。
Pardot フォームとフォームハンドラーは異なります。Pardot フォームは、Pardot で完全に設計および管理されます。フォームハンドラーは Pardot を外部フォームに接続して、プロスペクト情報を Pardot に集めることができます。機能を確認して、使用するフォームの種類を決定します。
iFrame とフォーム ハンドラーの主な違いは、後者ではサードパーティのフォームを統合できることです。Pardot の外部、つまり、Pardot を使用する前にフォームがあり、それを Pardot に統合する必要がある場合は、「フォームハンドラー」を通じて実行できます。このオプションは iFrame では使用できません。
Pardot IFRAME の代わりにフォームハンドラーを使用する場合
iFrame または Pardot フォームではなくフォームハンドラーを選択する場合に考慮すべき 5 つの点を以下に示します。
- フォームハンドラーを使用すると、Pardot の外側をデザインでき、可能性の範囲が広がるため、フォームの外観を完全に制御できます。
- アプリケーションデータを複数のデータベースに公開します。つまり、訪問者がフォームに入力して見込み客になると、この情報は Pardot を使用する前に、Pardot データベースと元のデータベースに保存されます。
- 財務データやパスワードなどの情報を含むログイン フォームを計画する必要がある場合
- Pardot を既存のフォームと統合する
- 「サードパーティデータ」フォームツールを使用します。
ただし、上記のシナリオのいずれもニーズに合わない別の状況に陥った場合は、おそらく iFrame が必要であるためです。
フォームハンドラーの代わりに Pardot フォームまたは iframe を使用する場合
iFrame は、フォームハンドラーとは異なり、Pardot から完全に作成および管理されるフォームであり、作成したら、HTML コードをコピーして Web サイトに簡単に統合できます。iFrame はほとんどの人が最もよく使用しています。
フォーム ハンドラーの代わりに IFrame を選択する利点のいくつか
-
プログレッシブ プロファイル: iFrame を使用すると、クライアントから既に得ている情報に関するフィールドを動的に変更または非表示にすることができます。これにより、フォームが小さくなり、入力できるオプションが増えます。
-
統合されたロボット保護:すべての Pardot フォームにはハニーポットと条件付き CAPTCHA があります。良いニュースは、あなたがそれを望むかどうかはあなたにも見込み客にもわからないということです。追加のセキュリティ層を追加する必要があると思われる場合は、対応するチェックボックスを備えた ReCaptcha を追加できます。
-
iframe の訪問とデータ エラー: iframe を使用すると、フォームへの応答方法に関する詳細情報が得られます。たとえば、エラー率が異常に高い場合、Pardot はフィールドで要求する情報の厳密性を下げるか、フィールドの数を減らすことをお勧めします。
-
Pardot ランディングでの IFrame の使用: iFrame を作成したら、Pardot で作成したランディングに簡単に追加できます。プロスペクトが Pardot で作成されたランディングでフォームに入力した場合、その情報はフォームではなくランディング ページのレポート部分に表示されることに注意してください。
-
フォームビューに基づいて自動化: Pardot が提供する訪問に関する情報のおかげで、取得したデータに基づいて自動化できます。このようにして、見込み客がフォームにアクセスした場合、通知を作成して通知の形式で届くようにしたり、通知にラベルを付けることもできます。
-
フォームの完成後に「ありがとうページ」を表示する:フォームの完成後に生成される「ありがとう」メッセージを完全に制御したい場合は、これらのフォームを Pardot でホストすることになります。これにより、次のことが可能になります。メッセージを素早く簡単に変更できます。
Pardot フォームは、Pardot でリード獲得フォームを作成するためのネイティブ オプションです。Pardot フォームを使用すると、事前入力フィールド、プログレッシブプロファイリング、その他の高度な機能を利用できるようになります。ただし、さまざまなメリットがあるにもかかわらず、それらが常にデフォルトの選択肢になるわけではありません。
その他のデータ収集オプションとして、Pardot の顧客には、既存のフォームインフラストラクチャを Pardot と統合するオプション (Pardot フォームハンドラーまたは Salesforce Web-to-Lead) が提供されます。これらのオプションは柔軟ではありますが、Pardot フォームの代わりに好まれると、マーケティング担当者は Pardot フォームをテストする前にメリットを逃してしまいます。このことから、「なぜ組織は Pardot フォームを無視するのでしょうか?」という疑問が生じます。
Pardot フォームハンドラーと Pardot フォーム
Web サイト上の既存のフォームを Pardot と統合する必要がある場合は、Pardot フォームハンドラーを使用します。フォーム ハンドラーは、Web-to-Lead フォームと同様の方法で動作します。つまり、外部フォームのコードに貼り付けられるコードのスニペットを生成します。Pardot では、フォームハンドラーは成功したプロスペクトの送信を記録するバケットとして機能します。
Pardot を使用している場合、Pardot フォームハンドラーは最適なオプションではありません。その理由は次のとおりです。
-
フォームビューに関するレポート: Pardot フォームハンドラーを使用すると、合計/個別の送信およびコンバージョンに関するレポートを作成できます。Pardot フォームはビューも追跡するため、送信率に加えて、フォームのエラーやフォームのサンキューページのクリックなども収集できます。
-
事前入力フィールド: Web サイト上のフォームは Pardot と一方向の関係にあります (つまり、データを Pardot に送信します)。つまり、Pardot は、そのプロスペクトについてすでに知っているデータを含め、情報をフォームと共有することはありません。フィールドが事前に入力されていると、戻ってくるプロスペクトの負担を軽減できます。また、既にデータがある場合は、Pardot フォームに表示されるフィールドの数を減らすこともできます。
-
プログレッシブプロファイリング: この機能は、最初のフォームで事前に大量の情報を要求するのではなく、時間の経過とともにより多くの見込み顧客データを収集するように設計されています。その見込み客に関して持っていない特定のデータを尋ね、持っている場合はシーケンス内の次の質問を選択するのが賢明です。
-
ボット保護: Pardot フォームにはこのオプションがありますが、Web サイトフォームの場合は別のプロバイダーでこれを並べ替える必要があります。
注: ユーザーにパスワードの作成、ファイルのアップロード、または機密情報の入力を求めるフォームが必要な場合は、Pardot フォームを使用しないでください。代わりにフォームハンドラーを使用する必要がありますが、それでもフォームは Pardot と統合されています。
Web サイトに Pardot フォームを埋め込む必要がある理由はいくつかあります。Pardot フォームを使用する際の制御が強化されるだけでなく、プログレッシブプロファイリング、依存フィールドなどの Pardot の拡張機能の一部も使用できるようになり、ユーザーがフォームに戻ってきたときに認識されるようになります。
私がクライアントから聞く最大の苦情の 1 つは、Web サイトにフォームがあり、ハンドラーを使用して送信データを Pardot に渡したいだけであるというものです。プログレッシブプロファイリングなど、Pardot の高度なフォーム機能の一部を使用できるようにしたいため、機能かデザインかの選択を迫られています。
既存の Web サイトと導入内容によっては、お問い合わせフォームやブログの購読など、ユーザーが再アクセスしない可能性のある単純なフォームに Web サイト上の Pardot フォームハンドラーを活用することが有益な場合があります。
次に、ランディング ページで Pardot フォームを活用して、Pardot フォームの完全な機能を実現します。ご想像のとおり、毎月のウェビナーやイベント登録などのキャンペーンを実施している場合、Pardot ランディング ページには定期的に訪問するユーザーがいる可能性があります。このユースケースでは、プログレッシブプロファイリングや依存フィールドなどの機能を活用して、定期的なキャンペーンに参加しているリード/連絡先に関する詳細情報を収集できます。
私も同様のアプローチを試みました。$.post を使用してフォーム値を PHP ファイルに POST します。そこで、CURL (curl_exec) を使用してすべてを Pardot フォームハンドラーにポストします。すべて正常に動作しますが、Pardot Cookie が設定されていません。iFrame 方式の方が優れているのでしょうか?
それは、サーバー側の投稿を行っているためです。サーバーからリクエストを行うと、Pardot は CURL のリクエストにトラッキング Cookie を設定します。クライアントのブラウザに Cookie を設定したいとします。クライアントのブラウザがリクエストを行うため、iframe がより適切に機能するのはこのためです。
フォームハンドラーでは、ブラウザー側からの投稿 (通常の投稿方法) またはサーバー側からの投稿を実行できます。サーバー側からの投稿では、キオスク/データエントリモードをフォームハンドラー上で有効にして、サーバーがプロスペクトとしてトラッキングされることを防止します。サーバー側からの投稿では、フォームハンドラーの登録アクティビティがプロスペクトのレコードに記録されますが、トラッキングクッキーはありません。
フォームハンドラーの送信がサーバサイドからの送信で実行される場合、ビジターの Cookie が削除されるため、ビジターアクティビティレコードは、関連付けられたプロスペクトレコードに結び付けられません。これは、ページに Account Engagement トラッキングコードがあるにもかかわらず、プロスペクトアクティビティセクションに「ページビュー」が表示されないことからも分かります。この理由で、ページアクションなどのマーケティングツールは実行されません。ビジターと紐づいていないプロスペクトにはアクションを実行することができないためです。