掌握電商後臺設計，這一篇足矣(轉載)

閱讀全文大約須要15分鐘。本文爲做者對平時工做的思考總結，包括商品中心的設計、訂單拆單的實現、促銷活動及優惠券的設計使用等，對相關從業者，有借鑑意義。歡迎留言交流討論。

本文包括如下幾個部分：

1. 電商後臺系統概述
2. 電商後臺產品設計：商品中心
3. 電商後臺產品設計：訂單拆單
4. 電商後臺產品設計：促銷活動解析
5. 電商後臺產品設計：優惠券的設計和妙用

1、電商後臺系統究竟是怎麼回事兒

每一年的「雙十二」「雙十一」人造購物節一來，電商羣戰就好不熱鬧，馬雲卻預言純電商時代已去，新零售時代已至。做爲一名電商產品經理，身處如此時代，亦會以爲不負青春。

作產品以來，主要作後端支撐產品方向，目前對各模塊系統都有所涉及。初次接觸時，在網上找了不少資料，發現關於產品的相關文章，大部分都是關於產品體驗、交互、APP等，說起後臺的文章基本淺嘗輒止，不多有文章來系統介紹後臺各模塊（商品、訂單、營銷、物流、支付、會員、評價、採購…）,就計劃寫一系列關於後臺各模塊的產品設計文章，但願可以幫助在產品路上成長的PM。

後臺系統，也不能叫作一個系統，不少公司將其拆分爲不少子系統，阿里更將其發展成了中臺事業羣（搜索事業部、共享業務平臺、數據技術）。後端一系列系統支撐着公司各類業務的進行和發展，前端展現、業務處理（訂單、優惠券）、庫存變更等進行時，後端各系統間互相調用接口進行數據更新。

因爲商業性質決定了電商業務支撐系統必須具有穩定性、可擴展、安全性強等特色，PM在設計產品架構時，應充分考慮到業務發展須要，儘可能將各模塊隔離，商品模塊建個商品中心，訂單模塊建個訂單中心等等。

只有在產品設計上有模塊化思想，具備前瞻性，技術在開發時纔會考慮業務隔離，當業務調整、功能新增時，開發可迅速進行，避免牽一髮而動全身的事情反覆發生。

針對通常電商業務，我簡單畫了一張產品模塊示意圖，基本一些中小型電商公司的產品架構大體如此。除了圖中所示，如今不少電商公司開始轉型社交電商，採用UGC模式或直播電商，在產品架構上會新增資訊系統，實現資訊與商品的高度融合，本文不過多涉及。

對電商公司來說，最核心最難作的三部分：商品、訂單、庫存。

商品與店鋪、營銷、評價等相關，訂單與會員、營銷、支付、庫存、物流等相關，庫存與訂單、採購、WMS、營銷等相關，系統之間業務邏輯和交互異常複雜，規則多樣。

• 商品中心：主要管理SKU(最小庫存單位)、SPU（標準化產品單元）、屬性（關鍵屬性、非關鍵屬性、銷售屬性）、類目品牌、價格等有關商品的數據；

• 訂單中心：管理訂單類型、訂單狀態，落下關於商品、優惠、用戶、收貨信息、支付信息等一系列的訂單實時數據，進行庫存更新、訂單下發等一系列動做；

• 支付中心：主要調用第三方支付平臺接口，記錄支付信息（對應訂單號、支付金額等）；

• 會員中心：主要管理用戶等級、用戶權益、積分、卡券等會員相關信息；調度中心主要將訂單信息轉化爲發貨通知單，調度倉庫和物流進行發貨；

• 客服中心：主要管理退貨退款、售後服務等操做，包括呼叫中心、在線客服等，與之對應的是工單系統，將客服任務進行隊列管理，分配給相應的客服；

• 營銷中心：主要管理活動相關，優惠券、滿減、專場活動、促銷專區等，營銷工具的開發對電商尤爲重要，營銷活動的濫用形成的用戶疲勞，怎樣推陳出新，給電商產品經理形成了很大挑戰；

