非小型電子商務(wù)系統(tǒng)設(shè)計(jì)經(jīng)驗(yàn)分享
前言
做了兩年多針對淘寶的電子商務(wù)數(shù)據(jù)線下數(shù)據(jù)系統(tǒng)，越到后面越覺得自己還沒入門，不管技術(shù)上還是業(yè)務(wù)上，這篇文章既是對自己的積累的一次梳理，更想的是能在和各位朋友交流中，互相進(jìn)步。
ps:所有字段并不是正式項(xiàng)目所使用字段，請根據(jù)自己的業(yè)務(wù)需求進(jìn)行酌情查看處理,類目屬性，商品，訂單結(jié)構(gòu)可以參考淘寶API數(shù)據(jù)接口進(jìn)行查看具體字段。
商品模塊設(shè)計(jì)
商品模塊是支撐整個架構(gòu)的核心，如果這塊沒設(shè)計(jì)好，那么所有后期的復(fù)雜的統(tǒng)計(jì)需求基本都滿足不了。
為什么這樣子設(shè)計(jì)屬性看這里和這里，把品牌從類目中剝離出來是為了降低程序針對商品屬性這塊的復(fù)雜度。這里通過淘寶的添加寶貝的操作來說明上面的數(shù)據(jù)結(jié)構(gòu)如何滿足下面的需求:
PS:本來要截玉蘭油沐浴露的圖，結(jié)果發(fā)現(xiàn)淘寶取消了以前選擇毫升*買的多送得多組合SKU的添加商品方式，改成了一個SKU就是一個寶貝的編輯手段，呵呵，沒辦法，只有上面截個衣服的圖，下面的數(shù)據(jù)卻是快消品的。淘寶這樣做這也是沒辦法的，這種快消品不同SKU，圖片還不能用一樣的，而且大部分用戶搜索的時候呢，會喜歡直接搜索具體的毫升數(shù),這也給我們提了個醒，不同的類目可能會是不一樣的處理方式，就算是服裝這種SKU相對標(biāo)準(zhǔn)的類目，也會有說在展示和搜索結(jié)果中，會放置一個產(chǎn)品的多個SKU，比如凡客的網(wǎng)站，一件衣服的幾個顏色都會出現(xiàn)在類目搜索結(jié)果中，增加曝光度，吸引用戶點(diǎn)擊購買。
頁面屬性的編程實(shí)現(xiàn)可以參考這里。SKU存放在產(chǎn)品SKU表中，按我們的實(shí)際需求增加修改字段，比如我的表中多了ProductCode和BarCode字段，SKU的屬性會拆分后存入產(chǎn)品基本屬性值表，便于搜索或統(tǒng)計(jì)等需求。商品的基本屬性全部打橫存入商品的基本屬性表中，那么SKU表的存儲如下：
那么這個item是4013的產(chǎn)品在基本屬性值表中的數(shù)據(jù)存儲如下：
這里我是把所有的屬性都打成一條一條存儲在這個表中，那么能滿足我們在日常業(yè)務(wù)的屬性搜索，統(tǒng)計(jì)等需求。按屬性搜索，這里必須要注意以下幾點(diǎn)：
1.不可能所有的屬性都開放給用戶或者我們的客戶進(jìn)行搜索，所以我們會在屬性名表中有個字段（是否搜索字段）來人工控制哪些屬性是搜索屬性
2.基本屬性是同一個寶貝下面所有SKU都共有的，SKU屬性是單個SKU獨(dú)有的，所以搜索的時候還必須分清楚銷售屬性（銷售屬性組成SKU）和基本屬性。
3.屬性圖片的存儲我并沒有設(shè)計(jì)，因?yàn)槲覀兪亲隹煜?，沒有這個需求。但是，如果我做的話我還會是在基本屬性值表中加上”是否圖片屬性，是否使用默認(rèn)圖片，圖片URL“3個字段來記錄顏色屬性。做屬性搜索的時候比較方便。
4.產(chǎn)品通過關(guān)鍵字搜索和屬性搜索是分開的，兩種搜索并不是一種解決方式，比如淘寶，在首頁的搜索框是通過分詞匹配寶貝標(biāo)題的關(guān)鍵字，通過關(guān)鍵字的匹配程度，店鋪的dsr評分權(quán)重來決定搜索結(jié)果，而屬性搜索的時候則是匹配滿足屬性條件的寶貝。那屬性又分第1點(diǎn)和第2點(diǎn)，所以還是挺麻煩的。
那到了這里產(chǎn)品的存儲已經(jīng)說完了，其它的運(yùn)費(fèi)什么的，就懶得說了。
這里你會發(fā)現(xiàn)有打包品表，打包品子表，最終商品表，商品變更記錄表。這里需要詳細(xì)說明一下。
首先說一下打包品概念：
打包品：為了各種運(yùn)營上的需求，很多時候我們會人為的把多個SKU組合成一個商品進(jìn)行組合銷售，我們在淘寶購物的時候，經(jīng)常會看到這樣的情況，A產(chǎn)品+B產(chǎn)品組合銷售，AB的組合在淘寶上面表現(xiàn)為一個寶貝，你看看這里或者這里或者這里，這些就是拉。這種銷售數(shù)據(jù)在訂單里表現(xiàn)是一個淘寶商品，但是我們要做庫存管理，數(shù)據(jù)分析等需要拆分出來。這是必須考慮的！
PS：有那種出廠打包品，比如一個包裝盒里面有香皂，有沐浴露，但是它們本身就是一個SKU，出廠就這樣，所以不能和打包品混為一談。
由于我們運(yùn)營上的需要，我們可能賣單個SKU，也可能賣多個SKU的組合，那么在我這里把單個SKU和多個SKU組合都看成打包品，單個的SKU打包品它的子項(xiàng)只有它自己，這樣做的好處是，系統(tǒng)中只需要一種方式來處理這種關(guān)系。在打包品表中通過類型來區(qū)分。
這里有一個關(guān)鍵問題要注意，我們在出售商品過程中，價格是可能會隨時人工或者系統(tǒng)來干預(yù)變化的，比如產(chǎn)品A標(biāo)題叫B洗發(fā)水+C護(hù)發(fā)素直降20元，但是我們根據(jù)實(shí)際的流量和轉(zhuǎn)換率價格可以上下浮動，那么我們就要及時的調(diào)整價格，所以我們的標(biāo)題，價格都需要進(jìn)行更改，這里牽涉2個問題，我們是新建一個打包品或者我們是另外放在最終商品表，我們就需要修改對應(yīng)的標(biāo)題和價格，同時呢，在商品變更記錄表中記錄添加一個上次修改的備份，作為我們對不同價格的轉(zhuǎn)換率的一個分析基礎(chǔ)數(shù)據(jù)。第二個問題就是由于修改了打包品或者創(chuàng)建了新的打包品（SKU子項(xiàng)，SKU數(shù)量一樣）價格，那么對應(yīng)的分配到每個具體SKU的價格發(fā)生了變化，這里如果是新建了打包品就沒問題，但是如果是修改打包品，那么我們對打包品SKU子項(xiàng)的價格就必須通過相應(yīng)的公式進(jìn)行計(jì)算。比如A+B+C今天是100元，A是30，B是50，C是20,如果價格變成了90或者110，那么對應(yīng)到具體的子項(xiàng)價格也需要更改，因?yàn)楹芙?jīng)常的需求就是統(tǒng)計(jì)某產(chǎn)品或者某SKU的銷售量和銷售額。
所以最終是我們網(wǎng)站上是出售打包品還是最終產(chǎn)品，是每次新建打包品還是修改，這要看自己權(quán)衡。但是商品的價格變更是一定要記錄的。一是留備份，二是分析價格對銷售的影響等等。
這樣設(shè)計(jì)遇到的問題
1.起初產(chǎn)品維護(hù)人員意見很大，覺得很復(fù)雜，工作量很大。因?yàn)檫@種結(jié)構(gòu)需要維護(hù)人員維護(hù)屬性，并且需要他們懂一些專業(yè)知識和熟悉整個流程，各種名詞搞得他們頭暈，后面甚至出現(xiàn)了相當(dāng)大的負(fù)面抵觸情緒。這個沒辦法，因?yàn)槲覀冞@個不是網(wǎng)站，不是說讓你簡單的舒服的就能添加一個商品，這個需要掌握分類-產(chǎn)品-屬性-打包品之間的業(yè)務(wù)關(guān)系以及這樣維護(hù)的好處。解決辦法：1.慢慢溝通，說明增加的工作量是為了他們在出復(fù)雜的報表的時候不需要手動去進(jìn)行篩選，而且基礎(chǔ)數(shù)據(jù)維護(hù)好了，一勞永逸。2.一定要培訓(xùn)好產(chǎn)品維護(hù)人員，讓他們在有相關(guān)業(yè)務(wù)背景人員指導(dǎo)下能清晰的分清楚屬性的意義，以及根據(jù)業(yè)務(wù)規(guī)則維護(hù)好屬性基礎(chǔ)表和錄入產(chǎn)品等信息。
2.由于一開始數(shù)據(jù)的關(guān)聯(lián)檢查機(jī)制沒做好，導(dǎo)致后面亂了很多數(shù)據(jù)，所以在后面又來花時間檢驗(yàn)數(shù)據(jù)和建立起相應(yīng)的檢查機(jī)制，浪費(fèi)了很多時間。
#p#
訂單模塊結(jié)構(gòu)
這里關(guān)系很簡單，我想著重說明3個問題，
1個就是訂單主表中存儲地址庫ID+買家具體地址組合成購物地址，不是依賴用戶收貨地址的信息，因?yàn)橛脩舻氖肇浀刂肥强赡馨l(fā)生人為的修改的。
2.地址庫的城市級別，這是一個統(tǒng)計(jì)維度，最好加上
3.在訂單子表中，不僅存儲了打包品的ID，還會把當(dāng)時網(wǎng)站上該商品的標(biāo)題和SKU名字，以及當(dāng)時的價格存儲進(jìn)來，這是很有必要，不能直接使用關(guān)聯(lián)的打包品或者商品的價格，標(biāo)題，前面說了，隨時可能改變的。
4.促銷信息表，這里就是記錄所有促銷活動信息，一個商品可能對應(yīng)多個促銷活動，比如使用了優(yōu)惠券+（滿200-20）+ 滿100包郵+VIP優(yōu)惠10元+XXX。這樣的設(shè)計(jì)是比較好的。從訂單角度來看這個訂單應(yīng)用了多少個活動模型，能準(zhǔn)確的抽取某種促銷活動的所有訂單。
不要把這種東西設(shè)置產(chǎn)品表中，或者與產(chǎn)品表進(jìn)行關(guān)聯(lián)，先不考慮其它原因，首先把業(yè)務(wù)模型和產(chǎn)品模型混在一起就亂了。
活動模塊設(shè)計(jì)
由于我們的訂單表有訂單活動促銷信息表與其關(guān)聯(lián)，那么實(shí)際上我們統(tǒng)計(jì)一般的需求只需要關(guān)聯(lián)過來活動模型表就能得到說某個活動或者某類活動的數(shù)據(jù)情況，這里對于前臺商品活動信息是個悲劇，一套活動緩存跟新機(jī)制，前臺所有商品顯示的時候和所有訂單提交時檢查是否滿足所在時間內(nèi)的活動模型來展示不同的UI。
還會有很多活動模型，這里只是列了幾個，另外，必須注意一個問題，只要涉及到包郵的地方就要考慮有的地方不能包郵。也可以單獨(dú)存儲不包郵的城市。這個就要看業(yè)務(wù)上如何決定這個模型怎么建立。
#p#
訪問跟蹤模塊設(shè)計(jì)和CRM
訪問數(shù)據(jù)這一塊我們是結(jié)合量子統(tǒng)計(jì)和自己跟蹤的數(shù)據(jù)進(jìn)行合并數(shù)據(jù)出數(shù)，這塊我就過掉了，因?yàn)檫@塊感覺我們并沒有做太深，今年會單獨(dú)把這塊加強(qiáng)。我只想說，這塊很重要。這一塊是電子商務(wù)運(yùn)營過程中的重中之中，沒有他，幾乎所有的帶有指導(dǎo)性的報表數(shù)據(jù)你都沒辦法出。沒有他就沒有轉(zhuǎn)換率，沒有它，你就不知道站外推廣的效果如何，沒有他，你就不知道網(wǎng)站欄目，活動標(biāo)題，圖片等怎么去改版，甚至商品怎么放置!!!等等等等….
CRM也是一樣，我們現(xiàn)在的弱項(xiàng)，我們現(xiàn)在著重統(tǒng)計(jì)用戶回購率，對品牌忠誠度等一些現(xiàn)在業(yè)務(wù)上比較關(guān)注的面，沒有鉆深，但是這樣光這樣說好像有點(diǎn)太那啥，我放點(diǎn)收集的資料吧，這也是我們下一步努力的目標(biāo)。
建立CRM的最本質(zhì)目就是獲取、保持和增加可獲利客戶（消費(fèi)者）。
我認(rèn)為好的數(shù)據(jù)報表展現(xiàn)
我認(rèn)為好的二維數(shù)據(jù)統(tǒng)計(jì)分析報表必要的條件：
1.多種直觀的，美觀的圖形報表展現(xiàn) （圖1）
2.對應(yīng)的數(shù)據(jù)表格展現(xiàn) （圖1）
3.對應(yīng)的名詞解釋 （圖1）
4.相關(guān)業(yè)務(wù)報表的關(guān)聯(lián)查看 （圖2）
5.能竄起業(yè)務(wù)流程，（圖3）
圖1：
圖2：
圖3：
我自認(rèn)為我們公司的報表的美觀，直觀，清晰度都做的不錯了，但是看到另一家公司的報表之后（就是后面2張），我直接給他們跪下了。相關(guān)數(shù)據(jù)一目了然，通過數(shù)據(jù)竄起了整個站點(diǎn)流程。多好的產(chǎn)品經(jīng)理啊~！建議大家做的時候可以參考這家，量子后臺的也不錯。
后記
現(xiàn)在越來越多關(guān)注運(yùn)營,營銷推廣和各種商業(yè)模式，技術(shù)反倒變成相對不太重要的東西。路漫漫，何其修遠(yuǎn)兮，努力吧。
原文鏈接：http://www.cnblogs.com/mmmjiang13/archive/2012/07/05/2575538.html
【編輯推薦】
