ランディングページにSupabaseを
本格的なリード獲得事業者は、いずれ、自分で管理するデータベースに生のデータを置きたくなります。リードと広告費を結合するため、リードの質をSQLで調べるため、買い手向けポータルや営業担当用のアプリにデータを送るため。たいてい止まってしまうのは、リードを受け取るエンドポイントを作る部分です。誰かが書いて、動かし続けなければならないからです。
Supabaseなら、その部分がなくなります。すべてのテーブルにはすでにRESTエンドポイントがあり、LanderLabのWebhookが、各リードを列名と値のフラットな組としてそこへポストします。Postgresが行を挿入し、Row Level Securityがリクエストに許される操作を決め、リードはキャンペーンとバリエーション付きでデータベースに入ります。
リードごとにPostgresの1行を、あなたのスキーマで
リクエストの本文はフラットで、列ごとに1つのキーなので、各リードは、型付きの列、列のデフォルト値によるcreated_atのタイムスタンプ、ほかのシステムから参照できるidを持つ行になります。どの列にも一致しないキーは拒否されるので、余計なデータがテーブルに入ることはありません。
Postgresなので、行はSQLでできることなら何にでも使えます。キャンペーン別、日別のリードのビュー、コストのテーブルとの結合、そして同じ人の再送信を2回保存するより断りたいなら、メールアドレスへのユニークインデックス。
Row Level Securityで保護
Webhookはプロジェクトのpublishable keyで書き込み、Row Level Securityがそのキーに許される操作を決めます。leadsテーブルへの挿入だけを許可しておけば、そのキーでリードを追加することはできても、読み取り、変更、削除は一切できないので、キーが秘密でなくても、リードのデータには手が届きません。
Row Level Securityを迂回するsecret keyは、自社のバックエンドから出す必要がありません。リードのフォームには不要だからです。
リードの質を測る、自分だけの信頼できる情報源
ビルダー、CRM、トラッカーは、それぞれ話の一部を持っています。すべてのリードとそのutm_campaign、クリックID、ランディングページ、バリエーションを入れたSupabaseのテーブルは、自分で管理できる部分です。日々の広告費を2つ目のテーブルに入れれば、SQLのビューでキャンペーン別、バリエーション別のリード単価が出ます。買い手や営業担当が記録する成果を加えれば、販売1件あたりのコストも出ます。
それが、スプリットテストに正直に決着をつける方法です。どのバリエーションのフォーム送信が多かったかではなく、どのバリエーションのリードがお金になったか。
挿入に失敗しても残るリード
「コンプライアンス対応のリード連携」がオンでない限り、すべてのリードはLanderLabのリードタブにも保存され、日付とバリエーションで絞り込め、Grow以上ではCSVでエクスポートできます。たとえば列の名前を変えたあとで挿入に失敗しても、リードは失われません。テーブルを直して、エクスポートから補完しましょう。代わりにLanderLabのワークフロー（ベータ版）経由で送れば、実行履歴ビューで、どのリードのリクエストが失敗したかが正確にわかります。