• 運營中心：主要是對用戶端進行頁面配置（Banner、ICON、TAB）、價格管理等，通常會營銷中心併入運營，做爲其一部分；

• 評價中心：管理商品評價和用戶反饋，這並無想象的那麼簡單，涉及到一些敏感詞和敏感圖片的篩選，以及回覆內容管理；

• 店鋪管理：功能龐雜，至關於提供給B端用戶一個Saas管理後臺，提供管理商品、營銷、訂單一系列功能，主要針對一些有to B業務的電商開放平臺；

• 採購中心：管理SKU，當庫存預警時，及時生成採購單進行入庫，有供應商管理模塊，主要進行供應商管理評級，發展新供應商等功能；

• 財務管理：主要和訂單、採購系統相關，數據準確性要求較高；

• WMS系統（倉庫管理系統）：主要是入庫、出庫、盤點等模塊，WMS主要和調度中心進行數據交互，反饋出入庫狀態和庫存變更；

• 物流中心：主要進行運費模板、運費管理（前端訂單、真實物流成本）、物流狀態保存查詢（快遞100、菜鳥等關聯），若是是跨境電商，還涉及到和海關總署的對接，進行報關操做。

• 風控中心：主要利用大數據進行用戶信用建設、反欺詐，避免惡意評價、刷單退款等操做，構建安全的電商購物環境。

對電商後端支撐線各模塊的業務功能有初步認知以後，能夠看到的是，日常手機中的一個電商APP，背後是若干系統在支撐着，亦是許多技術和產品人員在辛苦付出。

以客戶下訂單爲例來介紹業務信息在各系統之間的流轉，涉及主要的信息交互以下圖所示。從用戶選擇商品、生成訂單到訂單出庫、物流配送、用戶簽收、退貨退款，信息在多系統中流轉更新數據。

從圖中能夠看出前臺的一小步，後臺的一大步。對於產品經理來說，理清各系統之間的業務邏輯，特別是在商品類型多樣（服務商品、實物商品、服務加實物商品等），業務複雜（預售、代銷、代發等）時，各系統模塊的隔離，設計時考慮擴展性很是必要。

2、如何設計實用的商品中心（前端顯示篇）

天天逛淘寶和京東的時候，映入眼簾的都是品類繁多的商品，可是當咱們選擇分類或者直接搜索的時候，按條件篩選時，系統卻每每能從千萬商品中提供心中想要的商品；在瀏覽商品時，商品主圖、詳情圖、規格等信息讓咱們感受比在超市拿着實物得到更多信息，電商系統究竟是怎麼作到這些的呢？

簡單粗暴地講，商品中心是用來管理核心的商品數據。對於使用的維度：從前端來說，是給商品展現、訂單、營銷活動提供商品數據支撐，從後端來說，商品中心給訂單發貨、倉庫管理、供應商管理、採購提供基礎數據支撐。

爲了更清晰地描述商品中心這項重量級工程，文章分爲兩部分從上述兩個維度來闡述，第一部分主要從後端的維度介紹商品中心。第二部分主要從商品前端顯示來講後臺設計的那些事兒。

1、 商品經常使用概念介紹

先介紹幾個基本概念：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時都須要選擇類目，進行綁定。

須要注意的是，類目樹的層次不能太深，通常三層或四層，若是太深，不論對於管理仍是技術性能來講，都是不利的。前臺類目與後臺類目可隨意搭配，設置前臺類目關聯時，對前臺類目樹最深層進行設置，可以讓其關聯後臺類目任一層，可一對1、一對多。前臺類目還能夠對應品牌。

2、商品基礎資料設計

在介紹商品經常使用概念時，也透露了不少在產品設計時關聯的信息。在添加SKU時，須要選擇品牌、填寫一些屬性，以及關於倉庫管理的基礎數據（長寬高、重量、供應商等）。

