同一個客人，LINE 叫陳先生、Messenger 卻叫 David：用 API 縫合破碎的用戶身分

同一位客戶，在 Facebook Messenger 上是用英文發問的活潑 David，到了 LINE 官方帳號卻變成畢恭畢敬詢問訂單的「陳先生」——而系統完全不知道他們是同一個人。客服每次都得重問一遍基本資料，行銷數據也被切成互不相認的兩半。這篇就來拆解如何用 API 把這些破碎的用戶身分縫合起來，打造無斷點的客服體驗。

這不只是造成客服人員的困擾，更是數據分析的惡夢。我們無法建立完整的用戶輪廓，行銷活動的成效追蹤變得支離破碎，個人化推薦更是無從談起。這道由平台築起的高牆，讓我們的使用者數據變成一座座孤島。今天，我就要帶你拿起 API 這把鎚子，把這座牆給敲掉。

數據孤島的代價：當你的 CRM 變成臉盲

身為一個工程師，我最受不了的就是「冗餘」和「不一致」。當我看著資料庫裡，一個 email 為 `david.chen@example.com` 的使用者，同時對應著一組 `fb_psid_xxxxxxxx` 和另一組 `line_user_id_yyyyyyyy`，但這兩組 ID 之間卻沒有任何關聯時，我的程式碼潔癖就會發作。這不只是感覺不對勁而已，它實實在在地影響著商業運作：

• 重複的客服溝通： 客戶在 Facebook 問完 A 問題，又跑到 LINE 問 B 問題，客服人員因為無法識別身分，很可能需要客戶重複提供資訊，體驗極差。
• 行銷預算浪費： 你可能在兩個平台上對同一個人投放了兩次一樣的廣告，因為你的系統認為這是兩個不同的受眾。
• 破碎的用戶旅程： 你無法知道這位「陳先生」是不是因為看了 Facebook 的廣告才來 LINE 上詢問。用戶旅程的關鍵斷點，讓你的歸因分析形同虛設。
• 個人化體驗的泡影： 想要根據用戶在官網的瀏覽紀錄，在 LINE 上做精準的產品推薦？抱歉，系統不知道官網上的會員跟 LINE 上的使用者是同一位。

這些問題的根源，就是缺乏一個「單一事實來源 (Single Source of Truth)」。我們需要一個中央大腦，告訴我們，無論這位使用者在哪個平台出現，他都是我們認識的那位獨一無二的客戶。

技術藍圖：用 WordPress 打造你的用戶數據中樞

要把散落在各處的用戶身分縫合起來，我們的核心戰場就在自己的主場——WordPress 網站。概念其實很直接：以 WordPress 的使用者系統（或是一個客製化的資料庫）為核心，建立一個「身分對應表」，將不同平台的用戶 ID（Facebook 的 PSID、LINE 的 User ID）全部連結到同一個主帳號上。

第一步：打好地基 - 建立身分對應表

囉嗦一下，直接操作 `wp_usermeta` 來存這些外部 ID 不是不行，但當平台一多，或是需要更複雜的查詢時，效能和管理上都會是個災難。我強烈建議建立一個專門的資料表來處理這件事。一個簡單的結構可能像這樣：

