不動産マーケティング
WebフォームとFacebookの見込み客情報を、一つの管理画面へ
フォームとLead AdsのWebhookを共通のPostgreSQLモデルに集約し、権限付き管理画面とメール通知につなぎました。
課題
WebフォームとFacebook Lead Adsから、異なる形式とタイミングで見込み客情報が届いていました。メールと表計算で引き継ぐと、重複、処理状況、担当者の権限にずれが生じます。いつ届き、誰が閲覧し、その後どう対応したかも追いにくくなっていました。
制約
- 公開フォームとMeta Webhookで外部リクエストを受けつつ、管理機能と見込み客データを公開しない必要があります。
- イベントの再送、項目の欠落、到着遅延があるため、重複判定と安全な再試行が必要です。
- 見込み客情報は機密性が高く、件数、内容、顧客の特定につながる情報を公開できません。
取り組んだこと
PostgreSQLを業務データの正本にする
見込み客、取得元、状態、業務上の関係をPostgreSQLで管理し、画面の読み書きと権限に共通のトランザクションモデルを使いました。
見送った選択肢 BigQueryは分析に向いていますが、頻繁な状態変更や関連データを扱う日常業務のDBとしては選びませんでした。
公開の受付と管理機能を分離する
Webフォーム、Webhook受信、認証済みの管理機能の境界を明確にし、外部アクセスが内部業務へ与える影響を抑えました。
見送った選択肢 公開部分と管理部分ではリスクと拡張の条件が異なるため、すべてのルートと権限を区別のない一つの仕組みにしませんでした。
Webhookをすぐに受け取り、再送を制御する
Facebook Lead Adsのイベントを到着時に検証・処理し、取得元の識別子で同じイベントの二重登録を防ぎました。
見送った選択肢 定期取得だけに頼ると通知が遅れ、元のイベント順序も分かりにくくなるため、受信時の処理を採用しました。
権限と監査履歴を基盤に組み込む
画面の操作を隠すだけでなく、認証、役割別権限、操作記録で管理画面を制御しています。
見送った選択肢 機密情報へのアクセスには追跡できるバックエンドの境界が必要なため、共用アカウントや画面側の条件で認可を代用しませんでした。
成果
- WebフォームとFacebook Lead Adsが、一つの業務データモデルに集約されました。
- 権限のある担当者が、メールや表計算に頼らず、役割を反映した管理画面で作業できます。
- 通知、取得元、処理状況をシステムの流れとして追跡できます。
技術
- Go
- PostgreSQL
- Google Cloud Run
- Cloud SQL
- Meta Webhooks
振り返り
やり直すなら、保存期間と最小権限の一覧を初回リリースの要件にします。公開後に足せばよいものではありません。見込み客システムが信頼できるかどうかを左右するからです。