商品中心基礎資料結構圖主要以下，首先是品類管理，主要包括品牌管理(中英文名、可供品類、產地（跨境電商比較重要）)、屬性管理（針對類目添加相關屬性和屬性值）、類目管理（後端類目樹重中之重，肯定時要考慮全面，屬於基礎數據，後續更改比較麻煩。），大體產品框架如圖所示。

在添加SKU時，經過供應商去關聯採購，進而影響倉庫中SKU的庫存。

供應商在添加SKU時亦可不選擇，能夠在採購系統中添加關聯。

經過銷售屬性去關聯SPU與SKU，同一SPU在前臺顯示時能夠共用同一商品詳情，只是經過規格屬性映射到具體的SKU；針對商品的關鍵屬性和屬性值，能夠在商品搜索和篩選時用上，良好的屬性定義對於顧客決策樹的縮短有着相當重要的做用。

3、覆盤

商品中心後端屬於基礎數據，會被許多子系統調用，對於電商公司來講重中之重。商品中心提供接口數據進行倉庫管理、採購管理、庫存管理、訂單管理，可擴展的商品中心結構將給公司業務發展帶來很大益處。

文後擴展，不少電商公司業務定位都是B2B2C，爲了擴充SKU，增長用戶量，或者構建平臺體系，都會容許第三方來平臺管理商品，相似京東、有贊，這類平臺的商品結構更加複雜，SKU須要增長所屬商家，商品詳情、屬性值、庫存都須要相互獨立，在SKU、SPU緯度上增長一個商家緯度。這裏不作過多擴展，感興趣的朋友能夠深刻思考。

3、如何設計實用的商品中心  （後臺設計篇）

用戶日常購物接觸到最多的就是商品顯示頁，商品列表、商品詳情頁的基礎信息都是從商品中心獲取。

目前對於商品設計有着成熟的產品方案，電商網站的商品產品結構大同小異，淘寶上的商品以SPU形態顯示，京東上以SKU形態顯示，兩種處理方式各有優劣勢（表達可能不太準確，但認真研究過二者商品結構應該理解我說的不一樣點，下文解釋）。

其實我更傾向於淘寶的商品結構，可以支持更加靈活的商品方案。

京東與淘寶的商品詳情頁

商品信息主要由類目、標題、品牌、商品屬性、規格（京東定義爲銷售屬性）、價格、庫存、SKU信息（毛重、長寬高等）、商品圖、商品詳情描述、物流信息等組成。至於常常看到的服務標籤（白條、極速退款）、商品標籤（熱銷）、活動標籤（滿減、優惠券）、價格標籤（拼團價、活動價）、同類商品等都是在商品信息上的包裝層，不在本文的闡述範圍。

1、商品類目、商品基本信息

商品類目分爲兩層，基礎數據類目層、前臺展現類目層，在添加和管理商品時，都是在基礎數據類目層對商品進行管理（以下圖）。商品屬性、銷售屬性及品牌等不少數據都是在基礎類目上進行管理，因此類目管理屬於較爲核心的工做，必定要從長遠角度考慮。

在添加商品時，需選擇對應的類目。前臺類目在展現時，有兩種處理方式：

• 前臺類目對應後臺類目，可一對1、一對多、多對多，自由組合，動態調整。如今大部分自營電商都是用的這種類型。

• 前臺類目直接對應商品，適合商品較少的小商家，主要是一些電商平臺提供給平臺上商家的類目服務，添加商品時直接選擇前臺展現的類目。 

另外，類目通常是分爲三層，類目樹不要太深，不然將影響產品效率。 

JD商品類目

設置商品信息、副標題（通常介紹產品賣點、促銷），選擇商品對應的品牌。

在品牌管理中，有兩種方案：1.品牌統一管理，小公司商品豐富度較少時的方案。2.品牌關聯類目，商品豐富度高的選擇。

