轉載：原文根源實在是找不到。。。
本文爲作者對平時工作的思考總結，包括商品中心的設計、訂單拆單的實現、促銷活動及優惠券的設計使用等，對相關從業者，有借鑑意義。歡迎留言交流討論。
本文包括以下幾個部分：
-
電商後臺系統概述
-
電商後臺產品設計：商品中心
-
電商後臺產品設計：訂單拆單
-
電商後臺產品設計：促銷活動解析
-
電商後臺產品設計：優惠券的設計和妙用
一、電商後臺系統到底是怎麼回事兒
每年的“雙十二”“雙十一”人造購物節一來，電商羣戰就好不熱鬧，馬雲卻預言純電商時代已去，新零售時代已至。作爲一名電商產品經理，身處如此時代，亦會覺得不負青春。
做產品以來，主要做後端支撐產品方向，目前對各模塊系統都有所涉及。初次接觸時，在網上找了很多資料，發現關於產品的相關文章，大部分都是關於產品體驗、交互、APP等，提及後臺的文章基本淺嘗輒止，很少有文章來系統介紹後臺各模塊（商品、訂單、營銷、物流、支付、會員、評價、採購...）,就計劃寫一系列關於後臺各模塊的產品設計文章，希望能夠幫助在產品路上成長的PM。
後臺系統，也不能叫做一個系統，很多公司將其拆分爲很多子系統，阿里更將其發展成了中臺事業羣（搜索事業部、共享業務平臺、數據技術）。後端一系列系統支撐着公司各種業務的進行和發展，前端展示、業務處理（訂單、優惠券）、庫存變動等進行時，後端各系統間互相調用接口進行數據更新。
由於商業性質決定了電商業務支撐系統必須具備穩定性、可擴展、安全性強等特點，PM在設計產品架構時，應充分考慮到業務發展需要，儘量將各模塊隔離，商品模塊建個商品中心，訂單模塊建個訂單中心等等。
只有在產品設計上有模塊化思想，具有前瞻性，技術在開發時纔會考慮業務隔離，當業務調整、功能新增時，開發可迅速進行，避免牽一髮而動全身的事情反覆發生。
針對一般電商業務，我簡單畫了一張產品模塊示意圖，基本一些中小型電商公司的產品架構大致如此。除了圖中所示，現在很多電商公司開始轉型社交電商，採用UGC模式或直播電商，在產品架構上會新增資訊系統，實現資訊與商品的高度融合，本文不過多涉及。
對電商公司來講，最核心最難做的三部分：商品、訂單、庫存。
商品與店鋪、營銷、評價等相關，訂單與會員、營銷、支付、庫存、物流等相關，庫存與訂單、採購、WMS、營銷等相關，系統之間業務邏輯和交互異常複雜，規則多樣。
-
商品中心：主要管理SKU(最小庫存單位)、SPU（標準化產品單元）、屬性（關鍵屬性、非關鍵屬性、銷售屬性）、類目品牌、價格等有關商品的數據；
-
訂單中心：管理訂單類型、訂單狀態，落下關於商品、優惠、用戶、收貨信息、支付信息等一系列的訂單實時數據，進行庫存更新、訂單下發等一系列動作；
-
支付中心：主要調用第三方支付平臺接口，記錄支付信息（對應訂單號、支付金額等）；
-
會員中心：主要管理用戶等級、用戶權益、積分、卡券等會員相關信息；調度中心主要將訂單信息轉化爲發貨通知單，調度倉庫和物流進行發貨；
-
客服中心：主要管理退貨退款、售後服務等操作，包括呼叫中心、在線客服等，與之對應的是工單系統，將客服任務進行隊列管理，分配給相應的客服；
-
營銷中心：主要管理活動相關，優惠券、滿減、專場活動、促銷專區等，營銷工具的開發對電商尤其重要，營銷活動的濫用造成的用戶疲勞，怎樣推陳出新，給電商產品經理造成了很大挑戰；
-
運營中心：主要是對用戶端進行頁面配置（Banner、ICON、TAB）、價格管理等，一般會營銷中心併入運營，作爲其一部分；
-
評價中心：管理商品評價和用戶反饋，這並沒有想象的那麼簡單，涉及到一些敏感詞和敏感圖片的篩選，以及回覆內容管理；
-
店鋪管理：功能龐雜，相當於提供給B端用戶一個Saas管理後臺，提供管理商品、營銷、訂單一系列功能，主要針對一些有to B業務的電商開放平臺；
-
採購中心：管理SKU，當庫存預警時，及時生成採購單進行入庫，有供應商管理模塊，主要進行供應商管理評級，發展新供應商等功能；
-
財務管理：主要和訂單、採購系統相關，數據準確性要求較高；
-
WMS系統（倉庫管理系統）：主要是入庫、出庫、盤點等模塊，WMS主要和調度中心進行數據交互，反饋出入庫狀態和庫存變動；
-
物流中心：主要進行運費模板、運費管理（前端訂單、真實物流成本）、物流狀態保存查詢（快遞100、菜鳥等關聯），如果是跨境電商，還涉及到和海關總署的對接，進行報關操作。
-
風控中心：主要利用大數據進行用戶信用建設、反欺詐，避免惡意評價、刷單退款等操作，構建安全的電商購物環境。
對電商後端支撐線各模塊的業務功能有初步認知之後，可以看到的是，平常手機中的一個電商APP，背後是若干系統在支撐着，亦是許多技術和產品人員在辛苦付出。
以客戶下訂單爲例來介紹業務信息在各系統之間的流轉，涉及主要的信息交互如下圖所示。從用戶選擇商品、生成訂單到訂單出庫、物流配送、用戶簽收、退貨退款，信息在多系統中流轉更新數據。
從圖中可以看出前臺的一小步，後臺的一大步。對於產品經理來講，理清各系統之間的業務邏輯，特別是在商品類型多樣（服務商品、實物商品、服務加實物商品等），業務複雜（預售、代銷、代發等）時，各系統模塊的隔離，設計時考慮擴展性非常必要。
二、如何設計實用的商品中心（前端顯示篇）
每天逛淘寶和京東的時候，映入眼簾的都是品類繁多的商品，但是當我們選擇分類或者直接搜索的時候，按條件篩選時，系統卻往往能從千萬商品中提供心中想要的商品；在瀏覽商品時，商品主圖、詳情圖、規格等信息讓我們感覺比在超市拿着實物獲得更多信息，電商系統到底是怎麼做到這些的呢？
簡單粗暴地講，商品中心是用來管理核心的商品數據。對於使用的維度：從前端來講，是給商品展示、訂單、營銷活動提供商品數據支撐，從後端來講，商品中心給訂單發貨、倉庫管理、供應商管理、採購提供基礎數據支撐。
爲了更清晰地描述商品中心這項重量級工程，文章分爲兩部分從上述兩個維度來闡述，第一部分主要從後端的維度介紹商品中心。第二部分主要從商品前端顯示來說後臺設計的那些事兒。
一、 商品常用概念介紹
先介紹幾個基本概念：SKU、SPU、屬性、類目。
-
SKU
stock keeping uint（庫存量單位），庫存控制的最小可用單位。例如Iphone 7plus 128G 銀色就是一個SKU，倉庫管理、採購進貨、庫存顯示的都是SKU。
不同的公司都有自己的SKU編碼規則，如果有自己的倉庫，在商品入庫時一般會打上自己的SKU碼，這樣整一套庫存體系就會自上而下打通，當然還有另一種處理方式，設置自有SKU碼與供應商條碼的對應關係，將訂單轉化爲發貨單時，將自有SKU碼轉化爲供應商的條碼。
對大公司來說，推薦前一種做法，後一種由於供應商編碼規則不同，或者管理規範，在實際操作往往會增加出錯率。
-
SPU
standard product unit（標準化產品單元），是一組標準化信息的集合，例如Iphone 7plus就是一個SPU。SPU與SKU的關係有許多種，可以一對多，一對一，如下圖所示。
SPU信息中應該包含SPU屬性、產品圖片、產品描述、產品標籤。SPU和SKU之間是通過規格來鏈接的。
SPU(Iphone 7plus)通過顏色、內容關聯到SKU(Iphone 7plus 128G 銀色)。SPU的庫存是由其對應的SKU庫存共同決定的。
-
屬性
分爲關鍵屬性、銷售屬性、非關鍵屬性。
關鍵屬性是指能夠唯一確定產品的屬性，是必填項。例如手機的品牌、型號屬於關鍵屬性；銷售屬性組成SKU的特殊屬性，或稱爲規格屬性，如手機的”顏色”、”內存”；非關鍵屬性指的是除關鍵屬性、銷售屬性外的其他屬性，如手機的手機接口類型，非關鍵屬性不一定是非必填項，有時爲了商品信息完整，也會設爲必填項。
屬性定義對於良好的消費體驗有着至關重要的關係，對搜索、索引、篩選都有至關重要的作用。
-
類目
分類樹，電商常用的有兩層類目，前臺展示類目，後端商品類目。
前臺類目指的是展示給消費者的類目，會根據季節、銷售策略、活動進行變動；後臺類目屬於基礎數據，不可隨意變動，添加SKU時都需要選擇類目，進行綁定。
需要注意的是，類目樹的層次不能太深，一般三層或四層，如果太深，不論對於管理還是技術性能來說，都是不利的。前臺類目與後臺類目可隨意搭配，設置前臺類目關聯時，對前臺類目樹最深層進行設置，可讓其關聯後臺類目任一層，可一對一、一對多。前臺類目還可以對應品牌。
二、商品基礎資料設計
在介紹商品常用概念時，也透露了很多在產品設計時關聯的信息。在添加SKU時，需要選擇品牌、填寫一些屬性，以及關於倉庫管理的基礎數據（長寬高、重量、供應商等）。
商品中心基礎資料結構圖主要如下，首先是品類管理，主要包括品牌管理(中英文名、可供品類、產地（跨境電商比較重要）)、屬性管理（針對類目添加相關屬性和屬性值）、類目管理（後端類目樹重中之重，確定時要考慮全面，屬於基礎數據，後續更改比較麻煩。），大致產品框架如圖所示。
在添加SKU時，通過供應商去關聯採購，進而影響倉庫中SKU的庫存。
供應商在添加SKU時亦可不選擇，可以在採購系統中添加關聯。
通過銷售屬性去關聯SPU與SKU，同一SPU在前臺顯示時可以共用同一商品詳情，只是通過規格屬性映射到具體的SKU；針對商品的關鍵屬性和屬性值，可以在商品搜索和篩選時用上，良好的屬性定義對於顧客決策樹的縮短有着至關重要的作用。
三、覆盤
商品中心後端屬於基礎數據，會被許多子系統調用，對於電商公司來說重中之重。商品中心提供接口數據進行倉庫管理、採購管理、庫存管理、訂單管理，可擴展的商品中心結構將給公司業務發展帶來很大益處。
文後擴展，很多電商公司業務定位都是B2B2C，爲了擴充SKU，增加用戶量，或者構建平臺體系，都會允許第三方來平臺管理商品，類似京東、有贊，這類平臺的商品結構更加複雜，SKU需要增加所屬商家，商品詳情、屬性值、庫存都需要相互獨立，在SKU、SPU緯度上增加一個商家緯度。這裏不做過多擴展，感興趣的朋友可以深入思考。
三、如何設計實用的商品中心 （後臺設計篇）
用戶平常購物接觸到最多的就是商品顯示頁，商品列表、商品詳情頁的基礎信息都是從商品中心獲取。
目前對於商品設計有着成熟的產品方案，電商網站的商品產品結構大同小異，淘寶上的商品以SPU形態顯示，京東上以SKU形態顯示，兩種處理方式各有優劣勢（表達可能不太準確，但認真研究過兩者商品結構應該理解我說的不同點，下文解釋）。
其實我更傾向於淘寶的商品結構，能夠支持更加靈活的商品方案。
京東與淘寶的商品詳情頁
商品信息主要由類目、標題、品牌、商品屬性、規格（京東定義爲銷售屬性）、價格、庫存、SKU信息（毛重、長寬高等）、商品圖、商品詳情描述、物流信息等組成。至於經常看到的服務標籤（白條、極速退款）、商品標籤（熱銷）、活動標籤（滿減、優惠券）、價格標籤（拼團價、活動價）、同類商品等都是在商品信息上的包裝層，不在本文的闡述範圍。
一、商品類目、商品基本信息
商品類目分爲兩層，基礎數據類目層、前臺展示類目層，在添加和管理商品時，都是在基礎數據類目層對商品進行管理（如下圖）。商品屬性、銷售屬性及品牌等很多數據都是在基礎類目上進行管理，所以類目管理屬於較爲核心的工作，一定要從長遠角度考慮。
在添加商品時，需選擇對應的類目。前臺類目在展示時，有兩種處理方式：
-
前臺類目對應後臺類目，可一對一、一對多、多對多，自由組合，動態調整。現在大部分自營電商都是用的這種類型。
-
前臺類目直接對應商品，適合商品較少的小商家，主要是一些電商平臺提供給平臺上商家的類目服務，添加商品時直接選擇前臺展示的類目。
另外，類目一般是分爲三層，類目樹不要太深，否則將影響產品效率。
JD商品類目
設置商品信息、副標題（一般介紹產品賣點、促銷），選擇商品對應的品牌。
在品牌管理中，有兩種方案：1.品牌統一管理，小公司商品豐富度較少時的方案。2.品牌關聯類目，商品豐富度高的選擇。
基本信息編輯
二、商品屬性
商品屬性包括屬性名、屬性值，一般都是掛在具體類目子葉下，設置必填和非必填。在設置屬性值時，須保留一定的擴展性，部分允許自定義屬性。商品屬性管理要求強大的類目運營能力，在中小型電商平臺一般會提供基礎屬性值，再開放自定義屬性編輯，讓用戶來完善屬性庫數據。
商品搜索能力，除了標題、類目，很大部分依賴於商品屬性，條件篩選的基礎數據也是商品屬性和規格屬性。完善商品屬性對於良好用戶體驗至關重要。
淘寶的商品屬性（男裝>風衣）
三、規格、價格、庫存、SKU信息
在購買商品時，我們會經常選擇規格（銷售屬性），主要包括顏色、尺寸，爲了支持多樣化的用戶需求，選擇之後可以編輯規格。規格一對一確定之後，可單獨設置價格、庫存、商家SKU，淘寶上亦可添加條形碼（69碼）。
也可以設置統一價、統一庫存。填寫商家SKU主要是爲了方便對應到具體的實物，上文亦講過，倉庫和採購管理的都是具體的SKU。
仔細觀察會發現，京東的商品標題是加上具體的規格，在選擇規格時會跳轉SKU，對於落單數據有效率提升，但是對於頁面效率和體驗是不如淘寶的SPU結構的。現在大部分電商都採用的是淘寶的SPU結構，亦是優質選擇。
JD規格、價格、庫存、SKU設置頁面
在淘寶上選擇具體的規格後，會發現商品縮略圖會發生變化，這就需要在管理商品時，針對某規格單獨上傳圖片。這裏有個設計很巧妙的地方，只是不同顏色需要上傳對應的商品縮略圖，而尺碼不需要。
淘寶不同顏色上傳具體的縮略圖，京東可上傳多圖
針對商品設置平臺價和市場價，主要是爲了商品在列表展示商品、未選擇具體規格時展示，相當於商品的均價。毛重、長寬高等數據主要是爲了物流而設置的，自建倉庫的自營電商一般在SKU數據層就會錄入這些數據，直接調用。
貨號即商品編碼，在商城購物時會掃描的條形碼就是貨號。貨號不等同於SKU編碼，同一商品編碼的商品可能是不同SKU，有着不同的規格，所以不能直接拿貨號來管理SKU。
JD商品信息填寫
四、商品圖、商品詳情描述、物流信息
除了不同規格對應的商品縮略圖，商品圖還包括商品主圖，一般要求圖片質量較高，包括整體圖和細節圖。商品主圖是吸引顧客眼球的必要利器，不論是列表頁，還是活動頁，顧客除了關注價格，主要就是商品主圖，運營上架時需對商品主圖較爲慎重。
商品詳情頁現在一般會區分電腦版和手機版，由於兩者的使用場景和設備不同，側重點也不相同。爲了更好的展示產品特點，可提供不同的產品詳情模板，亦可支持不同的富文本編輯。
商品詳情描述
選擇運費服務時，要選擇對應的物流模板（包郵、按重量、按件數等），在訂單處理是按照具體的物流模板計算運費。運費模板計算較爲多樣複雜，下篇文章詳細描述講解物流運費相關的細節。
商品物流選擇
五、其他商品信息
主要包括售後服務（發票、保修服務、退換貨）、包裝清單等相關說明。
六、上下架管理
設置完商品基本信息之後，設置上下架時間，亦可直接上架發佈。和商品相關的活動，一旦商品下架，活動將失效，無法購買。搜索、篩選的商品範圍都是在上架的商品範圍進行。
上下架設置
在商品管理層面，平臺電商提供給平臺商戶的商品服務與自營電商自己的商品服務有着很大不同。最大區別在於自營電商比平臺電商多SKU管理，庫存和屬性都是基於SKU進行管理，在添加商品時，如果還要重新填寫，就會造成數據冗餘。所以一般會共用數據。
四、電商後臺產品設計：優惠券的設計和妙用
優惠券是一種常見的促銷方式，在規定的週期內購買對應商品類型和額度的商品時，結算時滿足一定條件會減免一定金額。通過發放優惠券，引導用戶購買相應的商品，在下單的時候抵扣一定的費用，達到促銷、提高客單價的目標。
優惠券不論在線上還是線下，適用範圍都比較廣泛。例如滴滴發的專車券、外賣平臺發的外賣券、京東淘寶的優惠券等。
一、優惠券的類型和應用場景
優惠券有多種分類方式，按照使用門檻、使用範圍、發放主體等有不同的分類。
1.1 按照使用門檻分爲現金券、滿減券、折扣券。
現金券：不限制訂單金額，可以直接使用。
滿減券：訂單金額需要滿足一定的最低額度纔可使用，例如：滿100減10元優惠券。
1.2 按照適用範圍分爲：單品券、品類券、品牌券。
單品券：購買優惠券指定商品時可使用，這種優惠券一般只針對少量特殊商品可以使用。
品類券：購買優惠券指定類別的商品即可使用，除個別特殊商品。
品牌券：購買優惠券指定品牌的商品時可使用，除個別特殊商品。
一般按照品牌或者品類設置優惠券範圍是比較常見的方式。
1.3 按照發放的主體分爲平臺優惠券和店鋪優惠券
平臺優惠券：優惠由平臺承擔，比如平臺活動優惠券、平臺註冊的新人優惠券、平臺積分兌換的優惠券。
店鋪優惠券：在平臺上的店鋪自己發放的優惠券，比如淘寶上的店鋪優惠券、京東的店鋪優惠券。
平臺優惠券的金額由平臺承擔，在店鋪使用時優惠金額由平臺返給店鋪；店鋪優惠券的成本由店鋪自己承擔。
二、優惠券的設計規則
從優惠券的生命週期，來設計優惠券是最恰當的。
優惠券週期
2.1 生成優惠券
在生成優惠券時，主要是從優惠券信息和推廣信息兩方面來考慮優惠券的設計。
2.1.1 優惠券信息
-
優惠券名稱
-
類型：現金券、滿減券、折扣券
-
面值：例如10元。
-
使用條件：滿XX元可用
-
使用平臺：客戶端、H5商城、主站、各分銷渠道
-
有效期時間：絕對時間（時間段）、相對時間（領取之日後多少天有效）
-
發行量：優惠券張數（設置限額）
-
使用範圍：平臺券（全平臺通用）、店鋪券（僅在某店鋪可用）
-
商品範圍：全品類、限制品類、限制商品
2.1.2 推廣信息
-
發放方式：可發放可領取、僅可發放(只能由平臺發放給用戶)、僅可領取（只能用戶自己領取或兌換）
-
推廣範圍：免費領取、積分兌換
-
優惠券是否公開：設置公開後，在領券專區、商品詳情頁、購物車都默認展示
-
限領：每人僅限一張、每人每天限領一張
-
券領取時間：設置領取時間段（過期）
-
在優惠券生成之後，將優惠券顯示在優惠券列表中。
2.2 發送優惠券
優惠券有主動領取和被動領取兩種方式。
主動領取：
用戶在店鋪首頁或者平臺上看到優惠券，主動進行領取；用戶在線下看到宣傳推廣；朋友圈優惠券分享鏈接等等。
這種發放方式需要一定的運營成本，需要打動用戶，產生興趣進行主動領取，這種方式需要做好防作弊機制，真正獲取到的用戶價值較高。
被動領取：
系統主動給用戶發送相應的優惠券，但是這種大面積分發的方式，用戶精準度低，轉化率較低，只能很少促進客單量。
系統發放優惠券場景有很多種：1.用戶註冊；2.大促活動；3.還有客服發券，主要是售後補償（平臺責任導致售後，發券補償客戶），或者好評返現。
除了以上的方式，還有許多平臺電商的一項業務：大客戶團購，主要是給一些單位提供的福利卡，例如京東卡。可以通過優惠券（平臺幣）的形式實現，生成相應的卡密（或兌換碼），製作實物卡售賣給一些公司發福利、送禮。用戶輸入卡密兌換之後，兌換成平臺的交易幣（相當於給購物卡充值），可以用來抵扣訂單金額。
發送優惠券雖然在前端頁面只是簡單的一個交互，但是後端有大量的邏輯需要處理。
校驗用戶登錄狀態 → 優惠券信息讀取（是否在有效期、是否可發放、剩餘數量） → 優惠券綁定用戶
2.3 優惠券覈銷
在用戶下單時，肯定是需要系統從其賬戶中的優惠券選擇合適的優惠券推薦給其使用的。我思考的推薦算法應該分三步：
-
從用戶優惠券列表中選擇出當前訂單可用的優惠券（包括通用券和相應產品優惠券），主要是從有效期、商品範圍等條件判斷
-
若有多種可用優惠券，但是金額不同，默認選擇可抵扣最高的優惠券。
-
如果金額相同，先匹配同類優惠券的優惠券，但當優惠券的額度（現金券）大於支付額度彈出提醒框，確認是否使用。
注：在用戶的優惠券列表中，優惠券是否失效也是實時拉取的（失效過長應清除此優惠券），下單時優惠券選擇應僅顯示用戶可用優惠券。
2.4 優惠券統計
主要統計優惠券的發送張數、使用張數。深度數據挖掘可以統計優惠券對應的客單價、復購率等等。
三、優惠券的前端展示
優惠券的前端露出窗口主要有五處：用戶優惠券列表、訂單提交頁、購物車、商品詳情頁、領券中心（或優惠券分享鏈接）。
前端展示的難點在於商品詳情頁和購物車中展示可用優惠券。需要高效率的算法來計算匹配商品對應的優惠券，主要有兩點好處：1.優惠券來促進用戶消費；2.在用戶消費時幫助用戶省錢。告知用戶有優惠可以享受，避免用戶下單之後看到相關優惠沒有享受到產生不平衡心理。
優惠券（京東）的前端透出
四、優惠券在訂單中的處理
下單時優惠券的匹配在前面已經敘述過，主要是分爲三步，詳見2.3優惠券的核銷。本節重點講解優惠券的逆向流程。
在訂單完成售後（退款或退貨）時，優惠券應有一定的返還機制。
-
統一設置成不可返還，用了之後就不退。
-
訂單中全部退款時，優惠券全部退還。
-
訂單中部分退款時，普通優惠券不返還，現金券按金額比例退還。
優惠券有着一套很成熟的產品設計方案，介紹之後，再提一個目前絕大部門產品難以解決的問題：基於日常優惠券的使用情況，運營人員如何平衡發放優惠券所帶來的成本增長，商品銷量增長和單品毛利下降之間的矛盾？在申請促銷活動經費時，怎樣的數據更具說服力？
五、電商後臺產品設計：促銷活動解析
促銷是最常見的電商運營手段，每到重要節日，類似雙十一、618、情人節等等，商家在線上或是線下都會展開瘋狂的促銷大戰，通過各樣的形式吸引消費者。作爲電商的從業者，應該對各種促銷手段有所瞭解。這部分內容將從產品設計的角度來介紹各種促銷手段。
一、促銷綜述
促銷就是營銷者向消費者傳遞有關產品的各種信息，吸引或促進消費者購買其產品，以達到擴大銷售量的目的。促銷對提高客單量、客單價、復購率甚至註冊量都有一定的好處。很多電商平臺或店鋪在起步階段會通過大量的促銷活動來吸引消費者，獲取流量。
促銷有利有弊，對平臺來說不一定是好事，頻繁的促銷容易給顧客產生疲勞，透支未來收入，甚至會降低品牌定位。
二、促銷的各種類型
促銷有多種形式，目前電商系統能夠支持的促銷形式我大致總結了一下，大約有7種：滿減促銷、單品促銷、套裝促銷、贈品促銷、滿贈促銷、多買優惠促銷、定金促銷。
這7種促銷形式幾乎囊括了各電商平臺所有的促銷方案，特別提一下“定金促銷"的形式在2016年雙十一開始廣泛應用，對電商供應鏈的備貨和物流控制大有益處。
-
滿減促銷：購物者只要購買相應商品到規定價格即可得到一定的減價優惠。主要有兩種形式：階梯滿減、每滿減。階梯滿減，例：滿100減10、滿300減50、滿500減80；每滿減，例：設置每滿200減20，則訂單金額230元實付210元，訂單金額430元實付390元。
-
單品促銷：在特定時間內購買指定商品享受一定的價格優惠。例：促銷期間商品6折，原價100元，購買時60元。
-
套裝促銷：商品組合套裝以優惠價出售，例如：A商品50元，B商品80元，A+B商品套裝促銷價100元。
-
贈品促銷：購買主商品之後贈送商品（可多個）。
-
滿贈促銷：有滿XX元送XX商品、滿滿XX元加價XX元送XX商品，與贈品促銷的區別在於以相應商品訂單的價格來區分，可分階設置，例如滿300元送自拍杆，滿500送充電寶，滿1000送高端耳機等。
-
多買優惠促銷：有M元任選N件、M件N折兩種優惠形式。這個主要是參考一些線下賣場發展的促銷形式。
-
定金促銷：在商品正式售賣之前採用預付定金的促銷模式，提前交定金可享受優惠價。定金預售有多種玩法：定金預購，相當於定金就已經確認訂單；定金槓桿，例如定金10元可抵扣30元。
三、促銷的後臺設計
剛剛介紹到的幾種促銷方式在設計上都大同小異，主要分爲活動條件、主商品信息、贈品信息（有些無贈品）這三部分。
3.1 活動條件
主要包括促銷活動名稱、促銷時間、限購數量、促銷範圍（全網、APP /微信商城）、會員級別（全員 or 新註冊用戶 or 某等級會員）、活動備註、活動規則。
活動規則即最核心的設置，例如：滿800元減60，3件150元。
滿減規則設置（來自京東）
3.2 主商品信息
選擇參加活動的商品，可按SPU、分類、品牌等來選擇參加促銷的商品。
除此之外，還要判斷當前所選商品是否參與其他促銷活動，與此活動由衝突。例如A商品參加4月的活動，滿400元減20元；再次設置該商品參加滿400減50的活動，就應與該商品已參加活動衝突，不可設置。
設置主商品（來自京東）
3.3 贈品信息
選擇參加活動的贈品，贈品一般有數量限制。有兩種規則，贈品全送，或在多贈品中選擇幾件。爲減少系統複雜度，減少用戶理解難度，建議採用贈品全送的規則。
另外對於滿贈促銷的形式，若要設置分級贈品（滿300元送自拍杆，滿500送充電寶，滿1000送高端耳機），就需要對贈品分開進行設置。
設置贈品（來自京東）
對於後臺產品來講，重點在於設置規則之後在商品詳情頁、購物車的促銷信息展示以及訂單頁面的促銷活動判斷邏輯。
四、前端展示
在商品詳情頁，要去判斷商品對應的所有促銷活動，例如加價購、滿贈、贈品等促銷活動。
商品詳情頁的促銷信息（來自京東）
在購物車，除了展示促銷信息（滿贈、滿減、套裝、換購）的作用，還可以讓用戶在多優惠並存只能選其一的情況下，可以選擇修改促銷方案。（感覺京東已經把購物車的功能做到極致了）
購物車的促銷信息（來自京東）
在訂單詳情頁，判斷當前所選商品的促銷信息（促銷價、贈品、換購商品等），將所有相關商品記入訂單信息中，再算出促銷價格。
訂單頁的促銷信息（來自京東）
企業利用各種促銷的方法和手段，使消費者瞭解和注意企業的產品、激發消費者的購買慾望，並促使其最終購買。每年源源不斷的促銷已經造成消費者對促銷麻木，只有在促銷與正常銷售之間尋找合適的平衡點，纔是企業的生存之道。
六、電商後臺產品設計：訂單拆單
最近在做拆單的需求，細思極恐，思考越深入，就會發現裏面涉及的東西越來越多，要想做好訂單拆單的功能，還是相當有難度，因此總結了一下拆單功能細節，分享出來。
拆單也有兩個層次，第一次是在提交訂單後支付之前拆單，這次是拆分的訂單，一次是在下單之後，發貨之前，去拆分發貨單（SKU層面）。
兩次拆單的原則不同，第一次拆單是爲了區分平臺商家、方便財務結算，第二次拆單是爲了按照最後的發貨包裹進行拆單，如不同倉庫、不同運輸要求的SKU、包裹重量體積限制等因素（第二次拆單的有些步驟可以放在第一步）。
需要注意的是，若是跨境商品平臺，則需要在支付前完成所有拆單步驟，因爲報關需要三單對碰，訂單、支付單、運單統一。
一、 爲什麼要拆單
拆單，顧名思義就是客戶在下單之後，爲了發貨和結算方便，需要對訂單進行拆分。
影響拆單的因素主要有以下幾點：
-
店鋪商家。由於商品歸屬權不同，涉及到財務結算和發貨的問題，店鋪商家不同，需要拆分訂單。例如京東自營和平臺商家的商品在下單時會拆分成不同的子訂單，售後入口不同。或者不同淘寶店同時下單會按照店鋪進行拆單。
-
倉庫。由於發貨倉庫不同，按照商品歸屬的倉庫進行拆單，若有多倉有貨，還應按照地域時效選擇倉庫進行拆單。
-
品類。由於商品屬性和價值得不同，同樣會產生拆單需求。例如易碎品需要特殊包裝，超大物品（兒童座椅、輪胎）需要單獨包裝。甚至有些品類不同的商品不能放在一起，都需要來定義拆單規則。
-
物流因素。不同物流公司對單個包裹的重量或體積都有特殊要求，需要根據sku的毛重和體積計算包裹總重量和體積，超出物流公司限制的也需要拆單。
-
商品價值。這塊的拆單主要是跨境海淘商品，國家政策規定：跨境電子商務零售進口商品的單次交易限值爲人民幣2000元，個人年度交易限值爲人民幣2萬元。當單次購買超過2000元（單倉）之後，就需要對訂單拆單。（總不能告訴用戶少買點，不要超過兩千吧！）
二、拆單流程
根據拆單的一些影響因素，需要對訂單進行拆分。由於跨境電商和國內電商的區別點：
-
跨境電商一般是單品單倉，同一個SKU只在一個倉庫有，而國內電商一般有多個區域倉，從時效最高的倉庫發貨；
-
跨境電商需要報關，必須三單統一，所以拆單隻能發生在下單後、支付前，而國內電商除了平臺商家不同需要在下單時就拆單，其他的拆單步驟可在下單之後再拆發貨單；
-
報關限額，只有跨境電商需要考慮。
下圖簡單解析一下拆單的流程：
拆單流程
三、拆單之後的前端顯示
在提交訂單之後、支付之前的拆單訂單，需要即時顯示給用戶，若用戶中斷支付，再回到支付環節，就需要分開支付。用戶就能知道，是不同的包裹發過來的，分屬不同的子訂單。
訂單拆分（淘寶）
在支付之後，系統根據一些影響因素進行拆單，同一個子訂單可能會對應多個物流單，在訂單顯示頁面查看物流時，需要展示多個物流信息。但是現在多個平臺只能一個訂單對應一個物流單。有些訂單無法通過一個包裹就能發貨，在信息反饋給客戶上就會有些瑕疵。
關於支付單，雖然基本所有平臺都會通過合併支付的方式簡化支付環節，但是不同的子訂單都是可以拿到不同的支付單號的，這樣就有利於售後和財務管理，對於跨境商品，還有報關的作用。
小結
拆單的系統比較複雜，要做的完全徹底，對大部分電商公司有很大的困難，這需要打通從訂單系統到WMS系統的許多環節，所以需要在產品設計上進行取捨，根據平臺的具體需求來確定拆單需求的優先級。