ランディングページにPostHogを
PostHogのプロジェクトの多くは登録から始まるので、ユーザーを連れてきた広告は推測するしかありません。LanderLabのWebhookは、スタートラインを広告まで戻します。各リードは、フォームの回答、ページ、UTM、訪問者のIPをプロパティにしたイベントとしてPostHogのcaptureエンドポイントへ送られ、本人のメールアドレスと名前がプロフィールに設定されます。
トラフィックを買うプロダクト主導のチームのためのものです。SaaSのトライアル、ウェイトリストのあるアプリ、供給側を募集するマーケットプレイス。リードとプロダクトの利用がPostHogで同じ人物にまとまれば、広告からアクティベーションまでのファネルが、スプレッドシートではなく1つのレポートになります。
ランディングページのリードを、PostHogのイベントに
各送信は、フォームの項目とクイズの回答をプロパティにした「Lead submitted」イベントとしてPostHogに入ります。PostHog独自のプロパティも埋まります。ページは$current_urlに、訪問者のIPは$ipに入るので、場所はLanderLabのサーバーではなく、本人から割り出されます。
PostHogのcaptureエンドポイントは公開・書き込み専用で、プロジェクトトークンは共有される前提のものなので、Webhookから送るのにシークレットキーは一切要りません。
フォームからパーソンプロパティを
イベントの中で、$setがメールアドレスと名前をその人のプロフィールに書き込み、$set_onceが最初にコンバージョンしたランディングページを、後で再び送信しても保持します。アプリが同じメールアドレスでユーザーを識別していれば、リードとプロダクトでのすべての行動が、1人の人物にまとまります。
広告から始まるファネル
リードのイベントにutm_source、utm_campaign、A/Bのバリエーションが載っていれば、PostHogのファネルをランディングページから始め、自分にとって大事なアクションで終えられます。最初のプロジェクト作成、最初の請求書の送付、プランのアップグレード。キャンペーン別に分ければ、登録するだけでなく、アクティベートするユーザーを連れてくる広告セットがわかります。
これは、LanderLabだけではできないテストです。LanderLabのレポートはバリエーションをリードで評価し、PostHogはその評価を、リードが次に何をするかまで広げます。
ワークフローで、追跡する価値のあるリードだけを
すべての送信がプロダクト分析に必要なわけではありません。ページとPostHogの間にワークフローを置けます。完了したクイズだけを通すフィルター、テストのリードを除外する条件分岐、そしてイベントを送るHTTPリクエストノード。実行履歴ビューで各リードの経路がわかるので、失敗した送信が、ファネルから静かに抜け落ちるのではなく、目に見えます。
