前言

做了兩年多針對淘寶的電子商務數據線下數據系統，越到後面越覺得自己還沒入門，不管技術上還是業務上，這篇文章既是對自己的積累的一次梳理，更想的是能在和各位朋友交流中，互相進步。

ps:所有字段並不是正式項目所使用字段，請根據自己的業務需求進行酌情查看處理,類目屬性，商品，訂單結構可以參考淘寶API數據接口進行查看具體字段。

商品模塊設計

商品模塊是支撐整個架構的核心，如果這塊沒設計好，那麽所有後期的復雜的統計需求基本都滿足不了。

為什麽這樣子設計屬性看這裏和這裏，把品牌從類目中剝離出來是為了降低程序針對商品屬性這塊的復雜度。這裏通過淘寶的添加寶貝的操作來說明上面的數據結構如何滿足下面的需求:

PS:本來要截玉蘭油沐浴露的圖，結果發現淘寶取消了以前選擇毫升*買的多送得多組合SKU的添加商品方式，改成了一個SKU就是一個寶貝的編輯手段，呵呵，沒辦法，只有上面截個衣服的圖，下面的數據卻是快消品的。淘寶這樣做這也是沒辦法的，這種快消品不同SKU，圖片還不能用一樣的，而且大部分用戶搜索的時候呢，會喜歡直接搜索具體的毫升數,這也給我們提了個醒，不同的類目可能會是不一樣的處理方式，就算是服裝這種SKU相對標準的類目，也會有說在展示和搜索結果中，會放置一個產品的多個SKU，比如凡客的網站，一件衣服的幾個顏色都會出現在類目搜索結果中，增加曝光度，吸引用戶點擊購買。

頁面屬性的編程實現可以參考這裏。SKU存放在產品SKU表中，按我們的實際需求增加修改字段，比如我的表中多了ProductCode和BarCode字段，SKU的屬性會拆分後存入產品基本屬性值表，便於搜索或統計等需求。商品的基本屬性全部打橫存入商品的基本屬性表中，那麽SKU表的存儲如下：

那麽這個item是4013的產品在基本屬性值表中的數據存儲如下：

這裏我是把所有的屬性都打成一條一條存儲在這個表中，那麽能滿足我們在日常業務的屬性搜索，統計等需求。按屬性搜索，這裏必須要註意以下幾點：

1.不可能所有的屬性都開放給用戶或者我們的客戶進行搜索，所以我們會在屬性名表中有個字段（是否搜索字段）來人工控制哪些屬性是搜索屬性

2.基本屬性是同一個寶貝下面所有SKU都共有的，SKU屬性是單個SKU獨有的，所以搜索的時候還必須分清楚銷售屬性（銷售屬性組成SKU）和基本屬性。

3.屬性圖片的存儲我並沒有設計，因為我們是做快消品，沒有這個需求。但是，如果我做的話我還會是在基本屬性值表中加上”是否圖片屬性，是否使用默認圖片，圖片URL“3個字段來記錄顏色屬性。做屬性搜索的時候比較方便。

4.產品通過關鍵字搜索和屬性搜索是分開的，兩種搜索並不是一種解決方式，比如淘寶，在首頁的搜索框是通過分詞匹配寶貝標題的關鍵字，通過關鍵字的匹配程度，店鋪的dsr評分權重來決定搜索結果，而屬性搜索的時候則是匹配滿足屬性條件的寶貝。那屬性又分第1點和第2點，所以還是挺麻煩的。

那到了這裏產品的存儲已經說完了，其它的運費什麽的，就懶得說了。

這裏你會發現有打包品表，打包品子表，最終商品表，商品變更記錄表。這裏需要詳細說明一下。

首先說一下打包品概念：

打包品：為了各種運營上的需求，很多時候我們會人為的把多個SKU組合成一個商品進行組合銷售，我們在淘寶購物的時候，經常會看到這樣的情況，A產品+B產品組合銷售，AB的組合在淘寶上面表現為一個寶貝，你看看這裏或者這裏或者這裏，這些就是拉。這種銷售數據在訂單裏表現是一個淘寶商品，但是我們要做庫存管理，數據分析等需要拆分出來。這是必須考慮的！

PS：有那種出廠打包品，比如一個包裝盒裏面有香皂，有沐浴露，但是它們本身就是一個SKU，出廠就這樣，所以不能和打包品混為一談。

由於我們運營上的需要，我們可能賣單個SKU，也可能賣多個SKU的組合，那麽在我這裏把單個SKU和多個SKU組合都看成打包品，單個的SKU打包品它的子項只有它自己，這樣做的好處是，系統中只需要一種方式來處理這種關系。在打包品表中通過類型來區分。

這裏有一個關鍵問題要註意，我們在出售商品過程中，價格是可能會隨時人工或者系統來幹預變化的，比如產品A標題叫B洗發水+C護發素直降20元，但是我們根據實際的流量和轉換率價格可以上下浮動，那麽我們就要及時的調整價格，所以我們的標題，價格都需要進行更改，這裏牽涉2個問題，我們是新建一個打包品或者我們是另外放在最終商品表，我們就需要修改對應的標題和價格，同時呢，在商品變更記錄表中記錄添加一個上次修改的備份，作為我們對不同價格的轉換率的一個分析基礎數據。第二個問題就是由於修改了打包品或者創建了新的打包品（SKU子項，SKU數量一樣）價格，那麽對應的分配到每個具體SKU的價格發生了變化，這裏如果是新建了打包品就沒問題，但是如果是修改打包品，那麽我們對打包品SKU子項的價格就必須通過相應的公式進行計算。比如A+B+C今天是100元，A是30，B是50，C是20,如果價格變成了90或者110，那麽對應到具體的子項價格也需要更改，因為很經常的需求就是統計某產品或者某SKU的銷售量和銷售額。

