PMCAFF（www.pmcaff.com）：網際網路産品社群，是百度，騰訊，阿裡等産品經理的學習交流平台。定期出品深度産品觀察，互聯産品研究首選。
外包大師（www.waibaodashi.com）：要外包，找大師。PMCAFF旗下高品質網際網路外包解決方案提供商。聯系電話：010-57026742.
作者：PMCAFF會員 劉志遠（社群ID：Bouny_Yuan），跨境電商産品經理，專注于電商後端業務，主導多業務産品更新疊代，負責過從0到1的電商項目。
編者按：
閱讀全文大約需要15分鐘。本文為作者對平時工作的思考總結，包括商品中心的設計、訂單拆單的實作、促銷活動及優惠券的設計使用等，對相關從業者，有借鑒意義。歡迎留言交流讨論。
本文包括以下幾個部分：
- 電商背景系統概述
- 電商背景産品設計：商品中心
- 電商背景産品設計：訂單拆單
- 電商背景産品設計：促銷活動解析
- 電商背景産品設計：優惠券的設計和妙用
電商背景系統到底是怎麼回事兒
每年的“雙十二”“雙十一”人造購物節一來，電商群戰就好不熱鬧，馬雲卻預言純電商時代已去，新零售時代已至。作為一名電商産品經理，身處如此時代，亦會覺得不負青春。
做産品以來，主要做後端支撐産品方向，目前對各子產品系統都有所涉及。初次接觸時，在網上找了很多資料，發現關于産品的相關文章，大部分都是關于産品體驗、互動、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系統的許多環節，是以需要在産品設計上進行取舍，根據平台的具體需求來确定拆單需求的優先級。
本文由PMCAFF産品社群會員（www.pmcaff.com）原創釋出，未經許可，禁止轉載。