在你的登陸頁上使用 PostHog
大多數 PostHog 專案都從註冊開始，這代表帶來使用者的那則廣告只能用猜的。LanderLab 的 Webhook 把起點往前移到廣告。每筆名單都會以事件送到 PostHog 的 capture 端點，表單答案、頁面、UTM 與訪客 IP 作為屬性，這個人的電子郵件與姓名則設定在他的人員檔案上。
它適合買流量的產品導向團隊：SaaS 試用、有候補名單的 App、招募供給端的交易平台。當名單與產品使用數據在 PostHog 中屬於同一個人，從廣告到啟用的漏斗就是一份報表，而不是一張試算表。
把登陸頁名單變成 PostHog 事件
每次送出都會在 PostHog 成為一個「Lead submitted」事件，表單欄位與問卷答案作為屬性。PostHog 自己的屬性也會填入：頁面記為 $current_url，訪客 IP 記為 $ip，所以地點來自這個人，而不是 LanderLab 的伺服器。
PostHog 的 capture 端點是公開且只能寫入的，它的專案 token 本來就可以公開，所以從 Webhook 送出完全不需要私密金鑰。
從表單取得人員屬性
在事件中，$set 會把電子郵件與姓名寫入這個人的檔案，$set_once 則保留他第一次轉換的登陸頁，即使他之後再次送出也不會改變。如果你的 App 用同一個電子郵件識別使用者，這筆名單和使用者在產品中做的一切，就都屬於同一個人。
從廣告開始的漏斗
名單事件上有 utm_source、utm_campaign 與 A/B 版本，PostHog 漏斗就能從登陸頁開始，結束在對你重要的行動：建立第一個專案、寄出第一張發票、升級方案。依廣告活動拆分，就能看出哪些廣告組合帶來會啟用的使用者，而不只是會註冊的使用者。
這是 LanderLab 自己做不到的測試：它的報表依名單評估版本，PostHog 則把評估延伸到這些名單接下來做了什麼。
用工作流程只送出值得追蹤的名單
不是每次送出都該進入產品分析。工作流程可以放在頁面與 PostHog 之間：只放行完成問卷的「篩選」、排除測試名單的「條件判斷」，再由「HTTP 請求」節點送出事件。執行紀錄檢視會顯示每筆名單的路徑，失敗的傳送看得到，而不是默默從漏斗中消失。
