ランディングページにCustomer.ioを
Customer.ioが最も力を発揮するのは、相手がたった今何をしたかを把握しているときです。デモの依頼、ウェイトリストへの登録、完了したクイズは、まさにそうしたシグナルです。ところがランディングページが自社プロダクトの外にあると、シグナルは遅れて届くか、まったく届かないことがよくあります。
LanderLabのWebhookは各リードをCustomer.ioのTrack APIへ送るので、1回のリクエストで、回答とキャンペーンを属性に持つ人物を識別し、lead_submittedのような、イベントをトリガーにしたキャンペーンの開始条件になるイベントを記録します。間にZapはありません。
LinkedInやGoogleからデモの予約を取るSaaSチーム、Metaで登録者を集めるフィンテックや消費者向けアプリ、クイズのリードにはニュースレターの登録者とは別のシーケンスを送りたいECブランドに向いた組み合わせです。
有料トラフィックから集めるCustomer.ioの人物とイベント
Customer.ioのTrack APIは、人物とイベントを1つのバッチで受け取ります。人物はメールアドレスで識別され、リードの属性を持ちます。イベントには、キャンペーンが待ち受けている名前を付けます。Customer.ioにとって初めての人物なら、新しく作成されます。
これで、ランディングページがプロダクトデータの一部になります。アプリ内の行動に使っているのと同じキャンペーン、セグメント、レポートで、広告が連れてきた人たちも扱えます。
デモの依頼と登録に、イベントをトリガーにしたキャンペーン
LinkedIn広告からのデモの依頼には、ありきたりの自動返信以上の対応がふさわしいはずです。プロフィールにイベントがあれば、Customer.ioのキャンペーンで依頼を確認し、翌日にはそのリードの業界の導入事例を送り、まだ予約していなければもう一度フォローアップできます。
消費者向けアプリなら、同じイベントでウェイトリストのシーケンスをメールで始め、相手がアプリをインストールしたらプッシュ通知に切り替えられます。
Customer.ioのプロフィールに残るアトリビューション
隠しフィールドが広告のURLからutm_source、utm_campaign、クリックIDを保持し、LanderLabがページとバリエーションを加えます。これらを属性として送れば、1つのキャンペーンからのすべてのリードでセグメントを作ったり、広告セットごとにアクティベーションを比べたり、どのバージョンのページがコンバージョンしたユーザーを連れてきたかを確認したりできます。
Customer.ioに届く前に、回答でリードを振り分ける
LanderLabのワークフロー（ベータ版）では、企業規模やプランで分岐するスイッチが、別々のHTTPリクエストノードから異なるイベントを送れます。フィルターを使えば、対象市場外のリードを止められます。実行履歴ビューで各リードの経路がわかるので、ある人がなぜそのキャンペーンを受け取ったのかが正確にわかります。
