LINE Login 與 LINE Messaging API 整合實錄:揮別技術債,邁向自動化行銷的轉生之路
最近接到一個有趣的委託,那是大約 6~7 年前我幫連鎖火鍋店客戶開發過的 LINE LIFF 優惠券系統。隨著業務擴大,業主希望能在既有的基礎上加入進階的問卷分析與分眾行銷功能,因此再次回頭找我進行「整骨兼升級」。
說到開發 LINE 整合系統,最怕的就是前期規劃沒對齊。這專案早年開發時,行銷跟開發團隊各開各的,結果 LINE Login 跟官方帳號被分在了不同的 Provider 下。這導致一個超低級的技術債:同一個使用者在兩邊拿到的 UserId 完全對不起來,官方帳號想發訊息(Push Message)給會員?抱歉,查無此人。
這次業主提了「生日祝福」跟「分眾行銷」的新功能,我乾脆下足重本,除了把帳號整合,也把整台系統來個「近代化大換血」。
核心絕活:如何優雅地綁定 UserId?
要把兩個不同 Provider 的 UserId 接起來,這次我改採 Webhook 搭配 bindToken 的方式來搞定。
綁定流程拆解
說白了就是玩一場「接力賽」:
- 觸發:使用者在官方帳號輸入 「優惠券」 或 「問券」。這兩個關鍵字都會觸發後端生成綁定 TOKEN 的邏輯。
- 生成 Token:Webhook 收到訊息後,在資料庫生成一個唯一的
bindToken,並將其與官方帳號的UserId_Messaging暫時掛鉤。 - 引導:機器人回給使用者一個帶有 bindToken 的 LIFF 連結(例如
https://liff.line.me/APP_ID?bindToken=xxx)。 - 登入獲取:使用者點進 LIFF,我們透過 LINE Login 取得他在此 Provider 下的
UserId_Login。 - 合體:前端把
bindToken與UserId_Login送回 API,我們從 DB 撈出對應的UserId_Messaging後,兩者正式存檔綁定。
sequenceDiagram
participant User as 使用者
participant Bot as 官方帳號 (Messaging API)
participant API as 後端 API / Webhook
participant LIFF as LIFF 應用 (LINE Login)
User->>Bot: 輸入「領取優惠券」
Bot->>API: Webhook 事件觸發
API-->>API: 生成 bindToken 並與 UserId_Messaging 關聯
API->>Bot: 回傳帶 Token 的 LIFF 連結
Bot->>User: 顯示領取按鈕
User->>LIFF: 點擊並登入
LIFF->>API: 送出 UserId_Login + bindToken
API-->>API: 匹配並存入 DB (完成綁定)
API->>LIFF: 綁定成功,顯示優惠券
核心功能地圖:從問卷到精準推播
除了 UserId 的綁定,這次我們同步開發了一套完整的「行銷自動化工作流」,確保每一分預算都砸在對的人身上:
- 問卷調查系統:行銷人員可靈活建立問卷題目。
- 填寫即發券:使用者填寫完畢後,系統自動發放指定的「感謝禮優惠券」,實現即時回饋。
- 會員標籤自動化:建立新連結進行會員綁定時,依據使用行為自動進行標籤分類。
- 動態標籤管理:後台可隨時建立新的標籤分類,因應不同時期的行銷活動。
- 生日禮自動發放:系統每日掃描,自動於會員生日當天發放禮券,並同步「群發消息」通知會員,溫馨提醒可領取。
- 目標對象推播中心:管理員可針對「特定標籤」的對象,建立與編輯群發消息內容,甚至連生日禮券的通知內容都能動態調整。
後台管理員只要透過這些標籤與功能,就能進行神準的分眾行銷。例如:「撈出常去楊梅店、固定素食、且這一個月內都沒有內用紀錄的舊客」,直接精確投送一張「楊梅店限定素食套餐優惠券」,轉換率絕對比亂發訊息高出數倍。
精準行銷發布流程
為了讓這套系統更易於操作,我們設計了一套直覺的發布流程。管理員只需三步即可完成精準投送:
Step 1. 條件篩選與名單確認
這套標籤系統的核心在於「維度組合」。例如:我們可以透過條件組合,秒速撈出「1 月生日、常去中壢店的男性顧客」。這不再是大海撈針,而是針對特定族群的精準打擊,名單備妥後即可連動訊息與券包投送。
Step 2. 訊息內容與發送設定
支援多樣化的推播形式,不管是純文字、Flex Message,還是搭配系統內的優惠券。這裡就是行銷人員的畫板,讓你靈活配置出最能觸發轉換的內容。
Step 3. 最後預覽與發送確認
發送前的最後一道關卡。系統會清晰顯示受眾人數與內容預覽,確保每一則推播都能準確傳遞給目標用戶,讓老闆的行銷預算每一分都花在刀口上。
系統轉生的下一步:邁向 .NET 10
雖然這篇主要在講 LINE 的業務整合,但其實背後我們同步進行了一次底層架构的「大手術」。我們將整個系統從古老的 ASP.NET Web Forms 徹底遷移到了 .NET 10 加 PostgreSQL。
關於這次硬核的技術轉型細節,包含五大關鍵階段的實作與 DB 遷移坑,我把它紀錄在另一篇文章:
[!IMPORTANT]
開發體悟:很多時候我們在修 Bug,但如果你深究進去,你會發現那是當初架構設計不慎留下的「惡因」。與其不斷貼 OK 繃,不如找個機會像這次一樣「長痛不如短痛」,把體質改好。