基本信息編輯 

2、商品屬性

商品屬性包括屬性名、屬性值，通常都是掛在具體類目子葉下，設置必填和非必填。在設置屬性值時，須保留必定的擴展性，部分容許自定義屬性。商品屬性管理要求強大的類目運營能力，在中小型電商平臺通常會提供基礎屬性值，再開放自定義屬性編輯，讓用戶來完善屬性庫數據。

商品搜索能力，除了標題、類目，很大部分依賴於商品屬性，條件篩選的基礎數據也是商品屬性和規格屬性。完善商品屬性對於良好用戶體驗相當重要。

淘寶的商品屬性（男裝>風衣）

3、規格、價格、庫存、SKU信息

在購買商品時，咱們會常常選擇規格（銷售屬性），主要包括顏色、尺寸，爲了支持多樣化的用戶需求，選擇以後能夠編輯規格。規格一對一肯定以後，可單獨設置價格、庫存、商家SKU，淘寶上亦可添加條形碼（69碼）。

也能夠設置統一價、統一庫存。填寫商家SKU主要是爲了方便對應到具體的實物，上文亦講過，倉庫和採購管理的都是具體的SKU。

仔細觀察會發現，京東的商品標題是加上具體的規格，在選擇規格時會跳轉SKU，對於落單數據有效率提高，可是對於頁面效率和體驗是不如淘寶的SPU結構的。如今大部分電商都採用的是淘寶的SPU結構，亦是優質選擇。

JD規格、價格、庫存、SKU設置頁面

在淘寶上選擇具體的規格後，會發現商品縮略圖會發生變化，這就須要在管理商品時，針對某規格單獨上傳圖片。這裏有個設計很巧妙的地方，只是不一樣顏色須要上傳對應的商品縮略圖，而尺碼不須要。

淘寶不一樣顏色上傳具體的縮略圖，京東可上傳多圖

針對商品設置平臺價和市場價，主要是爲了商品在列表展現商品、未選擇具體規格時展現，至關於商品的均價。毛重、長寬高等數據主要是爲了物流而設置的，自建倉庫的自營電商通常在SKU數據層就會錄入這些數據，直接調用。

貨號即商品編碼，在商城購物時會掃描的條形碼就是貨號。貨號不等同於SKU編碼，同一商品編碼的商品多是不一樣SKU，有着不一樣的規格，因此不能直接拿貨號來管理SKU。

JD商品信息填寫

4、商品圖、商品詳情描述、物流信息

除了不一樣規格對應的商品縮略圖，商品圖還包括商品主圖，通常要求圖片質量較高，包括總體圖和細節圖。商品主圖是吸引顧客眼球的必要利器，不管是列表頁，仍是活動頁，顧客除了關注價格，主要就是商品主圖，運營上架時需對商品主圖較爲慎重。

商品詳情頁如今通常會區分電腦版和手機版，因爲二者的使用場景和設備不一樣，側重點也不相同。爲了更好的展現產品特色，可提供不一樣的產品詳情模板，亦可支持不一樣的富文本編輯。

商品詳情描述

選擇運費服務時，要選擇對應的物流模板（包郵、按重量、按件數等），在訂單處理是按照具體的物流模板計算運費。運費模板計算較爲多樣複雜，下篇文章詳細描述講解物流運費相關的細節。

商品物流選擇

5、其餘商品信息

主要包括售後服務（發票、保修服務、退換貨）、包裝清單等相關說明。

6、上下架管理

設置完商品基本信息以後，設置上下架時間，亦可直接上架發佈。和商品相關的活動，一旦商品下架，活動將失效，沒法購買。搜索、篩選的商品範圍都是在上架的商品範圍進行。

上下架設置

在商品管理層面，平臺電商提供給平臺商戶的商品服務與自營電商本身的商品服務有着很大不一樣。最大區別在於自營電商比平臺電商多SKU管理，庫存和屬性都是基於SKU進行管理，在添加商品時，若是還要從新填寫，就會形成數據冗餘。因此通常會共用數據。

