會員系統

註冊流程每多一步，就少一批人

會員系統最常見的問題不是功能不足，是沒有人完成註冊。手機打字費力、驗證信收不到、欄位太多，每一個環節都會流失人。

設計原則很單純：先讓人進來，其他資料以後再問。

註冊只要最少的欄位

建議的最小組合是 Email + 密碼。其餘的欄位——姓名、電話、地址、生日、統編——可以在實際需要時再收。

為什麼是 Email

不只是聯絡方式，它同時是：

• 訂單與各種通知的發送管道——串接任何金流服務都會需要
• 密碼重設的唯一途徑——沒有 Email，忘記密碼就只能靠人工處理
• 網路上最低成本的身分驗證關卡——雖然不能保證確有其人，但至少經過提供信箱服務的公司驗證

沒有任何驗證機制的系統，實務上曾發生被大量灌入假訂單的情況——主機商只能提供連線紀錄，仍然查不出是誰。

不要在註冊時要求的欄位

• 身分證字號——除非有法規上的必要，否則不該蒐集
• 生日——除非真的會用於行銷活動
• 地址——購買時再問
• 統編——結帳需要開發票時再問

每一個欄位都應該說得出用途。蒐集用不到的資料，只是增加自己的保管責任。

三種替代的註冊方式

簡訊驗證的隱藏成本

簡訊看似方便，但要注意：一旦用簡訊取代 Email，後續的所有通知也必須用簡訊發送，長期下來成本會明顯累積。

常見的折衷是：用簡訊驗證身分，但仍要求留下 Email 作為通知管道。

社群登入的兩個提醒

• 要保留 Email 註冊的選項——不是每個人都有或願意用社群帳號
• 若使用者的社群帳號停用，要有補救方式——建議在首次登入後，引導他設定密碼或綁定 Email

驗證信是最常出問題的環節

使用者註冊了，但收不到驗證信——這是會員系統客訴的最大宗，而且你不會知道有多少人因此放棄。

常見原因

• 寄件驗證沒設好，被判定為垃圾郵件
• 使用者打錯 Email
• 信件被歸類到促銷或垃圾郵件匣

第一項是可以根本解決的：網站主機寄出的信必須納入寄件驗證設定，否則會被主流郵件服務擋下。排查方式見公司信箱收不到信或被當垃圾信怎麼查。

介面上該做的補救

• 送出後明確提示「請至信箱收信，並檢查垃圾郵件匣」
• 提供重新寄送驗證信的按鈕
• 提供修改 Email 的機會，處理打錯的情況
• 驗證連結的有效期限不要太短

登入與密碼

• 忘記密碼一定要能自助處理——透過 Email 重設，不要靠人工
• 不要用信件寄送明碼密碼——應該寄重設連結
• 登入失敗訊息不要太明確——「帳號或密碼錯誤」比「此帳號不存在」安全，後者會洩漏哪些 Email 已註冊
• 限制連續失敗次數，防止自動化嘗試
• 考慮提供「保持登入」，減少重複輸入

手機上的細節

多數使用者在手機上註冊，這些細節直接影響完成率：

• Email 欄位要跳出含 @ 的鍵盤，電話欄位要跳出數字鍵盤
• 不要禁止貼上——在手機上重打密碼很惱人
• 讓瀏覽器的自動填入能運作
• 送出失敗時不要清空已填內容
• 錯誤訊息要說明怎麼修正，並自動捲動到出錯的欄位

完整的表單設計原則見手機版表單怎麼設計才不會流失客戶。

驗證碼的取捨

圖形驗證碼能擋掉部分自動化註冊，但也會擋掉真人——尤其是只能看圖辨識的驗證碼，視障使用者無法通過。

若要使用，建議選擇提供替代方式的機制，或改用背景式的判斷方式，減少對使用者的干擾。

蒐集資料就是承擔責任

會員系統一旦上線，你手上就有了一批個人資料。這批資料在法律上有明確的保管義務，在實務上則是攻擊者的目標。

核心原則只有一句：只蒐集真正需要的，好好保管，不需要了就刪除。

最小蒐集原則

每一個欄位都應該說得出用途。說不出來的，就不要收。

屬於高度敏感的資料（如身分證字號、病歷、金融帳戶）一旦外洩，後果與責任都遠高於一般資料。能不收就不要收。

信用卡資料尤其不要自己存

串接金流服務時，卡號應該由金流業者處理，網站端不保存。這不只是安全考量，也大幅降低了自身的責任範圍。

告知與同意

蒐集個人資料前，應該讓使用者知道幾件事：

• 誰在蒐集——公司名稱
• 為什麼蒐集——目的
• 會怎麼使用——用途、期間、對象、地區
• 使用者有什麼權利——查詢、更正、刪除、停止使用
• 不提供的話會怎樣

