每個使用者只缺三樣東西中的某幾樣。找到缺口，補上它。
每個狀態直接顯示缺口與行動方案。
9 種綁定方法 × 不同使用者狀態。每種方法的技術流程、觸發方式、適用對象一覽。
| 方法 | 流程 | 技術 可行性 |
使用者 摩擦力 |
開發 工作量 |
適用對象 | 注意事項 |
|---|---|---|---|---|---|---|
| A 感謝頁 LINE 綁定按鈕 | LINE 推普通 URL → 捐款 → 感謝頁 按鈕 → LIFF 取 LINE ID → 綁定 ⚡ 同意畫面在捐款「之後」才出現 |
✅ | 中 | 低 | 支持者、捐款人 月捐人、LINE好友 |
跟 B 的差別只是順序： A = 先捐款，後問 LINE 同意 B = 先問 LINE 同意，再捐款 A 不需改捐款頁，工作量更低 |
| B LINE 內直開捐款頁 ⭐ | LINE 推 LIFF URL → 打開頁面立刻問 LINE 同意 → 取 LINE ID → 使用者捐款 → 送出時一起綁定 ⚡ 同意畫面在捐款「之前」就出現 |
✅ | 最低 | 中 | 所有從 LINE 進來的人 | 跟 A 的差別只是順序： B = 先問 LINE 同意，再捐款 A = 先捐款，後問 LINE 同意 B 需改捐款頁前端加 LIFF SDK 非 LINE 環境自動跳過 |
| C Email LINE 綁定連結 + QR Code | Email 含 LINE 綁定按鈕 + QR Code 手機點連結 → LINE 開啟 LIFF → 綁定 桌機 → 掃 QR Code → 同上 |
✅ | 中 | 低 | 支持者、捐款人 月捐人（CC/LP） |
手機點 liff.line.me → LINE 自動開啟 ✅ 桌機點 → 瀏覽器開，體驗差 → 需 QR 備援 URL 帶 contact_id 參數 |
| ⬇ 需使用者自己輸入資料比對 CRM（無 contact_id 的場景） | ||||||
| D LINE 內填表綁定 | LINE 好友 → LIFF 表單 → 自動取 LINE ID → 使用者填 email/手機 → 比對 CRM → 綁定 | ✅ | 需輸入 | 中 | LINE 好友 | 核心綁定表單，其他方法都指向這裡 比對不到 → 建新 Contact 需個資同意聲明 |
| E LINE 群發綁定請求 | 群發訊息含 LINE 綁定連結 → 使用者點擊 → 進入 D 填表綁定 | ✅ | 需輸入 | 低 | LINE 好友 | 觸發方式：群發推播 3-6萬人群發會超額度 💰 建議分批 or Narrowcast |
| F Rich Menu 常駐按鈕 | LINE 底部選單永久放「我的帳號」→ 進入 D 填表綁定 | ✅ | 需輸入 | 低 | LINE 好友 | 觸發方式：常駐按鈕 零成本 · 24/7 · 使用者主動 |
| G 加好友歡迎訊息 | 加好友 → 自動推歡迎訊息含 LINE 綁定連結 → 進入 D 填表綁定 | ✅ | 需輸入 | 低 | LINE 新好友 | 觸發方式：加好友自動 只有一次機會，搭配 F 後備 |
| I 推播文章文末 CTA | 推播內容文章 → 文末 CTA → 進入 D 填表綁定 | ✅ | 需輸入 | 低 | LINE 好友 | 觸發方式：文章內嵌 不需額外成本，每篇都帶 |
| ⬇ 客服輔助綁定 | ||||||
| H 電話客服 → SMS+Email | 使用者來電 → 客服問 email/手機 → 查 CRM 找到 contact_id → 發 SMS + Email 含 LINE 綁定連結（帶 cid）→ 使用者點開 → LINE 開啟 → 一鍵綁定 | ✅ | 低 | 低 | 任何來電且在 CRM 的使用者 |
走有 cid 路徑（零輸入） SMS + Email 雙管道確保送達 需 SMS 發送能力 |
● = 主要方法 · ○ = 可用但非首選 · — = 不適用
| 方法 ＼ 適用對象 | 陌生人 | 支持者 連署/活動/Email |
單次 捐款人 |
每月 捐款人 (CC) |
每月 捐款人 LINE Pay |
LINE 好友 |
|---|---|---|---|---|---|---|
| A 感謝頁 LINE 綁定按鈕 | — | ● | ● | ○ | ● | ○ 主動捐/簽 |
| B LINE 內直開 ⭐ | ● | — | — | — | — | ● |
| C Email LINE 綁定連結 | — | ● | ● | ● | ● | ○ 如也在CRM |
| D LINE 內填表 | — | — | — | — | — | ● |
| E LINE 群發 | — | — | — | — | — | ● |
| F Rich Menu 按鈕 | — | — | — | — | — | ● |
| G 歡迎訊息 | — | — | — | — | — | ● |
| I 文章文末 CTA | — | — | — | — | — | ● |
| H 電話→SMS+Email | — | ● | ● | ● | ● | ○ 如也在CRM |
核心原則：已知 contact_id 的場景 → 使用者零輸入，一鍵確認。只有 S4 才需要填表。
單頁漸進式 · Greenpeace 品牌 · 手機優先 · 預設用手機號碼搜尋
| 觸發來源 | 條件 | 顯示畫面 | 使用者出路 |
|---|---|---|---|
| ① LINE 同意授權 | LIFF init 失敗 | ⑧ 錯誤提示：「請從 LINE 內開啟」+ QR Code | 掃 QR 加好友 / 致電客服 |
| ② 確認綁定 | 綁定衝突 | ⑨ 衝突提示：帳號已綁其他 LINE | 📞 撥打客服 / 重新開始 |
| ④ 確認身份 | 綁定衝突 | ⑨ 衝突提示：LINE 已綁其他帳號 | 📞 撥打客服 / 重新開始 |
LINE 原生畫面，第一次開啟 LIFF 才出現。允許後 SDK 取得 LINE User ID + 顯示名稱。第二次以後不再顯示。
確認以下資訊是否正確
從 Email、感謝頁、SMS 進來。URL 帶 contact_id，後端查 CRM 回傳模糊化資料。使用者只按「確認」。
「不是我」→ 進入畫面 ③ 用手機重新比對。
讓我們找到你的會員資料
預設手機號碼（大家通常用同一組），可 Tab 切換到 email。
· 步驟指示「1/2」· 說明原因 · 只需一個欄位 · 上一步可回退
我們找到一筆符合的資料
請輸入姓氏幫助我們找到你
填寫資料完成綁定
欄位順序：姓 → 名 → Email → 手機 → 出生年月
預填：畫面 ③ 的手機/email、畫面 ⑤ 的姓氏自動帶入。
個資同意：必勾才能送出。
⑦a：有捐款紀錄 → LINE Pay 月捐 CTA。串聯策略，動力最高。
⑦b：沒有捐款紀錄 → 不推月捐。引導回 LINE。
⑧：非 LINE 環境，提供 QR Code + 引導 + 客服電話
⑨：綁定衝突，「📞 撥打電話」按鈕直接撥號 + 重新開始
使用者按下按鈕到綁定完成，每一秒發生什麼事。
liff.line.me/xxx?cid=tokenliff.init()liff.getProfile() 取得 LINE ID + 名稱 + 大頭照cid 呼叫後端 API 查 CRM/api/bindline{ success: true }使用者在 LINE 裡看到的實際畫面。左 = 手機模擬，右 = 技術說明。
LINE 資料（自動取得，綠色卡片）：
liff.getProfile() 回傳 userId, displayName, pictureUrl
使用者不需操作，LIFF SDK 自動取得。
CRM 資料（後端查詢，藍色卡片）：
前端從 URL 取得 ?cid=encrypted_token
呼叫 GET /api/contact-preview?token=xxx
後端解密 → 查 HubSpot → 回傳模糊化姓名 + email
為什麼要模糊化？
安全性 — 如果有人拿到別人的 LIFF URL，看到的也只是「陳O明」和「ch***@gmail」，無法確認是否正確，不會按確認。
g****e@gmail.com、09xx-xxx-456）match_count + 遮罩提示，永遠不拿到原始值LINE 資料（自動取得）：同場景 1，liff.getProfile()。
CRM 資料（使用者填寫比對）：
URL 沒有 cid 參數 → 前端切換到「填表模式」
使用者只需填 email 或手機（二選一），不需填姓名。
後端查到恰好 1 筆 → 回傳遮罩後的 email/手機讓使用者確認 → 按「確認」→ 綁定。
注意：前端只拿到 masked_hint，不知道完整 email 或 contact_id。
不顯示任何比對結果清單。攻擊者可輸入猜測的 email，利用清單確認某人是否為 GP 支持者 — 這本身就是資料洩漏。
引導使用者填入第二個欄位縮小範圍：
• 第一欄填 email → 追問手機
• 第一欄填手機 → 追問 email
CRM 裡沒有這個 email/手機 → 建立全新 Contact（只有 email/手機 + LINE ID），其他欄位待後續互動補齊。
這是 S4 → S5a 的典型路徑。
🌍 每月 $100 起，守護地球
使用者剛完成綁定，心理動力最高。此頁面同時做兩件事：
1. 確認綁定成功 — 告訴使用者綁定帶來的好處
2. 順推 每月捐款(LINE Pay) — 串聯策略，不是並列
這個頁面是整個轉換漏斗中轉換率最高的位置，因為使用者剛做完一個「同意」的動作，延續這個動力推月捐，接受度最高。
導向 每月捐款(LINE Pay)頁面。技術方案取決於建廠的 API：
| 方案 | 說明 |
|---|---|
| LIFF 內完成 | 在 LIFF 頁面直接完成 LINE Pay 簽約（需建廠確認 Q5） |
| 導到外部頁面 | 跳轉到捐款頁，預選 LINE Pay + 月捐 |
防止 URL 竄改、重複綁定、API 濫用。
| 風險 | 處理方式 | 實作 |
|---|---|---|
| URL 裡的 contact_id 被竄改 | 用加密 token，不是裸的 ID | cid = encrypt(contact_id + timestamp + secret)後端解密驗證 |
| token 被截取重複使用 | 設 30 分鐘過期 + 一次性使用 | token 含時間戳，使用後標記為已用 |
| 用自己的 LINE 綁到別人帳號 | 顯示模糊化資訊讓使用者確認 | 「陳O明 · ch***@gmail」— 不對的人不會按確認 |
| API 被自動化攻擊 | Rate limiting | 每 LINE ID 每小時最多 5 次請求 |
| 個資法合規 | 綁定頁加同意勾選 | 「我同意個資蒐集與利用聲明」+ 連結 |
| 場景 | LIFF URL | cid 來源 |
|---|---|---|
| A 感謝頁 按鈕 | liff.line.me/xxx?cid={token} |
感謝頁 後端動態產生 token |
| B LIFF 捐款頁 | liff.line.me/xxx/donate |
不需要 — 表單送出時一起建立 |
| C Email | liff.line.me/xxx?cid={token} |
HubSpot template: {{contact.token}} |
| D/E/F/G LINE 內 | liff.line.me/xxx |
沒有 cid — 切換到填表模式 |
| J SMS | liff.line.me/xxx?cid={token} |
客服觸發系統產生 token |
BJ 需要開發的 API endpoints。
用加密 token 查 CRM，回傳模糊化資料供前端顯示。
| 參數 | 說明 |
|---|---|
token | 加密的 contact_id，30 分鐘過期 |
執行綁定。兩種模式：有 token（直接綁）或 比對模式（查 email/phone）。
客服 / 系統用，產生加密的一次性綁定 token（用於方法 J SMS 場景）。
基於 2026-03 業界研究，涵蓋訂閱管理 UX best practices。
入口：Rich Menu →「我的帳號」→ LIFF 會員中心。LIFF 自動取 LINE ID → 後端查 Contact → 顯示訂閱資料。
| 狀態 | 背景色 | 邊框色 | Badge |
|---|---|---|---|
| ● 扣款中 | #f0fae6 | #c2eb99 | 扣款中 |
| ● 已暫停 | #fff2cc | #f0af23 | 已暫停 |
| ● 扣款失敗 | #ffa9a9 | #ff3333 | 扣款失敗 |
| ● 已取消 | #f5f7f8 | #ececec | 已取消 |
| 狀態 | 顯示的列表項目 |
|---|---|
| 扣款中 | 📋 請款紀錄 · ✏️ 修改捐款金額 · ⏸️ 暫停月捐 · ❌ 取消月捐 |
| 已暫停 | ▶️ 立即恢復月捐（綠色突出）· 📋 請款紀錄 · ✏️ 修改捐款金額 · ❌ 取消月捐 |
| 扣款失敗 | 🔄 更新付款方式（紅色突出）· 📋 請款紀錄 · ❌ 取消月捐 |
| 已取消 | 🔄 重新訂閱（綠色 CTA）· 📋 請款紀錄 |
建廠 / BJ 需要開發的 API endpoints。
查詢使用者訂閱狀態，主頁面載入時呼叫。
請款紀錄，近 12 筆。
修改捐款金額，下次請款日生效。
暫停月捐，1-3 個月後自動恢復。
提前恢復月捐（暫停中點「立即恢復」）。
取消月捐，下次請款不執行。