什麼是Account Linking？🤔

這要先來談談Messenger Chatbot用戶識別資料產生的方式，Messenger Chatbot最大的優勢之一就是替用戶產生一個可識別的身份是非常容易的，一但你的用戶在您的聊天機器人中點擊下Get Started（開始使用）按鈕或是進行過任何會在Page Webhook中產生資料的互動（發送訊息、點擊過或觸發Postback的按鈕甚至是只要按一個讚），你就有辦法取得一個名為PSID（Page-scoped user id）的用戶編號，然後在您的資料庫中用這PSID當作用戶身份的識別編號去關聯用戶在您Chatbot中所有的商業邏輯。

擁有了這PSID，您就可以伴隨著Page的Access Token去讀取該PSID所代表的用戶的一些基本資料，像是First name、Last name、Full name、Profile Picture鄧等等，甚至你還能透過PSID取得用戶的性別、時區以及語系，然而因為Facebook去年進行了一系列的隱私權政策調整，目前要透過PSID讀取用戶的性別、時區以及語系等資料都需要進行Page-level的權限審查，如果你有興趣，可以去你聊天機器人的粉絲團中的

Page > Settings > Messenger Platform > Advanced Messaging Features 中去進行權限的送審

這個對目前沒有網站、APP的企業主來說，透過聊天機器人這快速產生用戶識別資料的機制去建立起他們第一批用戶基礎絕對是一個非常好的方法，但如果你的公司擁有一個或多個經營多年的網站、APP，並已在這些年辛勞的經營下累積了許多會員資料在您的客戶關係管理系統中，這時如何連結您在聊天機器人中累積起的大量PSID與您CRM系統中累積多年的用戶資料，就成為一個必須去思考的議題，因為用戶在聊天機器人中所產生的行為資料很有機會讓您更加的去了解您的用戶。

因此！Messenger提出了Account Linking這一個機制來去解決連結Chatbot內用戶PSID與企業內部CRM中用戶資料的問題

Account Linking如何運作？

1. 首先，您要建立一個專門提供聊天機器人用戶進行Account Linking的會員登入頁在您的網站上
2. 將您用來進行Account Linking的URL輸入由Messenger Platform所提供的 Login Button 中的 url 參數裡，目前 Login Button 可用在以下四種 Messenger 的預設樣板中
   1. Generic template
   2. List template
   3. Button template
   4. Media template
3. 將綁定上了 Login Button 的樣版透過PSID發送給用戶
4. 綁定了 Login Button 的 樣版如下圖所示（要注意的是，Login Button上的Login字樣是預設且無法修改的）
5. 點擊這一個Button Template上的Log In按鈕之後，Messenger會開啟我綁定在該Login Button上用來進行Account Linking的客製化登入到達頁
6. 這個頁面乍看上跟一般的網頁沒有什麼不同，但重點在這個頁面的URL上，如下圖所示
   我們可以看到當用戶點擊Login Button之後，Messenger會自動的在開啟的URL後面附加上兩個參數，分別是 account_linking_token 以及 redirect_uri
7. 如果要在進行用戶身份驗證的當下取得正在進行Account Linking的PSID的話，我們可以將Login Button附加在URL後的 account_linking_token 一併傳入Server-Side，並用 account_linking_token 去讀取出其所代表的 PSID，API使用方式非常簡單，就使用傳送到Server-Side的account_linking_token伴隨著相對應的Page Access token發送到 https://graph.facebook.com/v3.3/me 這個端點就好
8. 當用戶在我所提供的自定義登入頁完成身份驗證之後，我們要從Server-Side去生成一個自定義的 authorization_code，並將其附加在由 Login Button 所產生的 redirect_uri 上面，然後執行頁面的 redirect
9. 如果過程一切順利，當你成功的將用戶重導向到你附加上 authorization_code 的 redirect_uri 後，您會在 Page 的 Webhook 收到一個名為”messaging_account_linking“的事件，該事件將會收到用戶的PSID以及您所附加在 redirect_url 後的 authorization_code
10. 通常我們會在 Webhook 收到 authorization_code 之後回過頭去資料庫查詢這組 authorization_code 是否存在，用以驗證是一次成功的 Account Linking
11. 在 Webhook 收到的 authorization_code 除了驗證的用途之外，還可以透過他來讀取究竟聊天機器人用戶的 PSID 連結到了網站或是APP客戶關係管理資料中的哪一位用戶
12. 透過這樣在聊天機器人與自有網站間資料拋轉來進行PSID與自有客戶關係管理系統間帳號的單向或雙向綁定的機制，就是所謂的 Account Linking 現行運作機制

有人在用Account Linking嗎？🤔

誒 … 老實說，在台灣我非常少看到有人在用Account Linking進行Bor與Web間雙向的資料綁定，甚至這項功能在開發者間也是鮮少有人聞問，當然這也是我撰寫這篇文章主要的目的，市場是需要更多人來協助進行教育的，畢竟，用戶在Bot內的行為資料若是整理得好的話，是能夠讓商家CRM裡的資料更加多元與豐富的。

那！今年F8有端出什麼新菜色嗎？

嘿嘿！就是因為有新搞頭我才把這鮮少有人在用的功能重新搬出來講呀，而這道新菜色的名字叫做 Authentication

什麼是Authentication？🤔

經過先前的說明我們可以看到，現行Account Linking的機制是由Bot內觸發的，透過在Bot內啟動一個Login Bouutn去開啟一個廠商自行設計的驗證到達頁，並在該驗證頁中完成用戶的身份驗證之後再將CRM用戶資料與用戶在Bot內的PSID進行綁定然後將用戶重新引導回Bot內。

Authentication 則是從另一個方向啟動Bot與Web或是App間的帳號綁定流程，Authentication 利用了 m.me 的機制，詳細實作方式尚未有官方文件來進行說明，但透過F8 session的Slide中可看到

網站主可以在網站或是App上放置一個Button去開啟一個特殊的 m.me link，該 m.me link 會將用戶從網站引導進入 Bot，猜想 Page 的 Webhook 會收到一個特殊的新事件（也有可能是用既有的事件然後在payload中加上新的property）並在收到的 payload 中會含有用來進行雙向帳號綁定的驗證資料，然後網站主或是開發者用收到的 payload 中的驗證資料來完成 Bot 與 Web 或是 App 間的帳號綁定，不過這都還只是猜測，要等文件正式上線時才能知道實際的運作方式。

小結一下

在可見的未來，Bot與網站、App間資料的交換與整合將會愈來愈重要，看得出Messenger這個平台在協助在其上面的商家與開發者打破資料整合Silo的問題也一直在做努力，就目前現有的機制再加上未來將會推出的 Authentication，讓開發者進行Bot與Web、App間雙向資料綁定的機制就有以下三種

• Account Linking
• Authentication
• WebView Extension

透過這些機制，要去做到不同即時通訊平台間Bot資料的相互整合與任務的交握似乎也不是不可能，腦洞更大開一點，也許下一階段將要發生的就會是跨平台 Bot 間的整合也說不定，就讓我們繼續在這才剛開始的道上進行的探索新的可能性吧！