房地產行銷
把網站與 Facebook 名單接進同一個營運後台
表單與 Lead Ads webhook 進入共同的 PostgreSQL 資料模型，再由權限後台與 Email 通知接手後續流程。
問題
名單從官網表單與 Facebook Lead Ads 進來，但來源格式與到達時間不同。若只靠 Email 或試算表轉交，重複資料、處理狀態與人員權限會逐漸失去一致性，管理者也很難追查一筆資料何時進來、被誰查看或如何處理。
限制
- 公開表單與 Meta webhook 必須接收外部請求，但管理後台和名單資料不能因此暴露。
- 不同來源可能重送事件、欄位不完整或延遲到達，寫入流程需要能辨識與安全重試。
- 名單屬於敏感營運資料，公開案例不得揭露名單量、內容或客戶識別。
我們做了什麼
以 PostgreSQL 作為營運真實來源
名單、來源、狀態與操作關係保存在 PostgreSQL，讓後台讀寫與權限規則落在一致的交易模型。
沒有選擇另一條路，因為 沒有直接把 BigQuery 當成日常營運資料庫，因為它適合分析，不適合承擔頻繁的狀態更新與關聯操作。
分開公開入口與管理介面
官網表單、webhook 接收與需要登入的管理功能保有清楚邊界，降低外部流量對內部操作面的影響。
沒有選擇另一條路，因為 沒有把所有路由與權限放進一個無邊界服務，因為公開端和管理端面對的風險與擴縮模式不同。
即時接收 webhook，保留重送防護
Facebook Lead Ads 事件到達後立即驗證與處理，並用來源識別避免同一事件重複建立名單。
沒有選擇另一條路，因為 沒有只靠固定排程批次拉取，因為那會增加通知延遲，也更難辨識事件在來源端的先後關係。
把角色與操作紀錄放進核心模型
管理後台以驗證、角色權限與操作紀錄控制名單存取，而不是只在畫面上隱藏功能。
沒有選擇另一條路，因為 沒有以共用帳號或前端條件代替授權，因為敏感資料的存取需要可追溯的後端邊界。
成果
- 官網表單與 Facebook Lead Ads 名單進入同一套營運資料模型。
- 管理者可在有角色權限的後台處理資料，而不是依賴分散的信件與試算表。
- 新名單通知、來源與操作狀態都保留在可追蹤的系統流程中。
技術
- Go
- PostgreSQL
- Google Cloud Run
- Cloud SQL
- Meta Webhooks
回頭看
如果重來，我們會在第一版就把資料保留期限與最小權限矩陣寫進需求。這些不是上線後再補的管理細節，而是名單系統是否值得信任的一部分。