台灣電商導入 HubSpot CRM：LINE 官方帳號自動化分眾完整教學

想讓 LINE 官方帳號的推播依 HubSpot 分眾自動發送，核心是三件事：用 LINE Login 取得 userId 並寫回 HubSpot 聯絡人屬性、以 Webhook 同步互動事件、再用 HubSpot Workflow 的 Custom Coded Action 呼叫 Messaging API 推播。以下是可直接照做的設定流程。

為什麼台灣電商非得把 LINE 綁進 CRM？

在台灣，LINE 不是「其中一個」渠道，而是幾乎等同於通訊層本身。依據 LINE for Business 台灣官方公布的資料，LINE 在台灣的月活躍用戶數超過 2,100 萬,滲透率在主要市場中名列前茅。對電商而言,這代表 EDM 開信率再怎麼優化,都很難追上 LINE 訊息的觸及。

但 LINE 官方帳號原生的分眾能力有天花板:

• 標籤(Tag)靠人工或有限自動化,難以反映 RFM、購物車金額、退貨紀錄等交易資料。
• 推播成本按訊息量計費,亂槍打鳥的群發會直接吃掉行銷預算。依 LINE 官方帳號的計價結構,超出免費訊息額度後每則加購訊息都需付費,因此「分眾精準度」直接等於「單位成本」。
• 跨渠道身分無法統一:同一位客人在網站是 email,在 LINE 是 userId,在 POS 是手機號碼。

HubSpot 的角色就是把這三種識別碼收斂成單一聯絡人紀錄,再把「誰該收到什麼訊息」的判斷邏輯放在 CRM 裡,而 LINE 只負責投遞。這個架構我們在香港、新加坡、台灣三地的專案中反覆使用——差別只在投遞層換成 WhatsApp Business Platform 或 LINE。

事前準備清單

開工前請確認以下項目齊備,缺一項後面都會卡住:

1. LINE 官方帳號(認證帳號或企業帳號),並已在 LINE Official Account Manager 開啟 Messaging API。
2. LINE Developers Console 上的 Provider,底下需要兩個 Channel:一個 Messaging API channel、一個 LINE Login channel。
3. Channel access token(long-lived) 與 Channel secret,兩者都要妥善保管。
4. HubSpot Marketing Hub Professional 或以上——Custom Coded Action 與 Programmable Automation 僅在 Professional/Enterprise 提供,依 HubSpot 官方定價頁說明。
5. HubSpot Private App token,scope 至少包含 crm.objects.contacts.read、crm.objects.contacts.write。
6. 一個可公開存取的 HTTPS endpoint(Cloudflare Workers、AWS Lambda + API Gateway、或 Vercel Functions 皆可)接收 LINE Webhook。LINE Developers 文件明訂 Webhook URL 必須為 HTTPS。
7. 電商平台的訂單資料能進 HubSpot:Shopify / Shopline / 91APP / 自建站皆可,透過原生整合或 Custom Object 寫入。

建議的技術堆疊

• Node.js 20 LTS + @line/bot-sdk(v9 以上)
• HubSpot API v3(@hubspot/api-client)
• 一個 KV / Redis 做 idempotency,避免 LINE 重送事件造成重複寫入

資料流長什麼樣子?

設定前先把方向搞清楚,可以省掉大量除錯時間。整套架構有三條資料流:

流向 A:身分綁定(LINE → HubSpot)

使用者點擊 LINE 圖文選單的「會員綁定」→ 開啟 LIFF 或 LINE Login 授權頁 → 你的後端拿到 userId 與(取得同意後的)email → 以 email 搜尋 HubSpot 聯絡人 → 寫入 line_user_id。

流向 B:行為與交易(電商 → HubSpot)

訂單、購物車、瀏覽事件寫入 HubSpot 聯絡人屬性或 Custom Object。分眾條件全部建立在這一層。

流向 C:推播(HubSpot → LINE)

HubSpot Workflow 觸發 → Custom Coded Action 讀取 line_user_id → 呼叫 POST /v2/bot/message/push → 回寫推播結果與時間戳。

關鍵原則:LINE 端不存判斷邏輯,HubSpot 端不存訊息模板以外的東西。這樣換渠道時只需改流向 C。

Step 1:建立 Channel 並取得憑證

在 LINE Developers Console 建立 Messaging API channel 後,到 Messaging API 分頁:

• 關閉「自動回應訊息」與「歡迎訊息」(這兩項會與你的 Webhook 邏輯打架)
• 開啟 Use webhook
• 發行 Channel access token (long-lived)

用 curl 驗證 token 是否有效:

1curl -v -X GET https://api.line.me/v2/bot/info \
2  -H "Authorization: Bearer {CHANNEL_ACCESS_TOKEN}"