4、電商後臺產品設計：優惠券的設計和妙用

優惠券是一種常見的促銷方式，在規定的週期內購買對應商品類型和額度的商品時，結算時知足必定條件會減免必定金額。經過發放優惠券，引導用戶購買相應的商品，在下單的時候抵扣必定的費用，達到促銷、提升客單價的目標。

優惠券不論在線上仍是線下，適用範圍都比較普遍。例如滴滴發的專車券、外賣平臺發的外賣券、京東淘寶的優惠券等。

1、優惠券的類型和應用場景

優惠券有多種分類方式，按照使用門檻、使用範圍、發放主體等有不一樣的分類。

1.1 按照使用門檻分爲現金券、滿減券、折扣券。

現金券：不限制訂單金額，能夠直接使用。

滿減券：訂單金額須要知足必定的最低額度纔可以使用，例如：滿100減10元優惠券。

1.2 按照適用範圍分爲：單品券、品類券、品牌券。

單品券：購買優惠券指定商品時可以使用，這種優惠券通常只針對少許特殊商品可使用。

品類券：購買優惠券指定類別的商品便可使用，除個別特殊商品。

品牌券：購買優惠券指定品牌的商品時可以使用，除個別特殊商品。

通常按照品牌或者品類設置優惠券範圍是比較常見的方式。 

1.3 按照發放的主體分爲平臺優惠券和店鋪優惠券 

平臺優惠券：優惠由平臺承擔，好比平臺活動優惠券、平臺註冊的新人優惠券、平臺積分兌換的優惠券。

店鋪優惠券：在平臺上的店鋪本身發放的優惠券，好比淘寶上的店鋪優惠券、京東的店鋪優惠券。

平臺優惠券的金額由平臺承擔，在店鋪使用時優惠金額由平臺返給店鋪；店鋪優惠券的成本由店鋪本身承擔。

2、優惠券的設計規則

從優惠券的生命週期，來設計優惠券是最恰當的。

優惠券週期 

2.1 生成優惠券

在生成優惠券時，主要是從優惠券信息和推廣信息兩方面來考慮優惠券的設計。

2.1.1 優惠券信息

• 優惠券名稱
• 類型：現金券、滿減券、折扣券
• 面值：例如10元。
• 使用條件：滿XX元可用
• 使用平臺：客戶端、H5商城、主站、各分銷渠道
• 有效期時間：絕對時間（時間段）、相對時間（領取之往後多少天有效）
• 發行量：優惠券張數（設置限額）
• 使用範圍：平臺券（全平臺通用）、店鋪券（僅在某店鋪可用）
• 商品範圍：全品類、限制品類、限制商品 

2.1.2   推廣信息

• 發放方式：可發放可領取、僅可發放(只能由平臺發放給用戶)、僅可領取（只能用戶本身領取或兌換）
• 推廣範圍：免費領取、積分兌換
• 優惠券是否公開：設置公開後，在領券專區、商品詳情頁、購物車都默認展現
• 限領：每人僅限一張、每人天天限領一張
• 券領取時間：設置領取時間段（過時）
• 在優惠券生成以後，將優惠券顯示在優惠券列表中。 

2.2 發送優惠券

優惠券有主動領取和被動領取兩種方式。

主動領取：

用戶在店鋪首頁或者平臺上看到優惠券，主動進行領取；用戶在線下看到宣傳推廣；朋友圈優惠券分享連接等等。

這種發放方式須要必定的運營成本，須要打動用戶，產生興趣進行主動領取，這種方式須要作好防做弊機制，真正獲取到的用戶價值較高。

被動領取：

系統主動給用戶發送相應的優惠券，可是這種大面積分發的方式，用戶精準度低，轉化率較低，只能不多促進客單量。

