昨天講了「身分是事實、帳號是聚合」——但把身分綁到帳號這一步,有一堵 FB 親手砌的牆。

FB 不讓你知道他是誰:ASID 與 PSID

真正的大魔王在綁定這一步。FB 的隱私設計是:同一個人,在不同表面有不同的 id——留言與 Messenger 給的是 PSID(page-scoped id),客人用 FB 登入你的 app 拿到的是 ASID(app-scoped id),兩者無法互推。這不是 bug,是 FB 立的牆:它不想讓你把「粉專的留言者」和「你 app 的會員」隨意串起來。官方留的窄門是 Business Mapping API(ids_for_pages / ids_for_apps),要求 app 和粉專掛在同一個 Business Manager、通過商業驗證——而且覆蓋率永遠不是 100%。

所以綁定做成了一個漏斗,一層收一批:

第二層值得特別停一下。得標通知本來就要發(private reply 私訊客人「你買到了」),在通知裡附一條帶一次性 token 的連結,客人點進去登入的那一刻,你同時握有 PSID(私訊通道)和 ASID(登入)——綁定是確定性的,不用猜。把「配對問題」轉化成「流程問題」,跟上一章把「下單意圖判斷」轉化成 DB lookup 是同一招:難題不硬解,把它變成另一個好解的問題。 每一筆成交都在自動收斂未綁定的尾巴,剩下的才輪到人工。

綁定的現實:家人的帳號

一個真實案例:有位客人用自己的 FB 喊單,結帳時用電腦登入的卻一直是家人的帳號。單掛在他的 fb user 上,帳號卻是另一個人的——最後靠客服做多重綁定收場:把兩個身分都掛到同一個 account 下,單就全齊了。

這個案例是 identity 模型最好的證詞:

• identity ≠ person。 一個人會頂著多個身分出現:自己的 FB、家人的帳號、換了平台的新 id。系統裡沒有「人」這個實體,只有身分和聚合。
• account 對 identity 必須是 1:N,而且 N 會成長。 多重綁定不是 workaround,是模型本來就該長這樣。
• 最妙的是:「帳號合併」這個惡名昭彰的難題,被 1:N 模型整個繞開了。 兩個身分各自累積了訂單、後來發現是同一人——傳統做法要把兩個 account 合併,那是一次不可逆的資料遷移,衝突處理跟多主複寫的衝突解決一樣讓人頭皮發麻。而在「訂單掛 identity、account 只聚合」的模型裡,答案是多綁一條關聯,一行 insert,隨時可撤。合併是搬家,聚合是加名牌——能用加名牌解決的,永遠不要搬家。

當然,綁定就是授權——把一個身分掛進 account,等於把那個身分名下的單交給這個帳號。綁錯人,就是把別人的訂單搬走。這條風險線留給風控那章。

重來,身分層會怎麼改

老實說,這章的當年設計我幾乎全數保留:分層是對的、訂單掛身分是對的、漏斗是對的、1:N 是對的。重來只補三件事:

1. 把 identity 正名成一層。 當年 fb user 是具體的表,IG 的對應問題由別的同仁處理、自建又是另一套——重來會先立一個統一的 identity 介面(source + external id + 各源 metadata),fb/ig/自建都是它的實例。命名這件事看似務虛,實際上決定了下一個平台接進來時,是「加一種 identity」還是「再蓋一套」。
2. 綁定關聯要帶出身:bound_via(auto / token / manual)、時間、操作者。 客服人工綁定尤其要留 audit——綁定就是授權,人工通道是最容易出錯也最難追責的一條。這同時是權限章和風控章的接點。
3. 把漏斗做成儀表板。 每一層的綁定率是產品指標,不是工程內幕:自動層掉了是 API 出問題、token 層掉了是通知沒送到、人工層積壓是客服要加人。殘量進工單系統排隊,而不是散在客服的訊息裡。1% 的人工不是設計失敗,是漏斗的自然殘留——但它必須可見、可排隊、可追蹤。

反思

平台的牆,決定你的下限;流程設計,決定你的上限

ASID/PSID 那堵牆我們翻不過去——FB 不給的配對,拿不到就是拿不到。但「得標通知附 token」讓大多數的綁定根本不需要那堵牆開門:使用者自己走過來,把兩個身分接在一起。做跨平台產品久了會明白:你的身分模型的下限,由平台願意給你什麼決定;上限,由你的流程替使用者鋪了什麼路決定。 抱怨 API 限制沒有生產力,把每個必經的觸點(通知、結帳、客服)都變成綁定機會,才有。

那 1% 的人工,值得被當成正式功能對待

漏斗收不乾淨的殘量,最後是客服一筆一筆人工綁掉的——包括家人帳號那種機器永遠猜不對的案子。這裡要幫當年記上一筆做對的事:我們的客服工具是當正式功能做的,而且好用。這個團隊的起源,本來就是老闆受夠了難用的第三方工具、決定自己做一套更好的;團隊裡不少 Grindr 出身的工程師,工程品質之外極度在意 UX——內部工具從第一天就是一級公民,多重綁定、調整購物車都有順手的介面。所以客服的累,累在案件本身難(家人帳號要不要綁,是判斷題,不是操作題),而不是工具在扯後腿。這件事影響了我後來的判斷:多數公司把內部工具當次等公民、「能動就好」,但客服的操作效率就是客訴的回應速度,內部工具的 UX 是外部體驗的一部分。工程師的本能是把 1% 自動化成 0.1%,但永遠會有系統接不住的最後一哩,預先為「由人來做」設計好介面,是成熟系統的標誌——這也是我後來帶 SRE 團隊時反覆講的:自動化的終點不是取代人,是讓人只處理值得人處理的事。

明天進系統的心臟:庫存——不能超賣,是唯一的鐵律。

本文改寫自我的部落格系列《Re:從零開始做直播代購電商平台》,本篇完整版:https://blog.aidan.tw/blog/rezero-identity/