深圳前海潘帕斯科技有限公司 程 亮

隨著大數(shù)據(jù)，電商的發(fā)展，企業(yè)的會(huì)員數(shù)據(jù)呈現(xiàn)爆發(fā)的增長(zhǎng)，這給各個(gè)企業(yè)帶來(lái)很大收入的同時(shí)企業(yè)對(duì)于客戶(hù)的管理成本也相應(yīng)提升。目前，近幾年SaaS技術(shù)有了很大的發(fā)展和成熟，通過(guò)互聯(lián)網(wǎng)+大數(shù)據(jù)的SaaS提供了高效的CRM管理工具，幫助企業(yè)維護(hù)，分析優(yōu)質(zhì)客戶(hù)，并且可以針對(duì)不同類(lèi)型的用戶(hù)制定相應(yīng)的經(jīng)營(yíng)策略和營(yíng)銷(xiāo)戰(zhàn)略。與此同時(shí)，也很大程度上提升了企業(yè)的服務(wù)水平，增加了用戶(hù)體驗(yàn)?？蛻?hù)信息對(duì)于企業(yè)來(lái)說(shuō)是寶貴的資源，對(duì)該部分資源利用效率，決定了互聯(lián)網(wǎng)時(shí)代，企業(yè)的發(fā)展和成長(zhǎng)，因此，CRM系統(tǒng)變得越來(lái)越重要。

本文描述了電子商務(wù)商家的CRM系統(tǒng)設(shè)計(jì)關(guān)鍵技術(shù)要點(diǎn)，通過(guò)會(huì)員模型，會(huì)員數(shù)據(jù)，發(fā)券活動(dòng)等闡述了基于SaaS技術(shù)的系統(tǒng)應(yīng)用場(chǎng)景。

1.系統(tǒng)的意義

大數(shù)據(jù)時(shí)代，誰(shuí)擁有更多有效顧客數(shù)據(jù)，誰(shuí)就越能在激烈市場(chǎng)競(jìng)爭(zhēng)中勝出，傳統(tǒng)做法是讓顧客填寫(xiě)表格，弊端是數(shù)據(jù)準(zhǔn)確度較低，難以更新，對(duì)精細(xì)化營(yíng)銷(xiāo)，產(chǎn)品研發(fā)幫助有限。在互聯(lián)網(wǎng)時(shí)代，一方面，可以通過(guò)信息化系統(tǒng)，輔以激勵(lì)等手段，鼓勵(lì)顧客在碎片化時(shí)間內(nèi)，主動(dòng)更新信息。同時(shí)，將顧客信息的收集納入銷(xiāo)售人員考核范圍，通過(guò)和顧客的交流，主動(dòng)收集顧客信息。產(chǎn)生精準(zhǔn)的用戶(hù)畫(huà)像，提高工作人員管理用戶(hù)的效率。另一方面，在信息系統(tǒng)，可以通過(guò)對(duì)顧客實(shí)際交易大數(shù)據(jù)的建模分析，給顧客打上更多的標(biāo)簽。從而精準(zhǔn)地營(yíng)銷(xiāo)。

2.系統(tǒng)設(shè)計(jì)

2.1 會(huì)員模型及使用

圖1

會(huì)員模型并不保存實(shí)際的用戶(hù)而是保存一組用戶(hù)的搜索條件。它定義一組搜索條件以及該組條件的會(huì)員數(shù)量，用于店鋪操作及參考。如圖1所示。反應(yīng)到代碼中，模型的定義就是序列化后的搜索條件。店鋪可以把過(guò)濾條件保存成會(huì)員模型，后續(xù)可用于快速查詢(xún)及店鋪發(fā)卷；保存會(huì)員模型時(shí)也統(tǒng)計(jì)當(dāng)時(shí)該過(guò)濾條件下的店鋪會(huì)員數(shù)據(jù)。會(huì)員保存是在會(huì)員列表查詢(xún)中操作保存，在輸入需定義搜索條件，點(diǎn)擊保存，系統(tǒng)計(jì)算模型的會(huì)員數(shù)量，把搜索條件及會(huì)員數(shù)量進(jìn)行序列化保存；返回界面時(shí)增加新模型。點(diǎn)擊保存模型分兩種情況：

（1）保存已有模型，這時(shí)更新模型的過(guò)濾條件及模型名稱(chēng)，視為修改模型；

（2）為當(dāng)前沒(méi)有選擇模型，應(yīng)為新增模型；