系統發放優惠券場景有不少種：1.用戶註冊；2.大促活動；3.還有客服發券，主要是售後補償（平臺責任致使售後，發券補償客戶），或者好評返現。

除了以上的方式，還有許多平臺電商的一項業務：大客戶團購，主要是給一些單位提供的福利卡，例如京東卡。能夠經過優惠券（平臺幣）的形式實現，生成相應的卡密（或兌換碼），製做實物卡售賣給一些公司發福利、送禮。用戶輸入卡密兌換以後，兌換成平臺的交易幣（至關於給購物卡充值），能夠用來抵扣訂單金額。

發送優惠券雖然在前端頁面只是簡單的一個交互，可是後端有大量的邏輯須要處理。

校驗用戶登陸狀態 → 優惠券信息讀取（是否在有效期、是否可發放、剩餘數量） → 優惠券綁定用戶

2.3 優惠券覈銷

在用戶下單時，確定是須要系統從其帳戶中的優惠券選擇合適的優惠券推薦給其使用的。我思考的推薦算法應該分三步：

• 從用戶優惠券列表中選擇出當前訂單可用的優惠券（包括通用券和相應產品優惠券），主要是從有效期、商品範圍等條件判斷

• 如有多種可用優惠券，可是金額不一樣，默認選擇可抵扣最高的優惠券。

• 若是金額相同，先匹配同類優惠券的優惠券，但當優惠券的額度（現金券）大於支付額度彈出提醒框，確認是否使用。

注：在用戶的優惠券列表中，優惠券是否失效也是實時拉取的（失效過長應清除此優惠券），下單時優惠券選擇應僅顯示用戶可用優惠券。

2.4 優惠券統計

主要統計優惠券的發送張數、使用張數。深度數據挖掘能夠統計優惠券對應的客單價、復購率等等。

3、優惠券的前端展現

優惠券的前端露出窗口主要有五處：用戶優惠券列表、訂單提交頁、購物車、商品詳情頁、領券中心（或優惠券分享連接）。

前端展現的難點在於商品詳情頁和購物車中展現可用優惠券。須要高效率的算法來計算匹配商品對應的優惠券，主要有兩點好處：1.優惠券來促進用戶消費；2.在用戶消費時幫助用戶省錢。告知用戶有優惠能夠享受，避免用戶下單以後看到相關優惠沒有享受到產生不平衡心理。

優惠券（京東）的前端透出

4、優惠券在訂單中的處理

下單時優惠券的匹配在前面已經敘述過，主要是分爲三步，詳見2.3優惠券的核銷。本節重點講解優惠券的逆向流程。

在訂單完成售後（退款或退貨）時，優惠券應有必定的返還機制。

• 統一設置成不可返還，用了以後就不退。
• 訂單中所有退款時，優惠券所有退還。
• 訂單中部分退款時，普通優惠券不返還，現金券按金額比例退還。

優惠券有着一套很成熟的產品設計方案，介紹以後，再提一個目前絕大部門產品難以解決的問題：基於平常優惠券的使用狀況，運營人員如何平衡發放優惠券所帶來的成本增加，商品銷量增加和單品毛利降低之間的矛盾？在申請促銷活動經費時，怎樣的數據更具說服力？

5、電商後臺產品設計：促銷活動解析

促銷是最多見的電商運營手段，每到重要節日，相似雙11、61八、情人節等等，商家在線上或是線下都會展開瘋狂的促銷大戰，經過各樣的形式吸引消費者。做爲電商的從業者，應該對各類促銷手段有所瞭解。這部份內容將從產品設計的角度來介紹各類促銷手段。

1、促銷綜述

促銷就是營銷者向消費者傳遞有關產品的各類信息，吸引或促進消費者購買其產品，以達到擴大銷售量的目的。促銷對提升客單量、客單價、復購率甚至註冊量都有必定的好處。不少電商平臺或店鋪在起步階段會經過大量的促銷活動來吸引消費者，獲取流量。

