落地页上的 Supabase
认真做线索获取的运营方，最终都想把原始数据放进一个自己掌控的数据库：把线索和花费关联起来，用 SQL 分析线索质量，为买家门户或销售应用供数。卡住的通常是搭建接收线索的端点这一步，因为得有人写它，还得让它一直跑着。
Supabase 把这一步省掉了。每张表本来就有一个 REST 端点，LanderLab 的 Webhook 把每条线索以一组扁平的列名和值投递过去。Postgres 插入这一行，Row Level Security 决定这个请求能做什么，线索就带着广告系列和变体进了你的数据库。
每条线索一行 Postgres，用你的表结构
请求体是扁平的，每列一个键，每条线索就成为一行带类型的数据，有一个来自列默认值的 created_at 时间戳，还有一个你其他系统可以引用的 id。匹配不到任何列的键会被拒绝，多余的数据就进不了表。
因为是 Postgres，这一行可以做 SQL 能做的任何事：按天、按广告系列统计线索的视图，与成本表的 join，或者在邮箱上建唯一索引，如果你宁愿拒收重复提交，而不是存两份。
用 Row Level Security 锁好
Webhook 用你项目的 publishable key 写入，由 Row Level Security 决定这个密钥能做什么。只允许在线索表上插入，其他一律不允许，这个密钥就只能添加线索，永远无法读取、修改或删除，即使密钥本身不是保密的，线索数据也无从触及。
可以绕过 Row Level Security 的 secret key，永远不必离开你自己的后端：线索表单用不着它。
你自己的线索质量唯一可信来源
搭建工具、CRM 和追踪工具各自只掌握一部分情况。一张存着每条线索及其 utm_campaign、点击 ID、落地页和变体的 Supabase 表，就是你自己掌控的那部分。把每日花费导入第二张表，一个 SQL 视图就能按广告系列和变体给出单条线索成本；再加上买家或销售记录的结果，就能得到单笔成交成本。
这才是判定 A/B 测试的老实办法：不看哪个变体的表单提交更多，而看哪个变体的线索变成了钱。
插入失败，线索也不会丢
每条线索也都保存在 LanderLab 的线索标签页里，可按日期和变体筛选，Grow 及以上套餐可导出为 CSV（除非开启了“合规线索投递”）。如果某次插入失败了，比如在某一列改名之后，线索并没有丢：修好表，再用导出文件补录。改为通过 LanderLab 工作流（Beta）发送，运行视图还会准确显示是哪条线索的请求失败了。