這里采用序列化方式：采用JSON格式，key為會(huì)員對(duì)象的字段名。value為用戶(hù)輸入的過(guò)濾條件。例如下面的串表示訂單金額從20到2000的會(huì)員級(jí)別為鉆石會(huì)員的一群會(huì)員。例如：{“l(fā)evelAtJd” : “鉆石” ,“minTotalOrderPrice” : 20 , “maxTotalOrderPrice” : 2000 }。店鋪在模型列表查看中，是集中管理店鋪?zhàn)约憾x的會(huì)員模型，展示了各模型的會(huì)員預(yù)估數(shù)量，以及操作入口。會(huì)員預(yù)估量會(huì)在每天從系統(tǒng)導(dǎo)入新數(shù)據(jù)后根據(jù)修改店鋪重新計(jì)算，正常情況下為前一天的數(shù)據(jù)；在模型的修改和查看時(shí)，使用模型定義查詢(xún)當(dāng)時(shí)的用戶(hù)數(shù)據(jù)。其實(shí)就是跳轉(zhuǎn)至?xí)T列表查詢(xún)功能中并將模型反序列化后查詢(xún)出具體的用戶(hù)數(shù)據(jù)，通過(guò)該功能達(dá)到用戶(hù)的模型修改。其中可以對(duì)各店鋪級(jí)別的會(huì)員數(shù)據(jù)固定成會(huì)員模型，每天在分析自動(dòng)更新，并在會(huì)員列表中顯示在前排，這樣能直觀各級(jí)會(huì)員數(shù)量，該類(lèi)模型是不可修改。

在使用該模型的時(shí)候，可以參考以下場(chǎng)景：

首先，在創(chuàng)建活動(dòng)時(shí)指定用戶(hù)群篩選條件，將篩選條件保存為一個(gè)臨時(shí)的發(fā)券用的用戶(hù)模型。后續(xù)操作和使用用戶(hù)模型篩選用戶(hù)的方式是一樣的。商家可以選擇一個(gè)或多個(gè)用戶(hù)模型來(lái)進(jìn)行營(yíng)銷(xiāo)活動(dòng)，這時(shí)候，實(shí)際上參與營(yíng)銷(xiāo)活動(dòng)的用戶(hù)是商家所選的模型用戶(hù)的并集。如果要保存用戶(hù)數(shù)據(jù)，注意由于通過(guò)模型選取出來(lái)的用戶(hù)數(shù)量可能會(huì)比較多（幾千，上萬(wàn)個(gè)左右），沒(méi)個(gè)用戶(hù)的pin。最大長(zhǎng)度為20.作為blob字段存放在數(shù)據(jù)庫(kù)里可能不是非常合適，所以準(zhǔn)備將用戶(hù)pin列表序列化成文件存放到fastDFS中。并通過(guò)fastDFS作為中轉(zhuǎn)站進(jìn)行傳輸，既解決了數(shù)據(jù)存儲(chǔ)問(wèn)題又解決了數(shù)據(jù)傳輸問(wèn)題。

其次，選取優(yōu)惠券的時(shí)候，可以通過(guò)調(diào)用促銷(xiāo)中心接口獲得，一次性最多獲取最近創(chuàng)建的20批有效的券信息（商品綁券也是如此實(shí)現(xiàn)）。所以準(zhǔn)備讓接口一次性返回所有數(shù)據(jù)。這樣做的好處是可以在商家選中某一批券時(shí)，可以快速顯示這批券的詳細(xì)信息。這時(shí)可以定時(shí)發(fā)券，采用的方式就是掃描活動(dòng)表，判斷指定的發(fā)券時(shí)間是否滿(mǎn)足，如果滿(mǎn)足，則調(diào)用發(fā)券接口發(fā)券。

2.2 店鋪會(huì)員統(tǒng)計(jì)

會(huì)員分析都是在會(huì)員的店鋪等級(jí)基礎(chǔ)上進(jìn)行分析的，當(dāng)會(huì)員數(shù)據(jù)或店鋪會(huì)員等級(jí)參數(shù)修改時(shí)，應(yīng)得重新計(jì)算會(huì)員的等級(jí)；計(jì)算會(huì)員等級(jí)有兩種情況設(shè)置情況：

（1）店鋪更新會(huì)員級(jí)別參數(shù)：這時(shí)需對(duì)店鋪中所有會(huì)員應(yīng)重新計(jì)算；

（2）店鋪沒(méi)有更新級(jí)別參數(shù)：只需重計(jì)算增量數(shù)據(jù)中會(huì)員記錄計(jì)算。

