在你的登陸頁上使用 Supabase
認真的名單開發業者，最後都會想把原始資料放進自己掌控的資料庫：把名單和花費 join、用 SQL 分析名單品質、供應買家入口或業務應用程式。建置接收名單的端點通常是卡住的那一步，因為得有人寫，還得讓它一直跑。
Supabase 省掉了這一步。每個資料表本來就有 REST 端點，LanderLab 的 Webhook 把每筆名單以一組扁平的欄位名稱與值發送過去。Postgres 寫入這一列，Row Level Security 決定這個請求能做什麼，名單就帶著廣告活動與版本進到你的資料庫。
每筆名單一列 Postgres，用你的結構
請求內容是扁平的，一個鍵對應一欄，所以每筆名單都會成為一列有類型的欄位，created_at 時間戳記來自欄位預設值，還有一個你其他系統可以參照的 id。對應不到任何欄的鍵會被拒絕，雜亂的資料就進不了資料表。
因為是 Postgres，這一列隨時能做 SQL 能做的任何事：每天每個廣告活動的名單檢視、和你的成本資料表 join，或者如果你寧可拒絕重複送出也不想存兩次，就在 email 上加唯一索引。
用 Row Level Security 鎖好
Webhook 使用你專案的 publishable key 寫入，由 Row Level Security 決定這把金鑰能做什麼。只允許對名單資料表新增、其他一律不行，這把金鑰就能新增名單，卻永遠無法讀取、修改或刪除它們，所以即使金鑰不是機密，名單資料仍然碰不到。
會繞過 Row Level Security 的 secret key 永遠不必離開你自己的後端：名單表單用不到它。
屬於你自己的名單品質真實來源
建置工具、CRM 與追蹤工具各自只掌握一部分。一個存有每筆名單及其 utm_campaign、click ID、登陸頁與版本的 Supabase 資料表，就是你能掌控的那一部分。把每日花費載入第二個資料表，一個 SQL 檢視就能依廣告活動與版本算出單筆名單成本；再加上買家或業務記錄的結果，就能算出每筆成交成本。
這才是判定分流測試的誠實方式：不是看哪個版本拿到更多表單填寫，而是看哪個版本的名單變成了錢。
寫入失敗，名單也不會遺失
每筆名單也都保存在 LanderLab 的「潛在客戶」分頁，可依日期與版本篩選，Grow 以上方案可匯出 CSV，除非開啟了「合規潛在客戶投遞」。如果寫入失敗，例如某個欄被改了名稱，名單也不會消失：修好資料表，再從匯出檔回填。若改透過 LanderLab 工作流程（Beta 版）傳送，執行紀錄檢視會準確顯示是哪筆名單的請求失敗了。
