會員要不要做成手機應用程式，這個念頭多半不是技術部門先提的，而是從門市和客服端傳上來：老客人抱怨查點數都得重新輸入密碼、行銷想通知限時活動卻只剩簡訊可用、櫃檯希望掃一下就能認出人。搜尋這個題目的人，多半已經有一套跑得動的網頁會員，正在衡量要不要再開一個手機端入口。這篇把行動化真正會改變的幾件事講開：使用者卡在哪一段、登入怎麼設計、推播能換到什麼、換手機時帳號跟著誰走，以及送審之後改版節奏會被什麼綁住。
先確認使用者真正卡住的是哪一段
很多行動化的需求，拆開來看其實是網頁體驗沒做好。如果會員每次都要重打帳號密碼，那是因為網頁沒有保留登入狀態；如果條碼要點三層選單才找得到，那是資訊架構的問題。這兩種狀況做成應用程式當然會變好，但把網頁修好一樣會變好，而且便宜得多。
真正只有安裝在手機上才能解決的，通常是這幾類：需要主動發出通知、需要在沒有網路的環境叫出憑證、需要用到相機或定位這類裝置能力、需要員工長時間停留在同一個畫面操作。盤點的方法很簡單，把過去三個月客服收到的抱怨列出來，逐條標記「換個入口就能解」還是「非得裝在手機上」，比例會說話。
行動應用做得到、網頁會員做不到的事
兩者在功能上的差距，比多數人想像的窄。註冊、查點數、看訂單紀錄、修改資料，這些用行動版網頁都能做，而且不必經過安裝這一關。差距集中在少數幾處：
- 主動通知：不必等使用者想起來才打開，這是最大的分野。
- 離線可用：把會員憑證存在裝置上，在收訊不良的賣場或地下室仍叫得出來。
- 裝置能力：指紋或臉部辨識解鎖、掃描條碼、依所在位置顯示最近的門市。
- 停留成本：圖示留在桌面上，回訪的門檻比記住一串網址低。
反過來說，安裝本身就是一道很高的門檻。一年只消費一兩次的客人不會為此下載，這種客群更適合把會員入口做在網頁上，用連結直接帶到功能頁。
登入這一關決定了後面的使用率
行動端的輸入成本高，帳號密碼打錯一次就可能流失。實務上比較穩的做法是：首次以手機號碼加驗證碼完成綁定，之後改用裝置本身的生物辨識解鎖，密碼只留作備援。這樣做的前提是後端要能發出並驗證一次性驗證碼，而且要設好重送間隔與失敗次數上限，避免被當成發訊管道濫用。
如果原本網頁會員是用電子郵件註冊的，行動化時就會遇到同一個人兩種識別的問題。建議在設計階段就決定唯一識別要用哪一個欄位，另一個當作可選的聯絡方式，而不是等資料混亂了再回頭合併。
推播的價值在分眾，不在發得多
推播是行動化最常被拿來當理由的功能，也是最容易被用壞的。使用者關掉通知權限之後幾乎不會再打開，所以每一則都該問：這個人現在需要知道這件事嗎。可以分眾的維度包括消費週期、會員等級、上次瀏覽過的類別、票券即將到期的天數。沒有分眾能力的推播，等於是把全部名單當成同一個人在對待。
技術上要留意的是，推播的傳送是委由行動作業系統的通知服務轉送，送達與否不在自己掌握之內，因此重要的權益通知不能只靠推播，站內訊息或電子郵件要留一份。同時要保留每一則的發送與開啟紀錄，否則之後無從檢討內容或時段。
換手機的時候帳號要跟著誰走
會員資料必須綁在帳號上，不能綁在裝置上，這是最容易在初期做錯、後期很難補救的一件事。有些做法圖方便，直接把裝置識別碼當成使用者，結果客人換了手機，點數與票券就找不回來。
正確的關係是一個帳號可以對應多台裝置，每台裝置各自持有一組登入憑證，可以個別失效。後台要能查得到某個帳號目前有哪些裝置在登入、最後使用時間是什麼時候，並提供讓客服協助解除的功能。同時要決定同一組帳號能否同時在兩台裝置上使用，如果涉及票券核銷或儲值，通常要限制成單一裝置，並在切換時強制重新驗證。
送審與多版本並存會改變開發節奏
網頁改完就上線，行動應用不是。每一次改版要經過商店的審查流程，時間不完全可控，遇到活動檔期就會很緊張。更麻煩的是舊版本會長期留在使用者手機裡，不更新的人比想像中多，等於後端要同時支援好幾個版本的介面。
應對方式有兩個。第一，把會活動性調整的內容做成由後端下發，例如首頁版位、活動說明、票券樣式，這樣不必改版就能換。第二，在程式裡放一個版本檢查機制，遇到必須升級才安全的情況能提示使用者更新，甚至擋住舊版繼續操作敏感功能。這兩件事在第一版就要做進去，之後再補會非常痛苦。
常見問題
已經有網頁會員了，資料需要重建一份嗎？
不需要，而且不應該。行動應用應該透過介接呼叫既有的後端，讀寫同一份會員資料，兩邊看到的點數與訂單才會一致。要新增的通常只有裝置註冊、推播權杖、登入憑證這幾張紀錄。如果被建議「另外開一套資料庫」，要問清楚兩邊資料何時同步、衝突時以誰為準。
會員條碼在沒有網路的地方能顯示嗎？
可以，但要在設計時就決定。做法是登入後先把識別碼取回並存在裝置的加密儲存區，畫面依此在本地產生條碼。這樣即使當下離線也叫得出來，缺點是點數餘額可能不是最新的，所以畫面上要標示更新時間。若採用每次都向伺服器要一組動態碼的做法，安全性較高但一定要有網路。
一定要同時做兩種行動作業系統的版本嗎？
先看自家會員實際使用的比例，從既有網站的裝置統計就查得到。如果某一邊佔多數，可以先做一邊驗證需求，另一邊暫時用行動網頁承接。要注意兩邊的審查規範與通知機制不同，某些功能的實作方式會有差異，排程時要各自估算，不能直接除以二。
客人不願意安裝，有什麼辦法？
與其加強勸說，不如把安裝理由做出來。常見有效的做法是把只有在應用程式裡才成立的權益具體化，例如專屬的通知提醒、免出示實體卡的結帳流程、離線也能用的憑證。同時要降低第一次使用的摩擦，安裝後不要立刻要求填一長串資料，讓他先用起來再逐步補齊。
舊版本使用者一直不更新會有什麼問題？
後端得長期維持舊介面，改動時要顧慮相容性，維護成本會隨版本數上升。安全性修正若沒被安裝，風險也留在外面。實務上會設定一個最低支援版本，低於這個版本時提示更新；涉及付款或個資的功能則直接要求升級後才能使用。這個政策要事先寫進規格，而不是出事才臨時決定。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
相關主題
下一步
如果你正在評估「會員系統app」相關的規劃，可以參考我們的系統開發需求討論，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。
