A. B2B電商平台怎麼防止用戶線下交易
客服全包，不讓他們交流，物流全接手不讓他們發貨。否則 不可能避免的，但是B2B最大的是信譽度，有信譽度積攢客戶自然喜歡通過信得過的擔保機構交易。
B. 做電商時，怎樣避免線上網路銷售與線下實體店銷售產生的沖突
俗話說：先治其內，後治其外，傳統品牌電商應先從內部矛盾整合開始入手，然後再以自身優勢改變市場格局，首先如果有效避免企業線上線下產品之間的銷售沖突，再來如何有效抑制線上泛數搜濫的假品對線下正品的的銷售沖突，而這兩方面的競爭沖突在傳統品牌電商經營問題中顯得尤為凸顯。
產品差異化
由於企業自身線上與線下的運營成本差異，和線上價位低於實體店價位的網路營銷潛規則，傳統品牌電商在官網推出的產品折扣都會大大低於線下同類產品，線上產品銷售一路走高的同時，也帶來線下顧客流失經營困難等弊端，而線上價位提升又導致線上產品失去原有的競爭優勢，逐漸埋沒在前仆後繼的競爭對手洪流中，在這樣看似矛盾且沖突的格局內，傳統品牌電商們不要受限於原有的營銷模式，應該根據市場動向、客戶需求提供差異化的產品服務，使線上與線下的產品能夠和諧共存，例如專門在線上推出幾款線新產品，避開與線下產品的直接沖突，亦或在線下推出幾款新品，但只在線上宣傳不在線上兜售，差異化的產品區分可以合理有效的避免企業自身矛盾沖突，更可以幫助企業細分市場，拓寬銷售渠道。
答州獨一無二的產品條形代碼
對於很多傳統品牌電商在進軍網路市場之前的調研中，就發現該企業的產品其實早已在網路上紅紅火火的銷售了，但線上良莠不齊的銷售環境，在影響其品牌線上銷售的同時，也影響著傳統品牌電商的線下銷售，在這場沒有硝煙的戰場上，不良電商成了最大的贏家，傳統品牌電商該如何有效抑制線上泛濫的假品對自身線上線下產品的的銷售沖突呢?其實傳統品牌電薯舉歷商不妨借鑒下電子產品的防偽條形代碼，獨一無二的產品條形代碼不僅便於消費者識別真偽，而且可以通過條形代碼建立追蹤庫監管銷售渠道，避免批發商打亂市場價格，降低惡性競爭，有效避免了線上其他渠道銷售商對傳統品牌電商線上和線下產品銷售的沖突。
C. 拼多多線下發貨怎麼操作
交易系統一直是電商的核心模塊，幾乎所有業務都圍繞其展開，看似簡單的下單流程，實際涉及的模塊、內容也很龐雜。這次就把訂單下單的整體鏈路抽象出來，與大家分享。
說到下單，對於用戶而言就是選擇商品-下單-支付-商品運輸-確認收貨這樣簡單的主流程，保證了即使是網購新手也可以很快上手。
但對於電商交易系統來說，訂單的生命周期遠不止上述流程那般簡單。見下圖，對於電商平台來說一個訂單的生命周期涉及眾多系統，下圖也僅僅是列出了各大系統間的交互流轉，且僅涉及正向流程，逆向流程會更加復雜。
01 關於訂單 1. 什麼是訂單
首先來聊一下什麼是訂單？
訂單可以簡單理解為買家與賣家簽訂的一份具備法律效應的合約。一般情況下，合同的訂立有要約和承諾兩個程序。賣家展示商品及其價值的行為，便屬於要約；購買者確認購買商品並提交訂單的行為屬於承諾，訂單提交後，合同即成立並生效。所以大家可以簡單理解為訂單其實就是一份客戶與商家簽訂的合同，具有法律效益。
2. 訂單的生成與流轉
參考上文，如果從前端的體驗來看，訂單的生成就是加車後結算或立即購買，進入結算界面確認訂單各項信息無誤，提交後即生成訂單。
但我們從訂單在內部系統生成的流程來看，在生成訂單前需要內部各大系統進行配合與支撐，包括風控系統、商品系統、營銷系統、會員系統、庫存系統等。上述系統流程也僅是對交易主流程的梳理，涉及數據在各系統中如何交互並沒有列出，可見整個電商交易系統是何其復雜。
02 風控系統——風險訂單檢測、攔截
說到風控系統，最容易聯想到的是銀行借貸、P2P等金融領域的風險控制。無論是金融行業還是電商行業，風控的本質都是保證平台利益不受損失。
電商訂單風控主要側重於兩防——防刷單；防羊毛黨。
1. 防刷單
商家刷單影響平台流量分配，間接影響商家管理體系的構建；商家刷單體系大概歷經了兩個時期：野蠻生長，集中刷單；平台監管，精細化刷單。
電子商務起步初期，唯銷量論英雄，」培養」了商家們的刷單習慣，加上平台監管缺失，一個人一台電腦就能刷上一天，那時候管刷單不叫刷單，叫刷鑽/刷皇冠，主要刷的是店鋪等級。
但「好日子」很快到頭了，隨著平台的流量分配由店鋪變為單品，加上管理規則、風控體系不斷完善，商戶們的刷單成本也越來越高，刷單的工作也要交給」專業」人士來，所謂精細化刷單就是模擬用戶真實下單場景，騙過系統，讓它認為就是普通用戶在下單。精細到怎麼搜到商品，需要瀏覽多少個商品，每個頁面停留多長時間，是靜默下單還是咨詢下單都有嚴格的規范。
業內早就形成了認知：沒有一勞永逸的防刷單策略，最好的方法就是不斷提高刷單的成本。
2. 防羊毛黨
羊毛黨薅羊毛的做法直接影響平台/商家收益，損害正常用戶購物體驗。說到羊毛黨離不開另外一個詞：黑產。單兵作戰的羊毛黨不可怕，可怕的是成體系作戰的黑產團隊，他們往往分工明確，主攻電商平台業務(規則)漏洞和系統BUG，薅上一天夠吃一年。
上述流程圖，在用戶提交下單申請後會經過風控系統的風險檢測，但此時的風險檢測較為初級，主要針對確定性事件如用戶黑名單、下單環境等事件進行下單攔截。
因為下單時風控系統能夠拿到的欄位信息較少，缺乏大量數據支撐，難以准確判斷用戶下單行為，且下單流程屬於高並發場景，系統反饋需要在毫秒級完成，進行復雜的風控檢測嚴重拖慢系統進程，因此更復雜的風控會在用戶下單成功後非同步進行。
進行非同步風控檢測後，系統會對命中風控策略的訂單進行關閉(取消訂單)，當然風控並不只是攔截訂單，在復雜的場景下還需要有報警機制，人工介入。
拼多多在19年1月就因為優惠券事件被黑產薅了數千萬羊毛，就是因為缺乏有效的風控機制。
03 商品系統——商品信息的獲取
訂單生成時需要通過商品系統獲取商品基礎信息、數量、價格。同時部分電商平台還會記錄交易快照，同樣是需要商品系統支持。
1. 關於交易快照
什麼是訂單商品快照(交易快照)？看字面意思，很容易讓人理解為用戶下單時針對訂單商品詳情的一個快照(截圖)，其實嚴格來講，商品快照是一個靜態數據合集，記錄了用戶下單時的商品信息，包含：商品圖片、標題、描述、服務等要素。
淘寶是國內較早啟用交易快照的電商平台，為了解決商家與用戶交易糾紛時難以追溯用戶下單時的商品情況，淘寶的產品經理引入了交易快照的概念，即用戶的每一次下單，都會對下單時的商品信息做一個記錄，快照作為買賣雙方發生交易的憑證，任何交易糾紛或者投訴都將以快照為准。
大多數電商平台做交易快照的初衷是為了解決交易糾紛，此外，交易快照還運用於法律訴訟場景，法院進行相關訴訟的裁定時，是認可交易快照作為證據的，但需要證明快照就是用戶下單時的商品快照，無法被篡改。
2. 交易快照的記錄
交易快照的記錄：目前主要有兩種記錄方式，如圖：
第一種：用戶每下一單都對訂單商品信息進行一次信息記錄，此操作主要由交易系統完成，弊端也很明顯在下單高峰期，會對系統性能產生影響，且數據存儲量大。該方案主要適用於低頻交易場景，如大宗商品交易等。
第二種方法：由商品系統(基礎數據)對每一次商品信息變更做備份，之後根據用戶下單時間映射商品快照。此方案適用於高頻交易場景，且對高並發下交易系統性能不會產生太大影響。
關於庫存的定義，網路上給出的解釋是：「倉庫中實際儲存的貨物」。但這里我特別提到了虛擬庫存，為了與實際倉庫庫存做區分。
目前商家在電商平台維護的庫存都叫虛擬庫存，虛擬庫存可以簡單理解為不存在的庫存，它並不跟實際倉庫庫存關聯，可以認為虛擬庫存就是商家指定的平台的一個渠道可售庫存。如果商家有一批商品正在生產中、采購中、運輸中或正在入庫，亦或者商家覺得能承擔住超賣的風險，有辦法從其他地方調貨，設置虛擬庫存時就可能大於實際倉庫庫存。
2. 庫存預占與庫存校驗
說到庫存預占，在電商發展過程中有個很經典的問題：是下單減庫存還是支付減庫存？
現在想一想，應該在什麼時候減庫存？
線下實體商超是怎樣的？
這里不考慮實體商超倉庫庫存的情況，只考慮貨架庫存。什麼時候減庫存呢？或者說什麼時候這個庫存會被用戶占據呢，應該是在用戶從貨架拿走商品，放入購物車的時候。
那麼線上購物流程也按照加入購物車即減庫存呢？顯然是不行的，線上購物車的」加車」操作幾乎是0成本，決定它更像是作為一個商品收藏池或備忘錄，用戶把備選的商品放入購物車後再進行二次選品，加車商品數遠大於用戶實際購買數，故在購物車即扣減庫存效率是低下的。
如果是在下單的時候扣減庫存呢？
相當於用戶下單，系統已經把相應庫存分配給此用戶，用戶支付成功後即可發貨，這是正常的流程。但會出現下單不支付惡意預占庫存的情況，導致商家商品未能及時售出，銷售受損。
如果更進一步，支付成功時再扣減庫存呢？
此方法一定程度提高了惡意下單的門檻。但問題也產生了，當商品供不應求，出現大量用戶搶購的情況，此時大部分用戶都能下單成功，但在支付環節僅有少部分用戶可完成支付，對於未成功支付的用戶來說，體驗太差。
上述兩種有效方案，無論是下單減庫存還是支付成功減庫存，都不是完美的解決方案。那麼應該選擇哪一種呢？蘇傑在《淘寶十年產品事》中回憶當時淘寶的產品經理也是糾結於選擇哪種方案，最後折中，提供兩種方案，商家自行選擇。
在我看來，對於平台型電商，下單減庫存優於支付成功減庫存。
從體驗角度上看：用戶(購物)體驗是平台型電商的核心競爭力。下單減庫存影響商家銷售，支付減庫存影響用戶體驗，所以從購物體驗角度做取捨，下單減庫存對用戶較為友好。
從系統層面上看，支付減庫存是要比下單減庫存復雜的。支付減庫存涉及 訂單系統-庫存系統-支付系統的交互，而下單減庫存僅由訂單系統-庫存系統完成即可。支付減庫存在高並發的場景下容易出現超賣現象。
下單減庫存存在的問題：惡意下單不支付。可以通過系統規則來解決：如單用戶限購，超時未支付自動取消訂單(庫存返還)
1）為什麼要進行訂單拆單？
核心有兩點：便於結算；便於發貨。
主要是圍繞上述兩點核心進行，常見拆單規則有：
按商家拆單；不同商家間需要拆單
按倉庫拆單；不同倉庫間需要拆單
按商品重量、體積拆單；快遞公司對包裹最大體積/重量有要求
按商品價值拆單；貴重、易損商品單獨拆分等
按發貨方式拆單；如實物商品與虛擬商品混合下單，發貨方式不同
按配送時效拆單；如正常商品與預售商品混合下單，發貨時效不同
具體拆單規則根據不同平台不同業務場景而異，按照便於結算、便於發貨兩大方向去做訂單拆分便能滿足大部分業務需求。
2）什麼時候拆單
先來看下京東、淘寶分別在什麼時候進行拆單
京東：用戶訂單支付成功後進行拆單
淘寶：用戶提交訂單，支付前即對訂單進行拆單
那麼什麼時候拆單有何講究？因為業務形態不同，淘寶以商家為主，京東以自營為主。故淘寶拆單邏輯較為簡單，按商家拆單即可滿足絕大部分拆單訴求；而京東因涉及自營倉+商家，除了商家間的拆單，還涉及倉間/倉內拆單，拆單邏輯更為復雜，將拆單邏輯後置到支付成功後，能夠減少無效拆單(未支付訂單不拆單)，提升高並發時系統性能。
所以在什麼時候進行訂單拆分，遵循兩大原則：
佔用資源最小原則（特別要考慮高並發場景）；
訂單推送前需要完成拆單（推送至商家/倉庫前都需要完成拆單）
早期的淘寶，商品就一個價格，即售賣價，對於商家、用戶來說都足夠簡單，所見即所得。但這種平衡很快被一個功能打破——購物車。購物車的上線標志著淘寶進入營銷時代，後來我們熟知的滿減、滿折、滿贈、M元N件等促銷玩法都要仰仗購物車。那麼訂單優惠是怎麼計算的呢？
1）遞進式門檻計算
既然促銷活動有了，有促銷就會有優惠，這些優惠怎麼算呢，讓我們記住這個詞【遞進式門檻計算】，就是它，讓很多用戶抓狂。
提問：購買兩件商品A和B，A單品優惠價100元；B單品優惠價200元，參加店鋪促銷滿300減50，店鋪優惠券滿280減40；同時還參加跨店鋪滿減，每滿290減50。問：在遞進式門檻計算規則下，到手價是多少?
按照【遞進式門檻計算】最終到手是：250，這就是一頓操作猛如虎，一看優惠兩塊五。
遞進式優惠計算核心規則即：根據上一層級優惠扣減後的金額來判斷是否滿足下一層級的優惠門檻。所以在【遞進式門檻計算】時期，經常出現用戶看到某一商品參加了多種活動、領取了各種優惠券，最終結算時僅可以使用一種優惠而大罵商家、平台虛假營銷的情況。
2）平行式門檻計算
前文我們提到：購物體驗是平台型電商的核心競爭力，在此背景下，淘寶、京東於18年、19年相繼用【平行式門檻計算】替代【遞進式門檻計算】。
採用平行式門檻計算規則後，優惠計算清晰明了，以前要糾結各級優惠的觸發門檻，現在湊單只需要盯著各類優惠里門檻最高那個就行，如圖：
此規則的上線對於平台用戶、商家來說無疑是利好的，用戶能夠一目瞭然感知優惠力度，商家也能清楚掌握讓利程度。
但這裡面存在一個大坑，即平台在切換優惠計算規則時歷史產生的促銷活動、優惠券怎麼辦？不處理，商家就要大出血，如圖。
淘寶、京東面對此坑時也是毅然在上線前將平台所有滿減、滿折、滿贈等促銷活動及優惠券作廢。
3. 訂單狀態的定義
我們常見的訂單狀態，如下：待付款-待發貨-已發貨-已完成-已評價(已評價狀態有時也不作為主狀態存在)
已關閉、異常
作為電商行業從業者需要經常跟訂單打交道，每個人都能隨口說出訂單狀態包含哪些，甚至連會網購的大媽都能說出個123。訂單狀態算是一套很成熟的體系，對於缺少電商行業經驗的產品來說，在定義訂單狀態時直接照搬這一套，大概率都不會出錯。
但在這里我還是想聊一下對於訂單狀態的思考：
首先，說一下狀態，這個詞對於產品經理來說一定不陌生，日常工作中各種單據、邏輯判斷都會用到。什麼是狀態？我的理解:事物處於某個穩定的情態，在無外力的影響下會一直處於一個穩定態，這個穩定態就可以稱為狀態。
那麼反過來說，在外力的作用下狀態是可以改變的，這里就衍生出來產品設計中的一個法則叫「一動一態」即兩狀態間有任何數量級的操作都可以抽象為一個動作，一動一態的好處主要體現在：降低用戶認知成本;便於制定、處理各種狀態值
回到訂單狀態，如圖，用戶下單後的一系列操作其實是由三個維度的狀態(支付狀態、物流 狀態、評價狀態)構成，但多維度狀態的存在容易引起認知混亂，為解決這一問題，我們傾向於創建一個全局維度的狀態——訂單狀態
但如上圖中所示，構建後的全局維度涉及訂單下單-配送-簽收評價全流程，涉及：待支付、待發貨、待攬件、運輸中、派件中、已簽收、已評價，狀態值依然龐雜。想
一下，我們創建全局維度狀態要解決的就是降低使用者(商家、消費者)認知成本，知道在什麼步驟需要執行什麼操作，所以我們歸納下上述訂單狀態流轉時進行相關操作的執行角色：
消費者：支付、簽收、評價
商家：發貨
物流公司：攬件、走件、派件
我們會發現，需要消費者、商家操作的僅有：支付、發貨、簽收、評價。在定義一動一態法則時我們講到：任何數量級操作都可以抽象為一個操作，為了降低使用者(商家、消費者)認知成本，我們可以把[發貨、攬件、走件、派件] 這一流程抽象為一個操作——發貨。這樣一來就明了了
4. 訂單號的設計
訂單號的設計是一門藝術，能夠參與訂單號規則設計是一件令人興奮的事情，這種機會通常只在電商項目從0到1的時候有。那麼訂單號的設計應遵循哪些原則呢？
1）唯一性
訂單號作為訂單表的主鍵，需要確保唯一性。
2）易讀性
這里易讀性主要體現在系統易讀性和溝通易讀性。
要求訂單號不宜過長且盡量為純數字，不宜出現字母、符號、數字混用的情況，否者對於系統存儲、查詢性能、以及與用戶的溝通成本來說都是一種負擔。
3）安全性
非特殊情況盡量不要在訂單號中帶入平台運營特徵信息，如訂單數量，避免泄露運營數據。除非故意要讓競對知道你的運營數據。
瑞幸咖啡較早之前門店訂單量就是逐一增加，後續也加入了隨機因子，就是擔心外界通過訂單編號獲得店鋪每天成交量。
4）擴展性
訂單號設計需要考慮擴展性，如隨著平台業務發展，訂單量激增訂單號不夠用的情況
5）語義性
訂單編號規則中加入帶有語義的特徵信息，能在一定程度上提昇平台人員處理訂單的效率與便捷性。
常見的特性信息有：訂單生成時間(年月日)、下單渠道、支付渠道、業務類型等，但訂單編號中不宜攜帶過多特徵信息，否則會出現不法分子通過描述訂單信息博取用戶信任進行實施詐騙。
說到語義性，細心的同學會發現，自己淘寶訂單號後6位都是一樣的。訂單號後6位其實就是用戶id後6位。那麼淘寶訂單編號中用了用戶id後6位是否代表了語義性？答案是否定的，因為只用後6位id並不能准確定位到某一個用戶。
那麼淘寶訂單編號後6位用戶id後6位的目的是什麼？
翻遍了網路、知乎，沒有找到答案。
我是偶然間翻到一份淘寶技術演變PPT，看到訂單表分庫的邏輯時才恍然大悟。
一般的平台型電商，訂單量大，為保證查詢檢索速度，都會採用分庫的形式，將巨量的訂單信息分庫存儲，一般情況下訂單系統同時維護了一個訂單號和userid的關聯關系，先根據訂單號查到userid，再根據userid確定分表進而查詢得到內容。而淘寶在訂單號上下功夫，通過訂單號後6位直接鎖定庫表，大大提升高並發下的系統查詢性能。
從這個策略我們也可以看到淘寶用戶訂單庫是按照用戶id後6位存儲的，例如：XXXX452154格式的用戶訂單都是儲存在一個分庫中。
本文由 @阿鐵 原創發布於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議