促銷有利有弊，對平臺來講不必定是好事，頻繁的促銷容易給顧客產生疲勞，透支將來收入，甚至會下降品牌定位。

2、促銷的各類類型

促銷有多種形式，目前電商系統可以支持的促銷形式我大體總結了一下，大約有7種：滿減促銷、單品促銷、套裝促銷、贈品促銷、滿贈促銷、多買優惠促銷、定金促銷。

這7種促銷形式幾乎囊括了各電商平臺全部的促銷方案，特別提一下「定金促銷」的形式在2016年雙十一開始普遍應用，對電商供應鏈的備貨和物流控制大有益處。

• 滿減促銷： 購物者只要購買相應商品到規訂價格便可獲得必定的減價優惠。主要有兩種形式：階梯滿減、每滿減。階梯滿減，例：滿100減十、滿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、促銷的後臺設計

剛剛介紹到的幾種促銷方式在設計上都大同小異，主要分爲活動條件、主商品信息、贈品信息（有些無贈品）這三部分。

3.1 活動條件

主要包括促銷活動名稱、促銷時間、限購數量、促銷範圍（全網、APP /微信商城）、會員級別（全員  or 新註冊用戶 or 某等級會員）、活動備註、活動規則。

活動規則即最核心的設置，例如：滿800元減60，3件150元。

滿減規則設置（來自京東） 

3.2 主商品信息

選擇參加活動的商品，可按SPU、分類、品牌等來選擇參加促銷的商品。

除此以外，還要判斷當前所選商品是否參與其餘促銷活動，與此活動由衝突。例如A商品參加4月的活動，滿400元減20元；再次設置該商品參加滿400減50的活動，就應與該商品已參加活動衝突，不可設置。

設置主商品（來自京東）

3.3 贈品信息

選擇參加活動的贈品，贈品通常有數量限制。有兩種規則，贈品全送，或在多贈品中選擇幾件。爲減小系統複雜度，減小用戶理解難度，建議採用贈品全送的規則。

另外對於滿贈促銷的形式，若要設置分級贈品（滿300元送自拍杆，滿500送充電寶，滿1000送高端耳機），就須要對贈品分開進行設置。

設置贈品（來自京東）

對於後臺產品來說，重點在於設置規則以後在商品詳情頁、購物車的促銷信息展現以及訂單頁面的促銷活動判斷邏輯。

4、前端展現

在商品詳情頁，要去判斷商品對應的全部促銷活動，例如加價購、滿贈、贈品等促銷活動。

商品詳情頁的促銷信息（來自京東）

在購物車，除了展現促銷信息（滿贈、滿減、套裝、換購）的做用，還可讓用戶在多優惠並存只能選其一的狀況下，能夠選擇修改促銷方案。（感受京東已經把購物車的功能作到極致了）

購物車的促銷信息（來自京東）

在訂單詳情頁，判斷當前所選商品的促銷信息（促銷價、贈品、換購商品等），將全部相關商品記入訂單信息中，再算出促銷價格。

訂單頁的促銷信息（來自京東）

企業利用各類促銷的方法和手段，使消費者瞭解和注意企業的產品、激發消費者的購買慾望，並促使其最終購買。每一年源源不斷的促銷已經形成消費者對促銷麻木，只有在促銷與正常銷售之間尋找合適的平衡點，纔是企業的生存之道。

6、電商後臺產品設計：訂單拆單

最近在作拆單的需求，細思極恐，思考越深刻，就會發現裏面涉及的東西愈來愈多，要想作好訂單拆單的功能，仍是至關有難度，所以總結了一下拆單功能細節，分享出來。

拆單也有兩個層次，第一次是在提交訂單後支付以前拆單，此次是拆分的訂單，一次是在下單以後，發貨以前，去拆分發貨單（SKU層面）。

