在你的登陸頁上使用 Customer.io
Customer.io 知道某人剛做了什麼時，最能發揮作用。示範申請、候補名單註冊或完成的問卷正是這種訊號，但登陸頁不在你的產品裡時，這個訊號往往來得太晚，甚至根本沒來。
LanderLab 的 Webhook 會把每筆名單發到 Customer.io 的 Track API，一次請求就能識別人員、把答案與廣告活動記為屬性，並記錄一個事件，例如 lead_submitted，讓事件觸發的行銷活動據以啟動。中間沒有 Zap。
這個組合適合從 LinkedIn 與 Google 預約示範的 SaaS 團隊、在 Meta 上累積註冊的金融科技與消費型 App，以及希望問卷名單和電子報訂閱者收到不同序列的電商品牌。
來自付費流量的 Customer.io 人員與事件
Customer.io 的 Track API 能在一個批次中接收一位人員與一個事件。人員以電子郵件識別，帶著名單的屬性；事件則依你的廣告活動要監聽的名稱命名。如果 Customer.io 之前沒見過這位人員，就會建立他。
這樣登陸頁就成了你產品資料的一部分。你用在 App 內行為的那些行銷活動、分群與報表，現在也涵蓋廣告帶進來的人。
由事件觸發的示範申請與註冊行銷活動
LinkedIn 廣告帶來的示範申請，值得的不只是一封制式自動回覆。事件記在個人檔案上，Customer.io 行銷活動就能確認申請、隔天寄出該名單所屬產業的案例分享，對方若還沒預約就再跟進一次。
對消費型 App 來說，同一個事件可以先啟動電子郵件的候補名單序列，等對方安裝 App 後改用推播。
記在 Customer.io 個人檔案上的歸因
隱藏欄位會保留廣告網址上的 utm_source、utm_campaign 與 click ID，LanderLab 再加上頁面與版本。把它們作為屬性送出，你就能為來自某個廣告活動的所有名單建立分群、依廣告組合比較啟用率，或查看哪個頁面版本帶來了完成轉換的使用者。
名單進到 Customer.io 之前，先依答案分派
在 LanderLab 工作流程（Beta 版）中，依公司規模或方案設定的「多分支」可以從不同的「HTTP 請求」節點送出不同的事件，「篩選」則能擋下你市場以外的名單。執行紀錄檢視會顯示每筆名單的路徑，你就能清楚看到某人為什麼收到那個行銷活動。
