之前和不少剛畢業的產品同學交流過，用戶端是他們十分偏向選擇的產品線?？稍趯嶋H的工作過程中，由于不太了解中后臺的情況加之邏輯上沒有那么成熟的經驗，很容易出現界面設計完成后無法和中后臺的相關同學交流實現。所以用戶端產品也需要了解基礎的業務邏輯規則和關聯。今天我們就分享下電商、020用戶端“背后”的邏輯。

用戶端的內部構造

用戶端一直有著迷之尷尬的地位，既充當門面卻深受各個系統的“牽連”。所有系統的最終表現都依賴于用戶端的展現，所以說用戶端是產品價值的最終體現。我們來看下用戶端內部都有什么。

電商的用戶端主要功能是提供購買和商品展示，并能夠協助用戶進行個人服務管理。從用戶的階段來劃分，主要分成售前、售中、售后三個階段。其中個人信息的管理屬于貫穿整個使用過程。

售前環節：實現用戶購買前的瀏覽和檢索。

• 首頁（對接CMS、商品、類目、推薦、促銷、廣告、搜索）
• 頻道頁（對接CMS、商品、類目、推薦、廣告）
• 專題頁（對接促銷、商品、CMS、廣告）
• 搜索結果頁（對接搜索、商品、推薦、廣告）
• 搜索分類頁（對接類目、商品、搜索、推薦、廣告）
• 發現頁(對接商品、搜索、推薦、促銷)

售前環節主要功能是完成商品的展示,頁面的信息布局和UI是此類模塊的首要功能。由于電商平臺商品、類目眾多，所以數據多是由負責規則整合的系統完成數據處理，然后通過頁面、內容生成系統完成前臺的展示工作。

售中環節：實現用戶的購買

售中環節也叫購買流程，是實現用戶從下單到完成支付的整個過程。這個流程是整個電商體系中最重要的環節。其中交易、訂單和支付系統負責這個環節的核心邏輯。

• 商品詳情頁（對接商品、促銷、推薦、廣告、CMS、會員）
• 購物車（對接商品、促銷、交易、推薦、廣告），其中庫存部分可放入商品或交易中合并計算，也可單獨由庫存系統提供處理。
• 結算頁，也叫訂單確認頁（對接商品、促銷、交易、訂單、會員）
• 收銀臺，也叫支付頁（對接支付、訂單）
• 支付完成頁，也叫訂單完成頁（對接訂單、推薦、廣告）

（1）購物車

購物車環節要考慮庫存是否需要做占用。購物車做預占庫存可以第一時間通知用戶庫存狀態，但有可能出現較多占用后但未生成訂單的情況。而生成訂單后占庫存則能保證訂單和庫存匹配率最大，但用戶在下單后才被告知無庫存，用戶體驗相對較差。

常規做法會在購物車環節設置數量閾值，庫存小于閾值顯示用戶庫存緊張。然后在下單環節完成扣減庫存的情況。如果是秒殺或者是類似唯品會的搶購模式，則可以在購物車扣減庫存，增加倒計時（如15分鐘）提示提高用戶搶購感。

促銷金額的計算也是購物車需要考慮的主要邏輯之一，由于商品詳情頁都是單品信息，所以組合促銷的金額計算是在購物車體現的。

另外，作為電商的“近親”020領域的購物車相比傳統電商處理方法有所差異。020的購物車原則上很多是不跨店鋪銷售的，所以購物車是存在于單個店鋪中且以浮層的方式展示。一般來說為避免對于服務器造成壓力過大的問題，不是所有的添加商品的操作都是請求后端服務，在邏輯處理上為了保證一致需要前后端都考慮邏輯統一的問題。

（2）結算頁

結算頁可以說是電商用戶端比較復雜的頁面之一。這里面涉及到配送邏輯判斷，送達時間計算，運費計算，訂單計算及分攤等。

配送邏輯判斷：根據提供的配送方式結合倉配情況和移倉的邏輯來判斷來預計送到的時間。此部分的物流配送的路程情況也會影響運費的計算邏輯。當無法單倉滿足或者移倉滿足時，有可能需要拆多個包裹從不同的倉發送。

運費計算：根據后臺設置的運費模板來計算實際應該收取的運費。運費模板是指設定好的一套運費規則，比如滿XX收多少等。

訂單計算：訂單計算主要涉及到交易單各個子單之間促銷優惠的計算和金額分攤。

• 優惠計算主要包括優惠券和促銷活動的金額計算。一般情況后臺會有一定的計算優先級，比如計算促銷活動的金額，完成后再看是否滿足優惠券的滿減金額。計算時需要考慮促銷范圍，如商家還是全場。
• 金額分攤，電商的支付類型發展到如今是越來越豐富。信用卡、匯款、支付寶、微信、白條、積分、禮品卡等等各種各樣?？紤]到訂單逆向（整單退，部分退）的情況，需要將所有支付的金額包括優惠券都分攤到每一個商品上，以便退款時可以保證金額不錯。分攤計算有兩個要注意的事情，一個是各項支付方式退款的優先級，先退什么在退什么。原則上先退成本低的，在退成本高的。二是當分攤時金額除不盡的時候多余的部分如何分攤，小數后三位的時候四舍五入還是直接舍掉。這個規則要和后端、報表保持一致，避免出現一分錢誤差的烏龍。