預期輸出:

1{
2  "userId": "U0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
3  "basicId": "@123abcde",
4  "displayName": "Your Shop",
5  "chatMode": "bot",
6  "markAsReadMode": "manual"
7}

若 chatMode 回傳 chat,表示帳號仍在聊天模式,Webhook 事件會收不完整,需回 LINE Official Account Manager 切換為 Bot 模式。

Step 2:在 HubSpot 建立自訂屬性

到 Settings → Properties → Contact properties,新增以下欄位(建議統一放在一個 group,例如 LINE Integration):

• line_user_id — 單行文字,務必勾選 unique value(HubSpot 支援聯絡人層級唯一值屬性),避免同一 userId 綁到多筆聯絡人
• line_display_name — 單行文字
• line_linked_at — 日期時間
• line_opt_in — 單選(是/否)
• line_last_push_at — 日期時間
• line_push_failure_count — 數字
• line_rich_menu_segment — 單選(如 new、repeat、vip、churn_risk)

最後兩欄很容易被省略,但它們是後續除錯與圖文選單分眾的依據。line_push_failure_count 累積到門檻(例如 3)就自動排除推播,可避免對已封鎖帳號的無效訊息持續計費。

Step 3:接收 LINE Webhook 並寫回 HubSpot

以下是一個最小可用的 Node.js handler,含簽章驗證。簽章驗證不可省略——LINE Developers 文件明確要求以 Channel secret 對 request body 做 HMAC-SHA256 驗證,否則任何人都能偽造事件汙染你的 CRM。

1import crypto from "node:crypto";
2import express from "express";
3import { Client as HubSpotClient } from "@hubspot/api-client";
4
5const app = express();
6const hubspot = new HubSpotClient({ accessToken: process.env.HUBSPOT_TOKEN });
7
8app.post(
9  "/line/webhook",
10  express.raw({ type: "application/json" }),
11  async (req, res) => {
12    const signature = crypto
13      .createHmac("SHA256", process.env.LINE_CHANNEL_SECRET)
14      .update(req.body)
15      .digest("base64");
16
17    if (signature !== req.get("x-line-signature")) {
18      return res.status(401).send("invalid signature");
19    }
20
21    // 先回 200,再非同步處理,避免 LINE 逾時重送
22    res.status(200).end();
23
24    const { events } = JSON.parse(req.body.toString("utf8"));
25    for (const event of events) {
26      await handleEvent(event).catch((e) =>
27        console.error("[line-webhook]", event.type, e.message)
28      );
29    }
30  }
31);
32
33async function handleEvent(event) {
34  const userId = event.source?.userId;
35  if (!userId) return;
36
37  if (event.type === "follow") {
38    await upsertByLineUserId(userId, { line_opt_in: "true" });
39  }
40  if (event.type === "unfollow") {
41    await upsertByLineUserId(userId, { line_opt_in: "false" });
42  }
43}
44
45async function upsertByLineUserId(userId, extraProps) {
46  const search = await hubspot.crm.contacts.searchApi.doSearch({
47    filterGroups: [
48      {
49        filters: [
50          { propertyName: "line_user_id", operator: "EQ", value: userId },
51        ],
52      },
53    ],
54    properties: ["email", "line_user_id"],
55    limit: 1,
56  });
57
58  const props = {
59    line_user_id: userId,
60    line_linked_at: new Date().toISOString(),
61    ...extraProps,
62  };
63
64  if (search.results.length) {
65    await hubspot.crm.contacts.basicApi.update(search.results[0].id, {
66      properties: props,
67    });
68  } else {
69    await hubspot.crm.contacts.basicApi.create({ properties: props });
70  }
71}
72
73app.listen(3000);

預期輸出與驗證

部署後回到 LINE Developers Console,填入 Webhook URL 並按 Verify。成功會顯示 Success。接著用手機加入官方帳號好友,幾秒內 HubSpot 應出現一筆新聯絡人,line_user_id 已填入、line_opt_in = true。

若 Verify 顯示 The webhook returned an HTTP status code other than 200,九成是因為簽章驗證用了已被 express.json() 解析過的 body。務必使用 express.raw() 取得原始 bytes。

Step 4:把 email 與 userId 對接起來

單靠 follow 事件,你只會拿到匿名 userId。要把它接到既有會員,必須走 LINE Login 授權。在圖文選單放一個「綁定會員」按鈕,指向你的授權入口:

1https://access.line.me/oauth2/v2.1/authorize
2  ?response_type=code
3  &client_id={LOGIN_CHANNEL_ID}
4  &redirect_uri=https%3A%2F%2Fshop.example.com%2Fline%2Fcallback
5  &state={CSRF_TOKEN}
6  &scope=profile%20openid%20email

