RFM八群會員經營:R方向、總消費與LINE訊息計量別搞混
保留作者八群的內容與頻率建議,修正R天數與分數方向、M總額不等於客單價、低頻不等於首購;補上LINE API計量與分群驗收方式。
結論:分群值得做,但八群是簡化方案,不是RFM唯一標準
這則 Threads 的重點是:VIP、近期新購客與長期未購客不該預設收到同一份促銷。作者把R、F、M各分高低,得到八種組合,配上內容與接觸頻率建議。這是可測試的會員經營框架,不是已證明能提升每個品牌業績的固定處方。[1]
已讀原圖、主文和兩則作者續文;圖上八群與續文可對應。本次沒有讀取私人會員名單、匯入CRM、發送LINE/EDM或驗證銷售成效。第三方留言的可見覆蓋有限,沒有把頁面下方「相關串文」當成本帖討論。
先固定資料口徑:R的天數方向與M的意思
- R,Recency:距最近一次有效購買的時間。若欄位是天數,越小表示越近期;若轉成「近期程度分數」,才是分數越高越近期。不能把原始天數直接用「高於中位數就是高R」套用,否則近期客與沉睡客會被反分。[2]
- F,Frequency:指定觀察期間內的有效購買次數。先定義訂單粒度,避免一張訂單的多筆商品列變成多次購買。[2]
- M,Monetary:指定期間內的消費總額;退款、取消、稅運費及折扣是否計入,要固定口徑。它不是平均每單金額,也不自動等於毛利或客戶終身價值。[2]
因此,原帖對「常來的小額客」的「每次花不多」描述不能單憑低M就成立;若要用客單價決定組合包,應另算有效訂單的平均或中位單筆金額。同樣地,低F不必然代表只買過一次;若「新客」必須是首購,需另外檢查首購日期與有效訂單數。
作者八群:保留用途,但不要把標籤當診斷
下列H/L依序是R、F、M的高/低分數,R的H一律表示購買較近期。群名沿用原帖辨識,行動為摘要而非逐字轉錄;「新客」「買一次」「快流失」不是單靠這三個二元值已經證實的事實。[1]
- 最有價值(HHH):以新品預覽或VIP專屬體驗經營,不把折扣當成唯一溝通。
- 該喚回的大客(LHH):過去高頻高消費但近期未購;個別關懷與了解需求,比同一封清倉訊息更貼近原帖意圖。
- 出手大方的新客(HLH):近期、低購買頻次但高消費;可測試使用引導與合理補貨提醒。
- 新客(HLL):近期、低頻低消費;先歡迎和協助使用,再測試第二次購買誘因。
- 常來的小額客(HHL):近期、頻次高但期間消費相對低;作者建議組合或加購,實作仍須確認單筆金額。
- 買一次大單就消失(LLH):近期未購、低頻但期間消費高;先確認使用情況與是否仍有補貨需求。
- 快流失(LHL):近期未購、過去頻次高而期間消費低;可測試適度回購提醒,別預設大折扣最好。
- 已沉睡(LLL):近期未購、低頻低消費;降低行銷頻率並尊重退訂,而非每週全名單群發。
高低怎麼切:不能只說「用中位數」
作者建議以中位數當簡單起點,並用保健品回購週期調整R。這可作為營運假設,但「一瓶30天,所以60天內都算近期」不是跨商品、跨產業的通用門檻,也不是醫療或補充品用量建議。[1]
官方平台也沒有統一八群標準。Klaviyo目前文件採R、F、M各1至3分,再歸納為六種客群;它亦說明同值給同分,不能保證每組客數相等。這支持「RFM可依業務設計」,不是證明任何一組八群門檻都正確。[2]
- 指定統計截止日、時區與觀察窗口,避免把不同期間的F、M混在一起比較。
- 對R先決定是天數還是分數;天數門檻的比較方向,必須與F、M分數分開處理。
- 對中位數同值寫清楚歸哪邊,例如F/M高於中位數為高、等於或低於為低。大量同值可能讓某些組很小甚至為空,八種理論組合不代表實際名單必定有八個非空群。
- 未購買會員沒有最近購買日,應另外列為未購買/潛在客;不要把缺值硬塞入沉睡客。
- 季節型、高單價低頻及訂閱型生意需另外核對合理回購週期;單次高消費也可能是贈禮或一次性採購。
LINE「照則數算錢」需要說得更精確
原帖藉LINE成本提醒不要濫發,方向有道理,但不能解讀成所有LINE互動都按每個泡泡額外收費。LINE官方 Messaging API 文件區分:push、multicast、broadcast及narrowcast計入方案訊息用量;reply messages不計入該訊息用量。同一次請求的message objects數量也不是計量基準,官方按收件人數計算。[3]
一對一也要分操作方式:API主動push給單一會員,仍屬會計入用量的方式;不能因看起來是一對一問候就當成reply。本文沒有把API規則推成官方帳號所有功能的完整價表,也未引用其他國家方案作為台灣費率。實際付費仍看所在地、方案內含額度及當期官方公告。[3]
EDM也不等於零成本,更不是對長期不互動的名單無限寄送的理由。Klaviyo文件對無互動的inactive客群建議考慮名單清理,以免影響郵件送達;通路可用性、退訂與觸達偏好應優先於分群標籤。[2]
落地與驗收:先草稿,不讓分群直接觸發群發
先做去識別化的分群預覽,再確認門檻、資料品質、排除對象與內容,最後才在授權範圍發送。