前言

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

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：

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

後記

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