注意 email scope 需在 LINE Developers Console 另外申請開通。callback 端交換 token 後解析 id_token 取得 email:

1const tokenRes = await fetch("https://api.line.me/oauth2/v2.1/token", {
2  method: "POST",
3  headers: { "Content-Type": "application/x-www-form-urlencoded" },
4  body: new URLSearchParams({
5    grant_type: "authorization_code",
6    code,
7    redirect_uri: process.env.LINE_REDIRECT_URI,
8    client_id: process.env.LINE_LOGIN_CHANNEL_ID,
9    client_secret: process.env.LINE_LOGIN_CHANNEL_SECRET,
10  }),
11});
12
13const { id_token } = await tokenRes.json();
14// 以 LINE 提供的 /oauth2/v2.1/verify endpoint 驗證後取得 sub(userId)與 email

拿到 email 後,以 HubSpot 的 email 為 key 做 upsert,把 line_user_id 寫進既有聯絡人,而不是建新的一筆。這一步做不好,就會出現「同一個人兩筆紀錄」的經典髒資料問題。

一個實務提醒:我們在協助一家台灣與香港雙站經營的美妝零售商規劃這段流程時,遇到的最大障礙不是技術,而是綁定誘因設計。沒有明確的綁定回饋(例如綁定後才能查詢訂單狀態),line_user_id 的覆蓋率會低到讓後續分眾失去意義。技術要先於誘因設計完成,但上線順序應該相反。

Step 5:用 Active List 建立分眾

分眾邏輯全部放在 HubSpot 的 Active List(主動清單),條件範例:

沉睡喚回(churn_risk)

• line_opt_in = true 且
• line_user_id is known 且
• Last order date 早於 90 天前 且
• Lifetime order count ≥ 2

高價值客(vip)

• line_opt_in = true 且
• Lifetime revenue ≥ 你的第 90 百分位門檻 且
• line_push_failure_count < 3

棄置購物車(cart_abandon)

• line_opt_in = true 且
• Cart updated 在 2 小時前至 24 小時前之間 且
• Last order date 不在此區間內

每一個 Active List 都對應一個 Workflow。不要在單一 Workflow 裡塞多重分支處理所有分眾——分開維護的除錯成本低得多。

Step 6:用 Custom Coded Action 推播 LINE

在 Workflow 中新增 Custom code action(Node.js 20.x),Secret 設定 LINE_CHANNEL_ACCESS_TOKEN,並在 "Property to include in code" 加入 line_user_id。

1exports.main = async (event, callback) => {
2  const userId = event.inputFields["line_user_id"];
3  const firstName = event.inputFields["firstname"] || "您";
4
5  if (!userId) {
6    return callback({ outputFields: { push_status: "skipped_no_userid" } });
7  }
8
9  const res = await fetch("https://api.line.me/v2/bot/message/push", {
10    method: "POST",
11    headers: {
12      "Content-Type": "application/json",
13      Authorization: `Bearer ${process.env.LINE_CHANNEL_ACCESS_TOKEN}`,
14      "X-Line-Retry-Key": crypto.randomUUID(),
15    },
16    body: JSON.stringify({
17      to: userId,
18      messages: [
19        {
20          type: "text",
21          text: `${firstName}好,您上次看的商品補貨了,點此查看:https://shop.example.com/restock`,
22        },
23      ],
24    }),
25  });
26
27  const status = res.status === 200 ? "sent" : `failed_${res.status}`;
28
29  callback({
30    outputFields: {
31      push_status: status,
32      pushed_at: new Date().toISOString(),
33    },
34  });
35};

X-Line-Retry-Key 是 LINE Messaging API 提供的 idempotency 機制,能避免 HubSpot 重試造成重複扣訊息額度。輸出的 push_status 接到後續 action,寫回 line_last_push_at 與失敗計數。

預期輸出

Workflow 執行記錄應顯示 push_status: sent,測試手機在 1–3 秒內收到訊息。若回傳 failed_400,查看 response body:Invalid to 表示 userId 格式錯誤;The user hasn't added the LINE Official Account as a friend 表示對方已封鎖,此時應把 line_opt_in 設為 false。

Step 7:讓圖文選單也跟著分眾

推播只是單向。真正拉開差距的是每個分眾看到不同的圖文選單。LINE Messaging API 支援 per-user rich menu 綁定:

1# 先建立多組 rich menu,取得各自 richMenuId
2curl -X POST https://api.line.me/v2/bot/user/{userId}/richmenu/{richMenuId} \
3  -H "Authorization: Bearer {CHANNEL_ACCESS_TOKEN}"

在 HubSpot Workflow 中,當聯絡人進入 vip 清單時,呼叫上述 endpoint 綁定 VIP 專屬選單(例如加入「專人客服」入口);離開清單時 DELETE 解除綁定,回落到預設選單。同時把 line_rich_menu_segment 寫回 HubSpot,方便稽核與排錯。