系統(tǒng)在接收到店鋪會(huì)員數(shù)據(jù)后，系統(tǒng)先對(duì)新增及更新數(shù)據(jù)進(jìn)行入庫(kù)，計(jì)算會(huì)員等級(jí)后，此時(shí)再預(yù)先對(duì)店鋪會(huì)員進(jìn)行分析，并保存在分析表中，用于前臺(tái)分析展現(xiàn)。分析時(shí)對(duì)各項(xiàng)分析數(shù)據(jù)進(jìn)行處理，每項(xiàng)分析數(shù)據(jù)整合成指定的格式字符竄，形成分析結(jié)果；分析結(jié)果統(tǒng)一保存數(shù)據(jù)庫(kù)中，一個(gè)店鋪只有一條分析記錄，每項(xiàng)結(jié)果為一字段；分析數(shù)據(jù)展現(xiàn)時(shí)直接讀取出相應(yīng)的字段，解析后顯示。其中各分析結(jié)果格式根據(jù)分析類(lèi)型定義，但最好不要與前臺(tái)展示格式一致，由于前臺(tái)展示所用圖形工具可能更換。依賴(lài)于前臺(tái)圖形工具會(huì)造成修改工作量加大，需要修改分析數(shù)據(jù)的結(jié)果生成格式；格式設(shè)置成簡(jiǎn)單通用，便于解析獲取各等級(jí)的分析數(shù)據(jù)。會(huì)員等級(jí)分析是根據(jù)店鋪會(huì)員等級(jí)計(jì)算各級(jí)別會(huì)員數(shù)量所占百分比（精確小數(shù)點(diǎn)后4位：33.33%），通過(guò)餅狀圖向前臺(tái)展示各等級(jí)份額。數(shù)據(jù)格式暫定義：比率保留小數(shù)后四分，如33.33%；每級(jí)以6位字符數(shù)表示（預(yù)留更精確），不足前面補(bǔ)0,再把各級(jí)比率按順序直接相連；例，各店鋪級(jí)別比率如下，普通會(huì)員：12%，中級(jí)會(huì)員：35.55%，高級(jí)會(huì)員：24.45%，VIP會(huì)員：28%；這時(shí)分析結(jié)果為：001200003555002445002800

3.數(shù)據(jù)庫(kù)設(shè)計(jì)

會(huì)員信息表最終的量級(jí)是略小于訂單數(shù)量，考慮到MySql的單表能力。決定對(duì)會(huì)員信息進(jìn)行分表。如圖2所示，從業(yè)務(wù)上看，會(huì)員數(shù)據(jù)按商家是天然隔離的。所以準(zhǔn)備選取商家id作為分表依據(jù)。目前，技術(shù)上已經(jīng)有成熟的分表組件可用。根據(jù)商家id分表唯一的缺點(diǎn)或者說(shuō)風(fēng)險(xiǎn)是，不同的商家的會(huì)員數(shù)量分布不是很均勻，可能導(dǎo)致分出來(lái)的表也不會(huì)特別的均勻。這點(diǎn)可以更具分表的張數(shù)來(lái)在一定程度上緩解。目前CRM系統(tǒng)不僅可以支持發(fā)送店鋪優(yōu)惠券這一種營(yíng)銷(xiāo)活動(dòng)，還會(huì)應(yīng)用到更多更實(shí)用的營(yíng)銷(xiāo)活動(dòng)功能，比如EDM等等。所以抽象了一張活動(dòng)表來(lái)存儲(chǔ)這些活動(dòng)的信息。包括活動(dòng)的類(lèi)型，名稱(chēng)，參與的會(huì)員，活動(dòng)本身的數(shù)據(jù)和活動(dòng)執(zhí)行的時(shí)間等等。另外，可能有些活動(dòng)需要在某一時(shí)段的參數(shù)次數(shù)和參數(shù)時(shí)間間隔等方面有要求，所以設(shè)計(jì)了一張活動(dòng)計(jì)數(shù)器表來(lái)記錄這些信息，比如會(huì)員總共參與某店鋪的某種活動(dòng)次數(shù)，這個(gè)月的參與次數(shù)，最近一次的參與時(shí)間等等。

圖2

4.結(jié)語(yǔ)

CRM在互聯(lián)網(wǎng)時(shí)代能夠?qū)τ脩?hù)資源起到很好的聚合和定向營(yíng)銷(xiāo)的作用，但是前提是針對(duì)業(yè)務(wù)設(shè)計(jì)號(hào)底層架構(gòu)和邏輯，目前CRM的應(yīng)用，在各行各業(yè)還是比較廣，但是還需要貼近業(yè)務(wù)邏輯。后續(xù)，CRM還可以做更多的延展，比如設(shè)置員工私海，成為一個(gè)可以在比較公平的規(guī)則下進(jìn)行有序競(jìng)爭(zhēng)的客戶(hù)信息管理平臺(tái)等，通過(guò)更加完善的客戶(hù)數(shù)據(jù)和基礎(chǔ)功能，幫助從業(yè)人員更好的尋找和跟進(jìn)客戶(hù)，提升工作效率?？傊?，CRM目前已經(jīng)成為各個(gè)企業(yè)的標(biāo)配，但是系統(tǒng)搭建技術(shù)參差不齊，本文希望能為企業(yè)CRM應(yīng)用提供基礎(chǔ)技術(shù)架構(gòu)建議，使得企業(yè)的系統(tǒng)開(kāi)發(fā)更為完整有效，從而對(duì)企業(yè)帶來(lái)實(shí)時(shí)性的幫助。