ランディングページにWebhookを
ほとんどのリード獲得の仕組みでは、途中で税金のようなコストを払っています。直接受け取れたはずのエンドポイントへ、ページからリードを動かすだけのZapやシナリオです。どのリードもその中継のためにタスクやクレジットを払い、中継が1つ増えるたびに、買い手が待つ間にリードが止まりうる場所も1つ増えます。
LanderLabのWebhook連携は、そのコストをなくします。各ページが、任意のHTTPSエンドポイントへリードを直接送ります。買い手のポスティングURL、自社のリードAPI、CRMのエンドポイント、トラッカーのポストバック。メソッド、形式、ヘッダー、本文の中身まで自分で決められるので、相手側はドキュメントのとおりの形でリードを受け取れます。
このサイトで紹介しているツールのうち、専用の連携がないものの多くは、この連携で動いています。買い手から仕様書が届いたら、使うのはこれです。
ミドルウェアにお金を払うより、直接のWebhookがいい理由
ページからZap、そして買い手へと進むリードは、2つのシステムに頼り、そのうち1つから請求されます。量の多いオファーでは、途中で何も特別なことが起きていなくても、自動化ツールのプランはリード数とともに膨らみます。Zapはリードを受け取って、別の場所へ送るだけなのに。
直接のWebhookは、中継のない同じ送信です。リードは送信時にページからエンドポイントへ届き、すべてあなたの管理下にあります。間で止まったり、タスクを使い切ったり、料金を変えたりするものはありません。ミドルウェアは複数ステップが必要な処理に残し、そうでないものはWebhookに任せましょう。
相手が求める形式でリードを送る
買い手もAPIも、こだわりがあります。仕様書どおりの名前を付けた項目でフラットなフォーム送信を求めるところもあれば、コンタクトをリードのオブジェクトの中に、トラッキングを別のオブジェクトの中にネストし、その横に固定のソースタグとキャンペーンIDを置いたJSONを求めるところもあります。Webhookはどちらにも対応します。項目にチェックを入れて各キーの名前を変えるシンプルな項目リストか、ネストしたオブジェクト、配列、固定値を使って自分で書くJSON本文か。
メソッドはGET、POST、PUTに対応し、本文はJSONかURLエンコードのフォームデータで送ります。カスタムヘッダーでAPIキーやトークンを送れるので、認証情報がURLに載ることはありません。
すべてのリードに、コンプライアンスとアトリビューションの項目を
LanderLabは、すべてのリードに独自の項目を追加します。ページの完全なURL、訪問者のIPとユーザーエージェント、UTCでの送信日時、表示したA/Bのバリエーション。リードに異議が出たときに買い手が確認する項目であり、リードの出どころを証明するのに必要な項目です。
utm_campaign、gclid、トラッカーのクリックIDなど、URLパラメーターと同じ名前の隠しフィールドを追加すれば、それもリードと一緒に保存され、一緒に送られます。買い手はアトリビューションを受け取り、あなたは各バリエーションを、単なるフォーム送信数ではなく、受け入れられたリードで判断できます。
GETでポストバックとPing
すべての送り先が本文を求めるわけではありません。トラッカーのポストバック、アフィリエイトネットワークのコンバージョンURL、単純なPingは、クエリ文字列でデータを受け取ります。GETのWebhookは、マッピングした項目をまさにその形で送ります。トラッカーが求めるパラメーター名でクリックIDを、その横に固定の報酬額やステータスを。コンバージョンは送信時に、そのクリックを買ったキャンペーンへ戻ります。
代わりにワークフローを使うとき
Webhookは、そのページからのすべてのリードを送ります。一部のリードだけを送りたいとき、たとえば米国のリードはある買い手へ、それ以外は別の買い手へ、あるいは待機の後にフォローアップを送るときは、LanderLabのワークフロー（ベータ版）に、同じ種類のリクエストがHTTPリクエストノードとしてあります。フィルター、条件分岐、スイッチのノードの後ろに置け、実行履歴ビューで各リードの経路と失敗したステップを確認できます。
どちらの場合も、リードはLanderLabのリードタブにも保存されるので、エンドポイントが落ちていてもリードを失うことはありません。ただし、「コンプライアンス対応のリード連携」がオンの場合は別で、この設定は意図的に保存を行いません。