AI 能在這條流程裡幫上什麼?

2026 年的實務差異不在「有沒有自動化」,而在自動化的內容產出效率。三個已被驗證有效的切入點:

1. 訊息變體生成:用 LLM 依商品資料與分眾特徵批次產生繁體中文訊息變體(注意 LINE 文字訊息單則上限 5,000 字元),再由行銷人員審核。人工只做把關,不做初稿。
2. 分眾條件建議:把 HubSpot 匯出的 RFM 分佈交給模型,請它提出候選門檻與預期覆蓋率,再回頭在 Active List 驗證。
3. 客服對話分類:LINE 進來的自由文字訊息,以模型分類為「物流查詢/退換貨/商品諮詢」並寫回 HubSpot Ticket,再依類別路由。

HubSpot 自身也持續擴充 AI 功能(Breeze),但跨語言的繁體中文語感,目前仍建議在自有 pipeline 中處理後再寫回 CRM。

疑難排解速查

Webhook Verify 失敗(非 200) — 檢查是否用了 express.json() 導致簽章比對失敗;確認 endpoint 在 10 秒內回應。

HubSpot 出現大量無 email 的聯絡人 — follow 事件建立的匿名紀錄。解法:在 Workflow 中把 line_user_id 已知但 email 未知者導向「待綁定」清單,推播綁定引導,而非任其累積。

推播回傳 429 — 觸及 Messaging API rate limit。在 Custom Coded Action 中加入指數退避,或改用 Multicast(/v2/bot/message/multicast,單次最多 500 個 userId)批次發送。

訊息額度爆掉 — 檢查是否有 Workflow 未設 re-enrollment 限制導致重複觸發。所有推播 Workflow 都應設定 suppression list 與每日上限。

同一人兩筆聯絡人 — line_user_id 未設為 unique property,或綁定流程先建新紀錄再更新。務必先以 email 搜尋。

個資與跨境合規要注意什麼?

台灣《個人資料保護法》要求蒐集個資時告知蒐集目的、類別與利用範圍,並取得當事人同意——這代表 LINE 綁定頁面必須有明確的同意勾選與隱私政策連結,不能只靠「加好友即視為同意」。行政上,台灣已於 2025 年設立個人資料保護委員會籌備處,監理趨嚴是可預期方向。

對跨境經營的品牌,還有兩層:

• 香港《個人資料(私隱)條例》的六項保護資料原則,對直接營銷另有獨立的同意與退出要求。
• 歐盟 GDPR:若你的網站服務歐盟居民,line_user_id 屬於可識別個人的識別碼,同樣受規範。

實務做法是把同意狀態當成一級資料:line_opt_in、marketing_consent_source、consent_timestamp 三欄都存在 HubSpot,推播 Workflow 一律以 opt-in 為第一道篩選條件。這比事後補救便宜太多。

這套架構如何延伸到其他市場?

LINE 在台灣、日本、泰國佔主導,但跨出這三個市場就得換投遞層。好消息是:如果你按前述「判斷邏輯在 CRM、投遞在渠道」的原則設計,替換成本很低。

• 香港、新加坡、馬來西亞 — 換成 WhatsApp Business Platform。HubSpot 有原生 WhatsApp 整合,分眾清單完全不用改。
• 中國大陸 — 換成微信服務號 / 企業微信,需另處理資料落地問題。
• 澳洲、紐西蘭 — SMS + Email 仍是主力,可直接用 HubSpot 原生功能。

對於在美國或歐洲總部、以亞洲為成長市場的品牌,這個分層設計還有一個額外好處:總部行銷團隊維護分眾與生命週期邏輯,各市場團隊只負責本地渠道與語言。時區與語言的協作成本被限制在最小面積。

交給熟悉多市場 CRM 落地的團隊

Branch8 總部設於香港,在台灣、新加坡、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊,長期處理 HubSpot、Salesforce 與 CDP 的跨市場導入,包括 LINE、WhatsApp 與微信的分眾串接。如果你正在評估把 LINE 官方帳號接進 CRM,或需要一個橫跨多市場的 MarTech 架構設計,歡迎與我們的團隊聊聊你的資料現況與目標。

Sources

• LINE for Business Taiwan — LINE 官方帳號服務介紹
• LINE Developers — Messaging API Documentation
• LINE Developers — LINE Login Documentation
• HubSpot Developers — CRM API Reference
• HubSpot Knowledge Base — Custom code actions in workflows
• 全國法規資料庫 — 個人資料保護法
• 香港個人資料私隱專員公署 (PCPD)
• HubSpot — Pricing and product tiers