實務上這些會寫在隱私權政策中，並在註冊時以勾選方式取得同意。

兩個常見錯誤

• 預設勾選——同意項目不應該預先打勾，尤其是行銷同意
• 把「同意條款」與「同意行銷」綁在一起——建議分開勾選，讓使用者可以只註冊而不接受行銷

會員應有的三種權利

系統設計時就要考慮這些功能，事後補會很麻煩：

1. 查詢與修改自己的資料——會員專區應提供
2. 取消訂閱行銷訊息——每封行銷信都應有明顯的退訂方式
3. 要求刪除帳號——應提供管道，並說明處理方式

刪除帳號的實務處理

完全刪除不一定可行——例如已完成的訂單，基於交易紀錄與稅務需求可能需要保留。常見的做法是：刪除或去識別化個人資料，保留必要的交易紀錄，並在隱私權政策中說明。

保護措施

技術面

• 全站加密連線——登入與資料傳輸不加密，等於在公開場合喊出密碼
• 密碼不可以明碼儲存——應以不可逆的方式處理。若系統能把密碼原文寄給你，那就是明碼儲存，這是嚴重的問題
• 後台權限分級——不是每個員工都需要看到完整的會員資料，見後台帳號與權限怎麼規劃
• 定期備份，且異地保存
• 系統與外掛保持更新

管理面

• 員工離職當天停用帳號
• 不要把會員名單匯出到個人電腦或私人雲端
• 不要用通訊軟體傳送含個資的檔案
• 與廠商合作時，約定保密義務

資料保存期限

這一項最常被忽略：資料不是留越久越好。

長期不活動的帳號、已經沒有業務關係的客戶資料，繼續保存只是增加風險而沒有效益。建議在規劃時就決定保存期限與清理機制。

萬一外洩

處理順序：

1. 立即阻止繼續外洩——關閉漏洞、更改密碼、必要時暫時關閉服務
2. 釐清範圍——哪些資料、多少筆、什麼時間
3. 通知當事人——說明外洩的內容與建議的因應措施
4. 依規定通報主管機關
5. 保留紀錄——處理過程與採取的措施
6. 檢討並修補

其中通知當事人這一項，實務上常被拖延或迴避，但延遲通知通常會讓後果更嚴重。

規劃階段就該做的三件事

1. 列出所有要蒐集的欄位，逐一確認用途
2. 準備隱私權政策，並在註冊流程中呈現
3. 在合約中約定廠商的保密義務與資料處理方式

本文說明個人資料保護的實務要點，供規劃時參考，不構成法律意見。實際的法令要求、主管機關規範與罰則，請以現行法規及主管機關公告為準，必要時建議諮詢專業人士。

這是客製化程度最高的一塊

會員分級與點數，看起來只是「多一個欄位」，實際上是整套商業規則的實作。每一家公司的規則都不同，很難有現成的方案完全適用。

這也是為什麼這類功能的報價通常明顯高於基本會員系統——費用來自規則的複雜度，不是介面。

會員分級

常見的分級依據

• 累積消費金額——最常見
• 消費次數
• 身分別——一般客戶、經銷商、企業客戶
• 人工指定——由管理員手動設定

要先釐清的問題

1. 計算區間是什麼？ 終身累積、還是近一年？
2. 會降級嗎？ 什麼條件下降？降級前要通知嗎？
3. 升級是即時還是定期結算？
4. 各級別的差異是什麼？ 折扣、專屬商品、優先出貨、專屬內容
5. 退貨後金額要扣回嗎？

這五題答不出來，就還不能開發。 規則沒定清楚就動工，後面一定會反覆修改。

點數系統

點數是這類功能中最複雜的一項。看起來只是「消費送點、點數折抵」，但實際要處理的規則很多：

其中退貨處理是最容易被遺漏、卻最常出問題的一項——沒有事先定義，實際發生時只能人工處理，而且容易產生爭議。

為什麼點數的開發成本高

• 規則交錯——上述每一項規則都會互相影響，組合起來的情況很多
• 涉及金錢價值——點數等同折扣，計算錯誤是實際的損失
• 需要完整的異動紀錄——每一次給點、扣點、到期都要留下軌跡，以備查詢與爭議處理
• 需要考慮資料安全與封存——歷史紀錄要保存，且不應被隨意修改
• 需要排程作業——到期扣除、到期通知都需要定時執行

因此這類功能通常需要客製化開發，費用與工期都需要單獨評估。

優惠券的替代方案

如果只是想做促銷，優惠券通常比點數簡單得多：

建議先從優惠券開始，觀察實際使用狀況與回購行為，確認有效再考慮投入點數系統。

發包時該準備的東西

