LINE 優惠券核銷不能只看「多少人領券」。對台灣 SME 來說，真正要先補的是 5 個欄位：發券對象、可核銷條件、實際核銷時間與門市、帶動的客單或毛利、以及退訂或封鎖風險。這些欄位沒有整理好，AI 報表很容易把高領取率解讀成高成效，卻看不出優惠是否吃掉毛利、吸引錯客群，或讓老客戶覺得被打擾。
LINE 優惠券很適合做回訪、會員經營與短期促銷，但它不是「發出去就算完成」。LINE Developers 文件顯示，優惠券可以由 Messaging API 建立並透過官方帳號訊息送出，也可以用 LINE Official Account Manager 操作；同一份文件也提醒，已建立的優惠券不能直接修改，若內容要改必須先停用再重建。這代表台灣 SME 在上線前就要把使用條件、期限、核銷方式與追蹤欄位寫清楚。
參考：LINE Developers coupon documentation。
LINE 優惠券核銷：先定義成功，不是只看領取
優惠券的第一個陷阱，是把「領取」當成「成交」。領券代表顧客願意打開或保存優惠；核銷代表顧客真的到店或下單；回購代表優惠沒有只買來一次性的折扣客。這三個階段的商業意義不同，如果全部丟進同一張報表，AI 只會幫你整理出看起來漂亮、但不一定能決策的結論。
比較務實的定義是：這張券要解決哪一個問題？是讓新客第一次到店、讓沉睡會員回來、讓常客加購高毛利品項、還是測試某個檔期主題？先定義問題，再設欄位；不要先做漂亮券面，再回頭猜成效。
適用對象與不適用情境
這套檢查表適合有 LINE 官方帳號、會員名單、門市核銷或電商折扣流程的台灣 SME，特別是餐飲、零售、美業、課程、診所周邊服務、地方店家與小型電商。只要你每月都有固定促銷，或正在讓 AI 協助看活動報表，就應該先建立欄位。
不適合的情況也要說清楚：如果你目前連基本銷售、客單、核銷紀錄都沒有，先不要做複雜自動化；如果涉及醫療療效、金融收益、保健宣稱或高額預付，優惠條件與文案應先經專業審核；如果只想清庫存，請先算毛利與庫存成本，不要把會員關係拿去換短期數字。
5 個核銷欄位：讓 AI 看得懂也讓店員做得到
| 欄位 | 要記什麼 | 為什麼重要 |
|---|---|---|
| 發券對象 | 新客、活躍會員、沉睡會員、高客單會員、特定品類興趣 | 避免把同一張券丟給所有人，事後才發現無法比較 |
| 使用條件 | 期限、門檻、指定品項、不可併用、每人次數 | LINE API 文件顯示優惠券建立後不能直接修改，條件要在上線前確認 |
| 核銷紀錄 | 核銷時間、門市、訂單、店員或系統來源 | 分清楚「有人領」與「真的使用」，也方便找出門市執行落差 |
| 商業結果 | 客單、毛利、加購品、回購間隔、是否新客 | 看優惠是否真的帶來增量，而不是用折扣換原本就會來的消費 |
| 關係風險 | 退訂、封鎖、客訴、客服問題、錯誤核銷 | AI 報表容易忽略負面訊號，但小品牌最怕把名單越推越冷 |
這 5 欄不需要一開始就串接昂貴系統。小店可以先用試算表加上每日收銀紀錄；有電商或 CRM 的團隊，再把 coupon、promotion_id、訂單編號與會員 ID 接起來。重點不是工具多高級，而是每個欄位有人負責、有人能在活動後看懂。
領取、核銷、回購：三種數字不要混在一起
Google Analytics 的 recommended events 文件在 2026-08-25 更新，促銷事件如 view_promotion 可帶 promotion_id、promotion_name、creative_name、creative_slot，也可在商品層級放 coupon 與 discount。這些欄位提醒我們，優惠券不是只有一個「轉換」數字，而是要把促銷曝光、使用券、商品、折扣與交易價值拆開看。參考：Google Analytics recommended events。
對台灣 SME 來說，最小可行報表可以先分三層。第一層是發送與領取：送給誰、多少人打開或領券。第二層是核銷：多少人真的使用、在哪個門市、用了哪個品項。第三層是回購：核銷後 30 天或 60 天是否再消費、是否升級會員、是否只在折扣時才出現。AI 可以幫你整理趨勢，但不能替你定義哪個數字才算成功。
自動發券前先做一張風險表
LINE Developers 文件也列出優惠券可以用 push、multicast、broadcast、narrowcast、reply 等訊息型態送出。選擇發送方式前，先想清楚「誰不該收到」。例如剛以原價購買的會員、已經退訂行銷的人、正在客訴中的顧客、或已拿過同一類折扣的人，都不應該被粗暴地放進下一波自動化。
台灣個人資料保護法第 20 條要求非公務機關利用個人資料行銷時，當事人拒絕接受行銷後應停止利用，首次行銷也應提供拒絕方式並支付所需費用。優惠券若透過會員生日、購買紀錄、電話、Email 或 LINE ID 做分眾，就要把資料來源、使用目的與停止行銷狀態放進流程。參考：個人資料保護法第 20 條。
另一個風險是優惠條件講不清楚。公平交易法第 21 條禁止對足以影響交易決定的事項做虛偽不實或引人錯誤表示，包含價格、數量、品質、內容、有效期限與使用方法等。優惠券文案若寫「全館可用」，但結帳時才排除熱銷品或指定門市，就容易傷害信任。參考：公平交易法第 21 條。
AI 報表可以做什麼，不能做什麼
AI 很適合做三件事：整理各券種的核銷差異、找出高領取低核銷的可能原因、把客服問題分類成條件不清楚、門市不知道、期限太短、優惠不夠有感、或名單錯配。這能幫老闆很快看到下一波要修哪裡。
但 AI 不應該直接決定下一波折扣。它不知道你的毛利底線、品牌定位、供應成本、門市人力與顧客關係，也不會自動知道哪些會員已拒絕行銷。最後決策仍要回到業務目標：你是要拉回高價值客戶、提高加購、清特定庫存、測新品，還是只是想讓報表看起來熱鬧？
7 天落地流程
- 第 1 天：列出最近 3 次優惠券，分別標記目標客群、優惠內容、發送通路與活動目的。
- 第 2 天：補齊使用條件，包含期限、門檻、指定品項、不可併用、每人可用次數與門市例外。
- 第 3 天：建立核銷欄位，至少記錄券名、會員或訂單、核銷時間、門市、金額與品項。
- 第 4 天：把退訂、封鎖、客服問題與錯誤核銷列入活動後檢查，不只看成交。
- 第 5 天：若有網站或電商，設定 GA4 的 promotion 或 coupon 相關欄位，讓曝光、使用券與交易資料能對上。
- 第 6 天：把資料交給 AI 做摘要，但要求它分開回答領取、核銷、毛利、回購與風險，不准只給總結。
- 第 7 天：決定下一波只改一件事，例如名單、門檻、期限、品項或提醒節奏，避免一次改太多而看不出原因。
資料更新與來源
本文於 2026-09-09 依公開可查資料整理。LINE coupon 行為以 LINE Developers 文件為主；GA4 事件與 coupon、promotion 欄位以 Google Analytics Developers 文件為主；台灣個資與廣告表示風險則參考全國法規資料庫。Ocard 2026-08-25 的 LINE 優惠券文章被用作 SERP benchmark，觀察到市場內容多著重送券情境、會員分眾與使用率，本文則補上核銷欄位、AI 報表與法規風險的操作缺口。參考：Ocard LINE coupon benchmark。
平台後台、API 可用範圍、訊息費用、報表欄位與法規解釋都可能更新。正式導入前，應確認自己的 LINE 官方帳號方案、開發權限、CRM 或 POS 是否能留下核銷資料；涉及法律責任時，請交由專業人員確認。
結論
LINE 優惠券核銷做得好，不是因為折扣更大，而是因為每次活動都能留下可判斷的資料。先補 5 個欄位：發給誰、怎麼用、何時在哪裡核銷、帶來什麼商業結果、造成什麼關係風險。等這些資料穩了，再讓 AI 幫你找趨勢、整理報告、提出下一波測試，才不會把會員名單變成一台只會發折扣的機器。
FAQ
LINE 優惠券核銷率要怎麼算？
最基本是已使用優惠券數除以已領取優惠券數；若要評估商業成效，還要分開看發送對象、客單、毛利、回購與退訂。
只用 LINE 官方帳號後台夠不夠？
小規模活動可以先用後台資料加試算表；如果要做會員分眾、門市核銷、回購分析或 AI 報表，通常還要接 CRM、POS 或電商訂單資料。
AI 可以自動決定下一張優惠券發給誰嗎？
不建議一開始就全自動。AI 可以協助分群與找異常，但名單、折扣、限制條件、退訂排除與毛利底線仍應由人確認。
優惠券文案最容易漏掉什麼？
最常漏掉有效期限、適用門市、不可併用條件、指定品項、最低消費門檻與每人可使用次數，這些都會影響交易決定與客服負擔。
沒有電商網站也能追蹤 GA4 嗎？
如果沒有網站或 App，先用 LINE、POS 與試算表追核銷即可；有活動頁、訂位頁或電商時，再用 GA4 的 promotion 與 coupon 欄位補完整路徑。