之前和不少剛畢業(yè)的產(chǎn)品同學(xué)交流過(guò)，用戶端是他們十分偏向選擇的產(chǎn)品線?？稍趯?shí)際的工作過(guò)程中，由于不太了解中后臺(tái)的情況加之邏輯上沒(méi)有那么成熟的經(jīng)驗(yàn)，很容易出現(xiàn)界面設(shè)計(jì)完成后無(wú)法和中后臺(tái)的相關(guān)同學(xué)交流實(shí)現(xiàn)。所以用戶端產(chǎn)品也需要了解基礎(chǔ)的業(yè)務(wù)邏輯規(guī)則和關(guān)聯(lián)。今天我們就分享下電商、020用戶端“背后”的邏輯。
用戶端的內(nèi)部構(gòu)造
用戶端一直有著迷之尷尬的地位，既充當(dāng)門(mén)面卻深受各個(gè)系統(tǒng)的“牽連”。所有系統(tǒng)的最終表現(xiàn)都依賴于用戶端的展現(xiàn)，所以說(shuō)用戶端是產(chǎn)品價(jià)值的最終體現(xiàn)。我們來(lái)看下用戶端內(nèi)部都有什么。
電商的用戶端主要功能是提供購(gòu)買(mǎi)和商品展示，并能夠協(xié)助用戶進(jìn)行個(gè)人服務(wù)管理。從用戶的階段來(lái)劃分，主要分成售前、售中、售后三個(gè)階段。其中個(gè)人信息的管理屬于貫穿整個(gè)使用過(guò)程。
售前環(huán)節(jié)：實(shí)現(xiàn)用戶購(gòu)買(mǎi)前的瀏覽和檢索
- 首頁(yè)（對(duì)接CMS、商品、類目、推薦、促銷、廣告、搜索）
- 頻道頁(yè)（對(duì)接CMS、商品、類目、推薦、廣告）
- 專題頁(yè)（對(duì)接促銷、商品、CMS、廣告）
- 搜索結(jié)果頁(yè)（對(duì)接搜索、商品、推薦、廣告）
- 搜索分類頁(yè)（對(duì)接類目、商品、搜索、推薦、廣告）
- 發(fā)現(xiàn)頁(yè)(對(duì)接商品、搜索、推薦、促銷)
售中環(huán)節(jié)：實(shí)現(xiàn)用戶的購(gòu)買(mǎi)
售中環(huán)節(jié)也叫購(gòu)買(mǎi)流程，是實(shí)現(xiàn)用戶從下單到完成支付的整個(gè)過(guò)程。這個(gè)流程是整個(gè)電商體系中最重要的環(huán)節(jié)。其中交易、訂單和支付系統(tǒng)負(fù)責(zé)這個(gè)環(huán)節(jié)的核心邏輯。- 商品詳情頁(yè)（對(duì)接商品、促銷、推薦、廣告、CMS、會(huì)員）
- 購(gòu)物車（對(duì)接商品、促銷、交易、推薦、廣告），其中庫(kù)存部分可放入商品或交易中合并計(jì)算，也可單獨(dú)由庫(kù)存系統(tǒng)提供處理。
- 結(jié)算頁(yè)，也叫訂單確認(rèn)頁(yè)（對(duì)接商品、促銷、交易、訂單、會(huì)員）
- 收銀臺(tái)，也叫支付頁(yè)（對(duì)接支付、訂單）
- 支付完成頁(yè)，也叫訂單完成頁(yè)（對(duì)接訂單、推薦、廣告）
配送邏輯判斷：根據(jù)提供的配送方式結(jié)合倉(cāng)配情況和移倉(cāng)的邏輯來(lái)判斷來(lái)預(yù)計(jì)送到的時(shí)間。此部分的物流配送的路程情況也會(huì)影響運(yùn)費(fèi)的計(jì)算邏輯。當(dāng)無(wú)法單倉(cāng)滿足或者移倉(cāng)滿足時(shí)，有可能需要拆多個(gè)包裹從不同的倉(cāng)發(fā)送。
運(yùn)費(fèi)計(jì)算：根據(jù)后臺(tái)設(shè)置的運(yùn)費(fèi)模板來(lái)計(jì)算實(shí)際應(yīng)該收取的運(yùn)費(fèi)。運(yùn)費(fèi)模板是指設(shè)定好的一套運(yùn)費(fèi)規(guī)則，比如滿XX收多少等。
訂單計(jì)算：訂單計(jì)算主要涉及到交易單各個(gè)子單之間促銷優(yōu)惠的計(jì)算和金額分?jǐn)偂?
- 優(yōu)惠計(jì)算主要包括優(yōu)惠券和促銷活動(dòng)的金額計(jì)算。一般情況后臺(tái)會(huì)有一定的計(jì)算優(yōu)先級(jí)，比如計(jì)算促銷活動(dòng)的金額，完成后再看是否滿足優(yōu)惠券的滿減金額。計(jì)算時(shí)需要考慮促銷范圍，如商家還是全場(chǎng)。
- 金額分?jǐn)?，電商的支付類型發(fā)展到如今是越來(lái)越豐富。信用卡、匯款、支付寶、微信、白條、積分、禮品卡等等各種各樣?？紤]到訂單逆向（整單退，部分退）的情況，需要將所有支付的金額包括優(yōu)惠券都分?jǐn)偟矫恳粋€(gè)商品上，以便退款時(shí)可以保證金額不錯(cuò)。分?jǐn)傆?jì)算有兩個(gè)要注意的事情，一個(gè)是各項(xiàng)支付方式退款的優(yōu)先級(jí)，先退什么在退什么。原則上先退成本低的，在退成本高的。二是當(dāng)分?jǐn)倳r(shí)金額除不盡的時(shí)候多余的部分如何分?jǐn)?，小?shù)后三位的時(shí)候四舍五入還是直接舍掉。這個(gè)規(guī)則要和后端、報(bào)表保持一致，避免出現(xiàn)一分錢(qián)誤差的烏龍。
售后環(huán)節(jié)：提高信息透明和服務(wù)體驗(yàn)
- 訂單詳情頁(yè)
- 訂單列表頁(yè)
- 在線客服
- 訂單列表一般會(huì)保留三個(gè)月左右的用戶顯示數(shù)據(jù)，而用戶端的刪除不是物理刪除只是訂單上打標(biāo)記而已。
- 在處理數(shù)據(jù)時(shí)考慮到歷史數(shù)據(jù)較多，部分O2O的APP會(huì)使用歷史訂單數(shù)據(jù)和當(dāng)日訂單數(shù)據(jù)分開(kāi)的讀取的方式。
- 訂單詳情一般會(huì)有再來(lái)一單的功能，電商系統(tǒng)只需要判斷是否存在可售賣(mài)的SKU即可。而O2O則需要增加判斷區(qū)域?qū)傩浴?/li>
- 在線客服要考慮是否是對(duì)接第三方應(yīng)用，在嵌入對(duì)方的SDK時(shí)一些通用的標(biāo)準(zhǔn)要符合滿足（比如IPV6）。另外對(duì)方SDK包是否會(huì)對(duì)自己APP的大小造成較大影響也需要注意。
個(gè)人中心：服務(wù)中轉(zhuǎn)站
個(gè)人中心作為用戶的統(tǒng)一服務(wù)中心，里面承載了所有涉及用戶資產(chǎn)和服務(wù)的信息。大多數(shù)是信息匯總查看的頁(yè)面（如我的訂單、我的積分、我的優(yōu)惠券等）。 這里強(qiáng)調(diào)一個(gè)小的細(xì)節(jié)，APP用戶端有時(shí)候排查問(wèn)題需要了解用戶的基本信息，比如版本號(hào)，手機(jī)型號(hào)。用戶的反饋很容易出現(xiàn)信息誤差，他們大多會(huì)說(shuō)已經(jīng)是最新版了。所以獲取版本信息的渠道可以在個(gè)人中心中。我以前的一個(gè)經(jīng)驗(yàn)可以給大家借鑒。在意見(jiàn)反饋?zhàn)詣?dòng)增加版本，手機(jī)型號(hào)信息回傳，或通過(guò)關(guān)于APP的部分讓用戶一鍵復(fù)制以便提供給客服進(jìn)行排查問(wèn)題。用戶端的“親屬關(guān)系”
用戶端作為“門(mén)臉”，和各個(gè)系統(tǒng)有著錯(cuò)綜復(fù)雜的關(guān)系，讓我們看下他們之間的關(guān)系是如何。
在整個(gè)電商系統(tǒng)體系里面。用戶端需要面對(duì)眾多系統(tǒng)，而這些系統(tǒng)的數(shù)據(jù)又相互依存，他們之間通過(guò)API進(jìn)行傳輸對(duì)接。
直接對(duì)接系統(tǒng)
頁(yè)面系統(tǒng)- CMS系統(tǒng)
- 廣告系統(tǒng)
- 交易系統(tǒng)
- 支付系統(tǒng)
- 訂單系統(tǒng)
- 搜索系統(tǒng)
- 推薦系統(tǒng)
- 促銷系統(tǒng)
- 會(huì)員系統(tǒng)
- 客服系統(tǒng)
間接對(duì)接系統(tǒng)
- 庫(kù)存系統(tǒng)
- 商品系統(tǒng)
- 價(jià)格系統(tǒng)
- 物流系統(tǒng)
- 商家系統(tǒng)
API
API主要是傳輸通道，理論上不做邏輯運(yùn)算。但現(xiàn)在很多實(shí)際的情況下API也需要夾雜很多業(yè)務(wù)規(guī)則的計(jì)算和處理。API主要包括幾個(gè)部分的功能： （1）數(shù)據(jù)傳輸 API的基本功能，完成基本數(shù)據(jù)的傳輸，往往是以頁(yè)面為單位計(jì)算API的數(shù)量。 （2）數(shù)據(jù)整合 由于數(shù)據(jù)可能涉及到多個(gè)系統(tǒng)之間的調(diào)用，所以API內(nèi)部可能需要進(jìn)行數(shù)據(jù)的整合。比如促銷活動(dòng)信息需要調(diào)用促銷信息和商品基礎(chǔ)信息。 （3）部分邏輯處理 在實(shí)際產(chǎn)品迭代過(guò)程中，考慮到APP發(fā)版時(shí)間限制等制約因素，一些處理邏輯可能需要放在API進(jìn)行操作，比如部分信息項(xiàng)的篩選、ABtest、灰度發(fā)布切換邏輯。另外有些功能為了快速上線且后續(xù)可以進(jìn)行延展，一些固定的邏輯也會(huì)考慮先不做后臺(tái)，在API中通過(guò)配置文件的方式來(lái)實(shí)現(xiàn)。比如提示文案、icon等。 （4）緩存功能 提供給用戶端的數(shù)據(jù)中，不是所有數(shù)據(jù)都需要實(shí)時(shí)更新獲取的,所以API會(huì)將部分更新周期較長(zhǎng)的數(shù)據(jù)放入緩存中定時(shí)去更新。比如用戶信息、類目信息。數(shù)據(jù)統(tǒng)計(jì)系統(tǒng)
數(shù)據(jù)統(tǒng)計(jì)系統(tǒng)主要用來(lái)處理用戶端埋點(diǎn)的信息，用于監(jiān)測(cè)流量數(shù)據(jù)的情況。 一般數(shù)據(jù)統(tǒng)計(jì)重要分為使用第三方或者自建BI系統(tǒng)兩種情況。用戶端需要做的主要是進(jìn)行埋點(diǎn)事件的命名和選擇觸發(fā)點(diǎn)。?結(jié)言
用戶端看似只是關(guān)注用戶體驗(yàn)和界面功能設(shè)計(jì)，實(shí)則反應(yīng)了整個(gè)電商生態(tài)下所有系統(tǒng)運(yùn)作的最終結(jié)果。了解中后臺(tái)的基本邏輯和流程有助于在構(gòu)想界面時(shí)提高可行性和合理性。【轉(zhuǎn)載說(shuō)明】 若上述素材出現(xiàn)侵權(quán)，請(qǐng)及時(shí)聯(lián)系我們刪除及進(jìn)行處理：[email protected]