兩次拆單的原則不一樣，第一次拆單是爲了區分平臺商家、方便財務結算，第二次拆單是爲了按照最後的發貨包裹進行拆單，如不一樣倉庫、不一樣運輸要求的SKU、包裹重量體積限制等因素（第二次拆單的有些步驟能夠放在第一步）

須要注意的是，如果跨境商品平臺，則須要在支付前完成全部拆單步驟，由於報關須要三單對碰，訂單、支付單、運單統一。

1、 爲何要拆單

拆單，顧名思義就是客戶在下單以後，爲了發貨和結算方便，須要對訂單進行拆分。

影響拆單的因素主要有如下幾點：

• 店鋪商家。因爲商品歸屬權不一樣，涉及到財務結算和發貨的問題，店鋪商家不一樣，須要拆分訂單。例如京東自營和平臺商家的商品在下單時會拆分紅不一樣的子訂單，售後入口不一樣。或者不一樣淘寶店同時下單會按照店鋪進行拆單。

• 倉庫。因爲發貨倉庫不一樣，按照商品歸屬的倉庫進行拆單，如有多倉有貨，還應按照地域時效選擇倉庫進行拆單。

• 品類。因爲商品屬性和價值得不一樣，一樣會產生拆單需求。例如易碎品須要特殊包裝，超大物品（兒童座椅、輪胎）須要單獨包裝。甚至有些品類不一樣的商品不能放在一塊兒，都須要來定義拆單規則。

• 物流因素。不一樣物流公司對單個包裹的重量或體積都有特殊要求，須要根據sku的毛重和體積計算包裹總重量和體積，超出物流公司限制的也須要拆單。

• 商品價值。這塊的拆單主要是跨境海淘商品，國家政策規定：跨境電子商務零售進口商品的單次交易限值爲人民幣2000元，我的年度交易限值爲人民幣2萬元。當單次購買超過2000元（單倉）以後，就須要對訂單拆單。（總不能告訴用戶少買點，不要超過兩千吧！）

2、拆單流程

根據拆單的一些影響因素，須要對訂單進行拆分。因爲跨境電商和國內電商的區別點：

• 跨境電商通常是單品單倉，同一個SKU只在一個倉庫有，而國內電商通常有多個區域倉，從時效最高的倉庫發貨；

• 跨境電商須要報關，必須三單統一，因此拆單隻能發生在下單後、支付前，而國內電商除了平臺商家不一樣須要在下單時就拆單，其餘的拆單步驟可在下單以後再拆發貨單；

• 報關限額，只有跨境電商須要考慮。

下圖簡單解析一下拆單的流程：

拆單流程

3、拆單以後的前端顯示

在提交訂單以後、支付以前的拆單訂單，須要即時顯示給用戶，若用戶中斷支付，再回到支付環節，就須要分開支付。用戶就能知道，是不一樣的包裹發過來的，分屬不一樣的子訂單。

訂單拆分（淘寶）

在支付以後，系統根據一些影響因素進行拆單，同一個子訂單可能會對應多個物流單，在訂單顯示頁面查看物流時，須要展現多個物流信息。可是如今多個平臺只能一個訂單對應一個物流單。有些訂單沒法經過一個包裹就能發貨，在信息反饋給客戶上就會有些瑕疵。

關於支付單，雖然基本全部平臺都會經過合併支付的方式簡化支付環節，可是不一樣的子訂單都是能夠拿到不一樣的支付單號的，這樣就有利於售後和財務管理，對於跨境商品，還有報關的做用。

小結

拆單的系統比較複雜，要作的徹底完全，對大部分電商公司有很大的困難，這須要打通從訂單系統到WMS系統的許多環節，因此須要在產品設計上進行取捨，根據平臺的具體需求來肯定拆單需求的優先級。

做者： 劉志遠，跨境電商產品經理，
公衆號：碎碎戀產品（ID：WebPMgrow）

 

轉載自：http://www.yixieshi.com/78740.html