（3）收銀臺

訂單生成后要通過支付系統完成支付操作，所以收銀臺的主要對接系統就是支付系統。對接第三方支付的時候需要注意的是，第三方支付客戶端返回的狀態原則上不能作為最終支付成功的狀態，要通過第三方支付服務端返回信息為準。理論上這兩種狀態是同步的，但設計時要考慮交互和數據傳輸異常的情況。

售后環節：提高信息透明和服務體驗

• 訂單詳情頁
• 訂單列表頁
• 在線客服

售后環節主要是訂單生成后到訂單交付完成的整個過程。這部分主要的功能就是跟客服和訂單打交道。這里就不展開說了。只說一些需要注意的經驗。

1. 訂單列表一般會保留三個月左右的用戶顯示數據，而用戶端的刪除不是物理刪除只是訂單上打標記而已。
2. 在處理數據時考慮到歷史數據較多，部分O2O的APP會使用歷史訂單數據和當日訂單數據分開的讀取的方式。
3. 訂單詳情一般會有再來一單的功能，電商系統只需要判斷是否存在可售賣的SKU即可。而O2O則需要增加判斷區域屬性。
4. 在線客服要考慮是否是對接第三方應用，在嵌入對方的SDK時一些通用的標準要符合滿足（比如IPV6）。另外對方SDK包是否會對自己APP的大小造成較大影響也需要注意。

個人中心：服務中轉站

個人中心作為用戶的統一服務中心，里面承載了所有涉及用戶資產和服務的信息。大多數是信息匯總查看的頁面（如我的訂單、我的積分、我的優惠券等）。

這里強調一個小的細節，APP用戶端有時候排查問題需要了解用戶的基本信息，比如版本號，手機型號。用戶的反饋很容易出現信息誤差，他們大多會說已經是最新版了。所以獲取版本信息的渠道可以在個人中心中。我以前的一個經驗可以給大家借鑒。在意見反饋自動增加版本，手機型號信息回傳，或通過關于APP的部分讓用戶一鍵復制以便提供給客服進行排查問題。

用戶端的“親屬關系”

用戶端作為“門臉”，和各個系統有著錯綜復雜的關系，讓我們看下他們之間的關系是如何。

在整個電商系統體系里面。用戶端需要面對眾多系統，而這些系統的數據又相互依存，他們之間通過API進行傳輸對接。

直接對接系統

頁面系統

• CMS系統
• 廣告系統

購買流程

• 交易系統
• 支付系統
• 訂單系統

規則整合

• 搜索系統
• 推薦系統
• 促銷系統

用戶體系

• 會員系統
• 客服系統

這些直接提供數據給用戶端，負責用戶端的生養問題，用戶端對他們有著很強的依賴。在設計時要充分考慮這些系統的數據邏輯情況，下面我們會詳細說明下如何考慮這些系統。

間接對接系統

• 庫存系統
• 商品系統
• 價格系統
• 物流系統
• 商家系統

間接對接的系統多是提供基礎信息的系統或者平臺。他們承擔著數據最底層的管理工作，他們的結構決定了前端展示的信息數據項。由于涉及的細分系統眾多，這里指列舉了部分主要系統。

API

API主要是傳輸通道，理論上不做邏輯運算。但現在很多實際的情況下API也需要夾雜很多業務規則的計算和處理。API主要包括幾個部分的功能：

（1）數據傳輸

API的基本功能，完成基本數據的傳輸，往往是以頁面為單位計算API的數量。

（2）數據整合

由于數據可能涉及到多個系統之間的調用，所以API內部可能需要進行數據的整合。比如促銷活動信息需要調用促銷信息和商品基礎信息。

（3）部分邏輯處理

在實際產品迭代過程中，考慮到APP發版時間限制等制約因素，一些處理邏輯可能需要放在API進行操作，比如部分信息項的篩選、ABtest、灰度發布切換邏輯。另外有些功能為了快速上線且后續可以進行延展，一些固定的邏輯也會考慮先不做后臺，在API中通過配置文件的方式來實現。比如提示文案、icon等。

（4）緩存功能

提供給用戶端的數據中，不是所有數據都需要實時更新獲取的,所以API會將部分更新周期較長的數據放入緩存中定時去更新。比如用戶信息、類目信息。

數據統計系統

數據統計系統主要用來處理用戶端埋點的信息，用于監測流量數據的情況。

一般數據統計重要分為使用第三方或者自建BI系統兩種情況。用戶端需要做的主要是進行埋點事件的命名和選擇觸發點。

?結言

用戶端看似只是關注用戶體驗和界面功能設計，實則反應了整個電商生態下所有系統運作的最終結果。了解中后臺的基本邏輯和流程有助于在構想界面時提高可行性和合理性。

相關閱讀

解構電商、O2O：訂單系統，平臺的“生命中軸線”

解構電商、020：查閱商品的“檔案柜”

解構電商、020：探秘搜索系統的“簡歷”

解構電商、020：促銷系統的“進化”之路

解構用戶消費心理：卓越的服務體驗始于「心」

作者：高暉（微信號公眾號@產品老高），10余年IT經驗，互聯網老兵。

本文由 @高暉 微信公眾號原創發布于人人都是產品經理。未經許可，禁止轉載