clickSomo

SaaS 同產品團隊

你個產品知道啲嘢,係冇任何營銷工具睇得到嘅

邊個完成咗新手流程,邊個喺第三步卡咗。邊個邀請咗同事。邊個今個禮拜撞咗兩次上限。邊個成兩個禮拜冇開過嗰樣嘢。每一樣都係比電郵開封率好嘅觸發條件,而且全部都係兩行程式碼之遙。

事件就係成個整合

POST /v1/events 用你自己嘅 token:一個你自己改嘅名、一個聯絡人、一個內容、一個 idempotency key。成個連接就係咁多。冇 SDK 要你追更新,冇對應畫面,亦都冇我哋自己嗰套詞彙要你將個產生硬譯過去。

每個事件都會記落聯絡人個只加唔減嘅紀錄度,而喺嗰度佢同時係三樣嘢。一個觸發條件,令漏斗喺佢到達嗰刻開始。一個條件,令分段可以話「最近十四日做過呢樣」或者,更加有用嘅係,「冇做過」。仲有一個目標,令個序列喺有人做到佢一直推嗰樣嘢嗰一刻就完。

第三樣就係令生命週期訊息收到唔覺得煩嘅關鍵。叫你完成設定帳戶嗰個提示,應該喺帳戶設定好嗰一秒就消失,但喺大部分工具入面佢唔會,因為個序列同個產品根本冇傾過偈。

啟動第 2 118 次執行
  • ⚡觸發條件api_event — signup.completed,方案 free。
  • 2發電郵第一件要做嘅事。唔係十一個功能嘅導覽。
  • 3等兩日執行上面嘅 wake_at。冇嘢排住隊,聽日你改寫咗都唔使拆嘢。
  • ?條件project.created 到咗未?未 → 幫助分支。到咗 → 下面嗰個目標。
  • 4幫助分支一個訊息,直接提佢漏咗做嗰樣嘢。然後再等一次。
  • 5目標project.created 嚟到。個 run 退出。呢個人以後唔會再收到任何 onboarding 電郵。

你嘅事件名稱你對「已啟用」嘅定義

五個漏斗

生命週期,照實際發生嘅次序

1 · 啟用

觸發條件:註冊。兩至三個訊息,每個針對一個動作,每個都有一個目標,當嗰個動作發生時就完結成個序列。呢個係你會起嘅最有價值漏斗,亦係最值得改三次嗰個。

2 · 停滯

觸發條件:segment_enter — 已註冊,但七日內冇任何有意義嘅事件。一個係問而唔係講嘅訊息,再加一個提供具體嘢嘅訊息。然後就停手。對一個已經無視咗三個訊息嘅人發第四個,等於對住冇人講嘢。

3 · 擴張時刻

觸發條件:一個代表佢哋攞到價值嘅事件 — 撞到上限、邀請咗第三個同事、第二次匯出。呢個係唯一一個升級訊息會受歡迎嘅時刻,而且你嘅產品可以精確講出呢個時刻係幾時。

4 · 續期同追數

觸發條件:續期前嘅 date_field,或者一個付款事件。通知、提醒,仲有 — 如果付款失敗 — 一個喺成功嗰一刻即刻停嘅短序列。喺追數入面目標節點唔係可有可冇;佢係「提醒」同「滋擾」嘅分別。

5 · 搵返舊客

觸發條件:segment_enter — 取消咗或者休眠咗六十日。兩個訊息,老實嗰種,然後打個 tag 同收聲。「佢哋走咗之後有咩改變」係一個好過「畀你折扣」嘅訊息。

仲有內部嗰個

notify_team 會喺一個值得人手跟進嘅帳戶越過某條線嗰陣通知一個真人。漏斗唔一定要以一封電郵畀客戶收尾;有時啱嘅動作係叫你自己嗰邊嘅某人攞起電話。

冇人係故意流失嘅。佢哋只係唔再打開佢。

點解開發者可能真係會鍾意呢樣嘢

當你係嗰個做整合嘅人嗰陣,真正要緊嘅部分

冇私人端點

每個畫面都可以用公開 API 起出嚟,因為根本冇第二種。如果你想喺自己嘅 admin 入面嵌入一個 campaign 報告,冇嘢阻住你,亦都唔使逆向工程。

冚唪唥都有冪等鍵

每條會改嘢嘅 route 都有。你嘅重試邏輯、你嘅 at-least-once queue 同你個唔穩陣嘅網絡,全部變成第個人嘅問題 — 具體嚟講,係一個 unique index 嘅問題。

出貨之前先模擬

POST /v1/simulate 會將一個聯絡人乾跑一次漏斗,然後回傳路徑同佢會發嘅每一個訊息。鍾意嘅話可以擺入 CI:漏斗係一個圖,而圖係可以測試嘅。

一個 MCP server

將一個 agent 指向 /mcp,畀佢撰寫同檢查漏斗。可以發送嘅工具需要明確確認,而且受配額限制,所以一個讀錯嘅 prompt 唔會變成五萬封電郵。

Webhook 輸出

有簽名、用 backoff 重試、至少送一次。同報告用嘅同一套事件詞彙,所以你嘅 warehouse 同你嘅 dashboard 唔會對「已送達」嘅意思有分歧。

真係去到嘅刪除

一個刪除請求會喺度移除嗰個聯絡人同佢嘅訊息歷史,並且擴散到每一個持有副本嘅姊妹服務。一個請求,一個結果,仲有一樣嘢畀人問嗰陣你可以指得出嚟。

邊界喺邊

ClickSomo 持有一個郵寄名單,同埋嗰個名單做過嘅嘢。佢唔係你嘅用戶資料庫,亦都冇打算做:一個聯絡人永遠唔會帶憑證、永遠唔會登入、永遠唔會變成一個帳戶。你嘅用戶住喺你嘅產品度;聯絡人住喺度,兩者靠一個電郵地址同你揀嚟發嘅事件連埋一齊。

呢個分離係刻意嘅,亦係同意模型行得通嘅原因。你係你嘅用戶嘅資料控制者;我哋代你處理。一個令行銷工具靜靜雞變成身份儲存庫嘅設計,係之後冇得拆返開嘅,而呢個正正係呢個設計要避免嘅失敗。

實際版本:發事件,發你想用嚟分眾嘅屬性,其餘嘅嘢留喺原處。如果你發現自己成個 schema 都推晒入嚟,咁你想起嘅嗰個分眾,好可能其實係你自己資料庫入面一條查詢,應該以一個 boolean 屬性嘅形式送過嚟先啱。