所以最終是我們網站上是出售打包品還是最終產品，是每次新建打包品還是修改，這要看自己權衡。但是商品的價格變更是一定要記錄的。一是留備份，二是分析價格對銷售的影響等等。

這樣設計遇到的問題

1.起初產品維護人員意見很大，覺得很復雜，工作量很大。因為這種結構需要維護人員維護屬性，並且需要他們懂一些專業知識和熟悉整個流程，各種名詞搞得他們頭暈，後面甚至出現了相當大的負面抵觸情緒。這個沒辦法，因為我們這個不是網站，不是說讓你簡單的舒服的就能添加一個商品，這個需要掌握分類-產品-屬性-打包品之間的業務關系以及這樣維護的好處。解決辦法：1.慢慢溝通，說明增加的工作量是為了他們在出復雜的報表的時候不需要手動去進行篩選，而且基礎數據維護好了，一勞永逸。2.一定要培訓好產品維護人員，讓他們在有相關業務背景人員指導下能清晰的分清楚屬性的意義，以及根據業務規則維護好屬性基礎表和錄入產品等信息。

2.由於一開始數據的關聯檢查機制沒做好，導致後面亂了很多數據，所以在後面又來花時間檢驗數據和建立起相應的檢查機制，浪費了很多時間。

訂單模塊結構

這裏關系很簡單，我想著重說明3個問題，

1個就是訂單主表中存儲地址庫ID+買家具體地址組合成購物地址，不是依賴用戶收貨地址的信息，因為用戶的收貨地址是可能發生人為的修改的。

2.地址庫的城市級別，這是一個統計維度，最好加上

3.在訂單子表中，不僅存儲了打包品的ID，還會把當時網站上該商品的標題和SKU名字，以及當時的價格存儲進來，這是很有必要，不能直接使用關聯的打包品或者商品的價格，標題，前面說了，隨時可能改變的。

4.促銷信息表，這裏就是記錄所有促銷活動信息，一個商品可能對應多個促銷活動，比如使用了優惠券+（滿200-20）+ 滿100包郵+VIP優惠10元+XXX。這樣的設計是比較好的。從訂單角度來看這個訂單應用了多少個活動模型，能準確的抽取某種促銷活動的所有訂單。

不要把這種東西設置產品表中，或者與產品表進行關聯，先不考慮其它原因，首先把業務模型和產品模型混在一起就亂了。

活動模塊設計

由於我們的訂單表有訂單活動促銷信息表與其關聯，那麽實際上我們統計一般的需求只需要關聯過來活動模型表就能得到說某個活動或者某類活動的數據情況，這裏對於前臺商品活動信息是個悲劇，一套活動緩存跟新機制，前臺所有商品顯示的時候和所有訂單提交時檢查是否滿足所在時間內的活動模型來展示不同的UI。

還會有很多活動模型，這裏只是列了幾個，另外，必須註意一個問題，只要涉及到包郵的地方就要考慮有的地方不能包郵。也可以單獨存儲不包郵的城市。這個就要看業務上如何決定這個模型怎麽建立。

訪問跟蹤模塊設計和CRM

訪問數據這一塊我們是結合量子統計和自己跟蹤的數據進行合並數據出數，這塊我就過掉了，因為這塊感覺我們並沒有做太深，今年會單獨把這塊加強。我只想說，這塊很重要。這一塊是電子商務運營過程中的重中之中，沒有他，幾乎所有的帶有指導性的報表數據你都沒辦法出。沒有他就沒有轉換率，沒有它，你就不知道站外推廣的效果如何，沒有他，你就不知道網站欄目，活動標題，圖片等怎麽去改版，甚至商品怎麽放置!!!等等等等….

CRM也是一樣，我們現在的弱項，我們現在著重統計用戶回購率，對品牌忠誠度等一些現在業務上比較關註的面，沒有鉆深，但是這樣光這樣說好像有點太那啥，我放點收集的資料吧，這也是我們下一步努力的目標。

建立CRM的最本質目就是獲取、保持和增加可獲利客戶（消費者）。

我認為好的數據報表展現

我認為好的二維數據統計分析報表必要的條件：

1.多種直觀的，美觀的圖形報表展現 （圖1）

2.對應的數據表格展現 （圖1）

3.對應的名詞解釋 （圖1）

4.相關業務報表的關聯查看 （圖2）

5.能竄起業務流程，（圖3）

圖1：

圖2：

圖3：

我自認為我們公司的報表的美觀，直觀，清晰度都做的不錯了，但是看到另一家公司的報表之後（就是後面2張），我直接給他們跪下了。相關數據一目了然，通過數據竄起了整個站點流程。多好的產品經理啊~！建議大家做的時候可以參考這家，量子後臺的也不錯。

後記

現在越來越多關註運營,營銷推廣和各種商業模式，技術反倒變成相對不太重要的東西。路漫漫，何其修遠兮，努力吧。

非小型電子商務系統設計經驗分享