如果確定要做，建議先自行整理一份規則文件，包含：

1. 分級的名稱、條件、權益
2. 點數的給點與折抵規則（上表每一項都要有答案）
3. 各種例外情況的處理方式
4. 後台需要哪些查詢與調整功能
5. 會員端能看到什麼

這份文件就是報價與驗收的依據。 沒有它，報價只能是估算，驗收也沒有標準。

一個實務建議

規則越簡單越好。複雜的點數制度不只開發成本高，會員也記不住——記不住就不會有促進回購的效果。

「消費一百元送一點，一點折抵一元，一年內有效」這種一句話說得完的規則，效果往往勝過需要看說明頁才懂的複雜制度。

會員系統上線後的真實問題

功能都做好了，但實際運作起來會遇到一批日常問題。多數不是程式錯誤，而是流程或設定沒有處理好。

一、註冊了但收不到驗證信

最大宗的客訴。 而且你只會接到少數幾通電話，其他人是直接放棄。

先確認範圍

• 所有人都收不到→ 系統寄信功能或主機設定的問題
• 只有特定信箱收不到（例如只有 Gmail）→ 寄件驗證設定的問題
• 進了垃圾郵件匣→ 同上

後兩種都是寄件驗證沒設好。網站主機寄出的信必須納入驗證設定，否則會被主流郵件服務判定為可疑。這是可以根本解決的，排查見公司信箱收不到信或被當垃圾信怎麼查。

介面上的補救

• 明確提示「請檢查垃圾郵件匣」
• 提供重新寄送的按鈕
• 提供修改 Email 的機會
• 後台要能手動將帳號設為已驗證，處理無法自助解決的個案

二、忘記密碼、無法登入

• 一定要有自助重設功能，不要靠人工
• 不要用信件寄送明碼密碼——應寄重設連結。如果系統能寄出原密碼，代表密碼是明碼儲存，這是必須修正的問題
• 重設連結應有效期限，並且用過即失效
• 會員換了信箱又忘記密碼時，需要有人工驗證身分的流程

三、假帳號與灌水註冊

自動化程式大量註冊，會造成資料庫膨脹、寄信量暴增、統計失真。

處理方式

• Email 驗證——最基本的一道關卡
• 限制同一來源的註冊頻率
• 背景式的機器人判斷——比圖形驗證碼對使用者友善
• 定期清理未驗證的帳號——設定一段時間未完成驗證即自動刪除

圖形驗證碼能擋一部分，但也會擋掉真人，尤其是視障使用者無法通過。若要使用，應提供替代方式。

四、殭屍會員

註冊後從未再登入的帳號，長期累積會造成三個問題：

• 會員數看起來很漂亮，但實際活躍人數很少，決策容易誤判
• 寄行銷信給早已不看的信箱，退信率上升，可能影響整體的寄信信譽
• 持續保管用不到的個人資料，只有風險沒有效益

建議做法

1. 定義什麼叫「不活躍」——例如兩年未登入
2. 寄送提醒，給予重新啟用的機會
3. 無回應者依隱私權政策的保存期限處理
4. 統計時區分「總會員數」與「活躍會員數」

五、退信率過高影響寄信

大量寄送給無效信箱，會讓郵件服務商降低對你網域的信任，連正常的訂單通知都可能被擋。

處理方式：定期清理無效地址、提供明顯的退訂方式、不要購買名單、寄送前先確認驗證設定正確。

六、會員要求刪除帳號

應該提供明確的處理管道。實務上要注意：

• 已完成的交易紀錄可能需要保留——基於稅務與帳務需求
• 常見做法是刪除或去識別化個人資料，保留必要的交易紀錄
• 處理方式應寫在隱私權政策中，避免爭議

詳見會員資料與個資保護。

七、後台的會員管理該有什麼

驗收時值得確認這些功能：

• 依 Email、姓名、註冊時間搜尋
• 查看單一會員的資料與紀錄
• 手動啟用、停用、刪除帳號
• 手動設為已驗證
• 協助重設密碼（寄送重設連結，而非查看原密碼）
• 匯出名單——此功能應限制權限，並注意匯出檔案的保管
• 操作紀錄——誰查看或修改了會員資料

最後兩項與個資保護直接相關。不是每個員工都需要看到完整的會員資料，見後台帳號與權限怎麼規劃。

八、會員數不成長

如果註冊數長期停滯，先檢查三件事：

1. 註冊流程是不是太複雜——欄位太多、驗證太麻煩
2. 訪客註冊之後能得到什麼——如果沒有具體好處，就沒有動機
3. 手機上的註冊流程是否順暢——多數人是用手機註冊的

第二點最根本。會員系統本身不會帶來會員，能帶來會員的是註冊後的價值。