CREATE TABLE `user_platform_identities` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) unsigned NOT NULL COMMENT '對應到 wp_users.ID',
  `platform` varchar(50) NOT NULL COMMENT '平台名稱，例如 facebook, line',
  `platform_user_id` varchar(255) NOT NULL COMMENT '平台上的使用者唯一 ID',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `platform_identity` (`platform`,`platform_user_id`),
  KEY `user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

這個表的設計有幾個好處：`user_id` 讓我們可以快速關聯回 WordPress 的使用者；`platform` 和 `platform_user_id` 的唯一索引 (UNIQUE KEY) 確保了不會有重複的平台身分紀錄，效能也更好。

第二步：搭建橋樑 - 萬用 Webhook 接收器

接下來，我們需要在 WordPress 建立一個統一的入口，來接收來自 Facebook 和 LINE 的訊息事件。這就是 Webhook 的主場。我們可以用 WordPress 的 REST API 功能來快速建立一個客製化端點 (Endpoint)。

把這段程式碼加到你的主題 `functions.php` 或是自訂外掛中：

add_action( 'rest_api_init', function () {
    register_rest_route( 'my-chatbot/v1', '/webhook', array(
        'methods'  => 'POST',
        'callback' => 'handle_universal_webhook',
        'permission_callback' => '__return_true' // 注意：正式環境務必加上驗證！
    ) );
} );

function handle_universal_webhook( WP_REST_Request $request ) {
    // 步驟 1: 識別請求來源是 Facebook 還是 LINE
    $headers = $request->get_headers();
    $body = $request->get_body();
    $data = json_decode($body, true);

    // 檢查 LINE 的簽名
    if ( isset($headers['x_line_signature']) ) {
        // 這裡是 LINE 的驗證與處理邏輯
        // ... 驗證 channel secret ...
        $line_user_id = $data['events'][0]['source']['userId'];
        $user = get_user_by_platform_id('line', $line_user_id);
        // ... 後續處理 ...
        return new WP_REST_Response( 'LINE event received.', 200 );
    }

    // 檢查 Facebook 的簽名 (或結構)
    if ( isset($data['object']) && $data['object'] === 'page' ) {
        // 這裡是 Facebook 的驗證與處理邏輯
        // ... 驗證 App Secret ...
        $fb_psid = $data['entry'][0]['messaging'][0]['sender']['id'];
        $user = get_user_by_platform_id('facebook', $fb_psid);
        // ... 後續處理 ...
        return new WP_REST_Response( 'Facebook event received.', 200 );
    }

    // 如果來源不明，回傳錯誤
    return new WP_Error( 'unknown_source', 'Cannot identify webhook source.', array( 'status' => 400 ) );
}

// 輔助函式：根據平台 ID 尋找 WordPress 使用者
function get_user_by_platform_id( $platform, $platform_id ) {
    global $wpdb;
    $table_name = 'user_platform_identities'; // 你自訂的資料表名稱

    $user_id = $wpdb->get_var( $wpdb->prepare(
        "SELECT user_id FROM {$table_name} WHERE platform = %s AND platform_user_id = %s",
        $platform,
        $platform_id
    ) );

    if ( ! $user_id ) {
        return null; // 找不到對應的使用者
    }

    return get_user_by( 'id', $user_id );
}

上面的程式碼是一個骨架，它建立了一個 `/wp-json/my-chatbot/v1/webhook` 的端點。當收到請求時，它會嘗試判斷是來自 LINE 還是 Facebook，然後呼叫 `get_user_by_platform_id` 這個輔助函式去我們自訂的資料表裡尋找對應的 WordPress 使用者。找到之後，你就可以拿到該使用者的所有資訊（例如 email、姓名、會員等級等），實現真正的個人化互動。

第三步：關鍵的握手 - 如何完成身分綁定？

有了基礎建設，最關鍵的問題來了：系統怎麼知道 `line_user_id_yyyyyyyy` 和 `fb_psid_xxxxxxxx` 其實都對應到 `user_id` 為 123 的使用者？我們必須引導使用者完成一次「綁定」的動作。常見的作法有幾種：

• 網頁登入綁定： 在使用者登入 WordPress 網站後，提供按鈕讓他們連結自己的 LINE 或 Facebook 帳號。這通常是透過 LINE Login 或 Facebook Login API 來實現，使用者授權後，你就能同時拿到他的 WordPress 使用者身分和平台 ID，進而寫入對應表。
• 聊天機器人引導綁定： 當一個新的、未知的平台 ID 傳訊息進來時，聊天機器人可以啟動一個引導流程，例如：「您好，為了提供更完整的服務，請輸入您註冊的會員 Email 來綁定帳號。」使用者輸入 Email 後，系統驗證無誤，就可以將這個平台 ID 跟該 Email 對應的 WordPress 使用者綁定在一起。
• 透過專屬連結： 從 Email 或會員後台發送一個包含使用者專屬 token 的連結，引導他們點擊後開啟 LINE 或 Messenger，點擊的當下，系統就能透過 token 識別 WordPress 使用者身分，並擷取當下的平台 ID 完成綁定。

無論哪種方法，核心都是要找到一個「共同的錨點」（例如 Email、手機號碼或會員 ID），才能把不同平台的浮標（平台 ID）串連起來。

實戰中的魔鬼細節：工程師的囉嗦提醒

概念很美好，但實際執行起來，有幾個坑你一定要避開：

1. 安全！安全！還是安全！

你的 Webhook 端點是暴露在公網上的，任何人都可以對它發送請求。如果沒有做好驗證，你的網站很快就會被垃圾請求淹沒，甚至被惡意利用。務必、務必、務必實作平台官方提供的簽名驗證機制！

• LINE: 驗證請求標頭 (Header) 中的 `X-Line-Signature`，需要用你的 Channel Secret 進行 HMAC-SHA256 驗證。
• Facebook: 驗證請求標頭中的 `X-Hub-Signature-256`，需要用你的 App Secret 進行 HMAC-SHA256 驗證。

沒有驗證的 Webhook，就像沒鎖門的金庫，是在邀請小偷光臨。

2. 隱私與授權的界線

在進行任何身分綁定之前，請務必清楚地告知使用者你將會做什麼、為什麼要這麼做，並取得他們的同意。例如，在綁定頁面明確寫出：「連結您的 LINE 帳號後，我們將能整合您在官網與 LINE 上的互動紀錄，以提供更貼近您需求的個人化服務。」這不只是使用者體驗的問題，更是法規（如 GDPR）的要求。

3. 處理「孤兒」用戶

總會有使用者直接從 LINE 或 Facebook 進來，他們在你的 WordPress 系統中還沒有帳號。你的系統邏輯必須能夠處理這種「尚未綁定」的狀態。你可以將他們暫時標記為潛在客戶，並在對話中溫和地引導他們註冊或綁定，而不是直接忽略他們。

結論：從破碎到整合，這不只是技術，更是策略

打破 Facebook Messenger 和 LINE OA 之間的圍牆，統一用戶身分，絕不只是一個酷炫的技術挑戰。它是一個能深刻影響企業營運效率與顧客關係的策略性舉措。當你能真正看到一個用戶的全貌時，你的客服才能從「請問您是哪位？」進化到「陳先生您好，看到您上次詢問的 A 商品我們已經補貨了，需要幫您留一組嗎？」。

這背後需要的，是穩固的後端架構、安全的 API 實作，以及對使用者體驗的細膩考量。這條路可能有點複雜，但它通往的是一個更智慧、更高效、也更人性化的數位互動未來。

延伸閱讀

• n8n、Make、Zapier 怎麼選？2026 自動化平台完整比較
• WordPress 不再是孤島！資深工程師帶你串接 LINE / HubSpot / n8n，打造企業級自動化帝國
• 別再用「貴賓」稱呼每個人！WordPress + CRM 終極聯動，打造看人下菜碟的『智慧文案』系統
• 活動名單還在手動 Key-in？揭秘 WordPress + CRM 自動分流術，讓你的業務線索『秒速』就位！

還在為破碎的客戶數據傷腦筋嗎？

打造一個能夠整合多平台用戶身分的系統，需要專業的技術規劃與滴水不漏的執行。如果你希望為你的企業建立一個 360 度的客戶視圖，但不知從何下手，歡迎與浪花科技的團隊聊聊。讓我們幫助您打破數據孤島，釋放您客戶數據的真正潛力。