中文字幕日韩精品一区二区免费_精品一区二区三区国产精品无卡在_国精品无码专区一区二区三区_国产αv三级中文在线

電商O2O用戶設(shè)計(jì)分析

2022-06-02    分類: 網(wǎng)站建設(shè)

之前和不少剛畢業(yè)的產(chǎn)品同學(xué)交流過,用戶端是他們十分偏向選擇的產(chǎn)品線??稍趯?shí)際的工作過程中,由于不太了解中后臺(tái)的情況加之邏輯上沒有那么成熟的經(jīng)驗(yàn),很容易出現(xiàn)界面設(shè)計(jì)完成后無法和中后臺(tái)的相關(guān)同學(xué)交流實(shí)現(xiàn)。所以用戶端產(chǎn)品也需要了解基礎(chǔ)的業(yè)務(wù)邏輯規(guī)則和關(guān)聯(lián)。今天創(chuàng)新互聯(lián)就分享下電商、020用戶端“背后”的邏輯。

用戶端的內(nèi)部構(gòu)造

用戶端一直有著迷之尷尬的地位,既充當(dāng)門面卻深受各個(gè)系統(tǒng)的“牽連”。所有系統(tǒng)的最終表現(xiàn)都依賴于用戶端的展現(xiàn),所以說用戶端是產(chǎn)品價(jià)值的最終體現(xiàn)。我們來看下用戶端內(nèi)部都有什么。


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

售前環(huán)節(jié):實(shí)現(xiàn)用戶購買前的瀏覽和檢索

首頁(對(duì)接CMS、商品、類目、推薦、促銷、廣告、搜索)

頻道頁(對(duì)接CMS、商品、類目、推薦、廣告)

專題頁(對(duì)接促銷、商品、CMS、廣告)

搜索結(jié)果頁(對(duì)接搜索、商品、推薦、廣告)

搜索分類頁(對(duì)接類目、商品、搜索、推薦、廣告)

發(fā)現(xiàn)頁(對(duì)接商品、搜索、推薦、促銷)

售前環(huán)節(jié)主要功能是完成商品的展示,頁面的信息布局和UI是此類模塊的首要功能。由于電商平臺(tái)商品、類目眾多,所以數(shù)據(jù)多是由負(fù)責(zé)規(guī)則整合的系統(tǒng)完成數(shù)據(jù)處理,然后通過頁面、內(nèi)容生成系統(tǒng)完成前臺(tái)的展示工作。

售中環(huán)節(jié):實(shí)現(xiàn)用戶的購買

售中環(huán)節(jié)也叫購買流程,是實(shí)現(xiàn)用戶從下單到完成支付的整個(gè)過程。這個(gè)流程是整個(gè)電商體系中最重要的環(huán)節(jié)。其中交易、訂單和支付系統(tǒng)負(fù)責(zé)這個(gè)環(huán)節(jié)的核心邏輯。

商品詳情頁(對(duì)接商品、促銷、推薦、廣告、CMS、會(huì)員)

購物車(對(duì)接商品、促銷、交易、推薦、廣告),其中庫存部分可放入商品或交易中合并計(jì)算,也可單獨(dú)由庫存系統(tǒng)提供處理。

結(jié)算頁,也叫訂單確認(rèn)頁(對(duì)接商品、促銷、交易、訂單、會(huì)員)

收銀臺(tái),也叫支付頁(對(duì)接支付、訂單)

支付完成頁,也叫訂單完成頁(對(duì)接訂單、推薦、廣告)

(1)購物車

購物車環(huán)節(jié)要考慮庫存是否需要做占用。購物車做預(yù)占庫存可以第一時(shí)間通知用戶庫存狀態(tài),但有可能出現(xiàn)較多占用后但未生成訂單的情況。而生成訂單后占庫存則能保證訂單和庫存匹配率大,但用戶在下單后才被告知無庫存,用戶體驗(yàn)相對(duì)較差。

常規(guī)做法會(huì)在購物車環(huán)節(jié)設(shè)置數(shù)量閾值,庫存小于閾值顯示用戶庫存緊張。然后在下單環(huán)節(jié)完成扣減庫存的情況。如果是秒殺或者是類似唯品會(huì)的搶購模式,則可以在購物車扣減庫存,增加倒計(jì)時(shí)(如15分鐘)提示提高用戶搶購感。

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

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

(2)結(jié)算頁

結(jié)算頁可以說是電商用戶端比較復(fù)雜的頁面之一。這里面涉及到配送邏輯判斷,送達(dá)時(shí)間計(jì)算,運(yùn)費(fèi)計(jì)算,訂單計(jì)算及分?jǐn)偟取?/p>

配送邏輯判斷:根據(jù)提供的配送方式結(jié)合倉配情況和移倉的邏輯來判斷來預(yù)計(jì)送到的時(shí)間。此部分的物流配送的路程情況也會(huì)影響運(yùn)費(fèi)的計(jì)算邏輯。當(dāng)無法單倉滿足或者移倉滿足時(shí),有可能需要拆多個(gè)包裹從不同的倉發(fā)送。

運(yùn)費(fèi)計(jì)算:根據(jù)后臺(tái)設(shè)置的運(yùn)費(fè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)偂?/p>

優(yōu)惠計(jì)算主要包括優(yōu)惠券和促銷活動(dòng)的金額計(jì)算。一般情況后臺(tái)會(huì)有一定的計(jì)算優(yōu)先級(jí),比如計(jì)算促銷活動(dòng)的金額,完成后再看是否滿足優(yōu)惠券的滿減金額。計(jì)算時(shí)需要考慮促銷范圍,如商家還是全場。

金額分?jǐn)?,電商的支付類型發(fā)展到如今是越來越豐富。信用卡、匯款、支付寶、微信、白條、積分、禮品卡等等各種各樣??紤]到訂單逆向(整單退,部分退)的情況,需要將所有支付的金額包括優(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)一分錢誤差的烏龍。

(3)收銀臺(tái)

訂單生成后要通過支付系統(tǒng)完成支付操作,所以收銀臺(tái)的主要對(duì)接系統(tǒng)就是支付系統(tǒng)。對(duì)接第三方支付的時(shí)候需要注意的是,第三方支付客戶端返回的狀態(tài)原則上不能作為最終支付成功的狀態(tài),要通過第三方支付服務(wù)端返回信息為準(zhǔn)。理論上這兩種狀態(tài)是同步的,但設(shè)計(jì)時(shí)要考慮交互和數(shù)據(jù)傳輸異常的情況。

售后環(huán)節(jié):提高信息透明和服務(wù)體驗(yàn)

訂單詳情頁

訂單列表頁

在線客服

售后環(huán)節(jié)主要是訂單生成后到訂單交付完成的整個(gè)過程。這部分主要的功能就是跟客服和訂單打交道。這里就不展開說了。只說一些需要注意的經(jīng)驗(yàn)。

訂單列表一般會(huì)保留三個(gè)月左右的用戶顯示數(shù)據(jù),而用戶端的刪除不是物理刪除只是訂單上打標(biāo)記而已。

在處理數(shù)據(jù)時(shí)考慮到歷史數(shù)據(jù)較多,部分O2O的APP會(huì)使用歷史訂單數(shù)據(jù)和當(dāng)日訂單數(shù)據(jù)分開的讀取的方式。

訂單詳情一般會(huì)有再來一單的功能,電商系統(tǒng)只需要判斷是否存在可售賣的SKU即可。而O2O則需要增加判斷區(qū)域?qū)傩浴?/p>

在線客服要考慮是否是對(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ōu)惠券等)。

這里強(qiáng)調(diào)一個(gè)小的細(xì)節(jié),APP用戶端有時(shí)候排查問題需要了解用戶的基本信息,比如版本號(hào),手機(jī)型號(hào)。用戶的反饋很容易出現(xiàn)信息誤差,他們大多會(huì)說已經(jīng)是最新版了。所以獲取版本信息的渠道可以在個(gè)人中心中。我以前的一個(gè)經(jīng)驗(yàn)可以給大家借鑒。在意見反饋?zhàn)詣?dòng)增加版本,手機(jī)型號(hào)信息回傳,或通過關(guān)于APP的部分讓用戶一鍵復(fù)制以便提供給客服進(jìn)行排查問題。

用戶端的“親屬關(guān)系”

用戶端作為“門臉”,和各個(gè)系統(tǒng)有著錯(cuò)綜復(fù)雜的關(guān)系,讓我們看下他們之間的關(guān)系是如何。


在整個(gè)電商系統(tǒng)體系里面。用戶端需要面對(duì)眾多系統(tǒng),而這些系統(tǒng)的數(shù)據(jù)又相互依存,他們之間通過API進(jìn)行傳輸對(duì)接。

直接對(duì)接系統(tǒng)


  • 頁面系統(tǒng)
  • CMS系統(tǒng)
  • 廣告系統(tǒng)
  • 購買流程
  • 交易系統(tǒng)
  • 支付系統(tǒng)
  • 訂單系統(tǒng)
  • 規(guī)則整合
  • 搜索系統(tǒng)
  • 推薦系統(tǒng)
  • 促銷系統(tǒng)
  • 用戶體系
  • 會(huì)員系統(tǒng)
  • 客服系統(tǒng)

這些直接提供數(shù)據(jù)給用戶端,負(fù)責(zé)用戶端的生養(yǎng)問題,用戶端對(duì)他們有著很強(qiáng)的依賴。在設(shè)計(jì)時(shí)要充分考慮這些系統(tǒng)的數(shù)據(jù)邏輯情況,下面我們會(huì)詳細(xì)說明下如何考慮這些系統(tǒng)。

間接對(duì)接系統(tǒng)


  • 庫存系統(tǒng)
  • 商品系統(tǒng)
  • 價(jià)格系統(tǒng)
  • 物流系統(tǒng)
  • 商家系統(tǒng)

間接對(duì)接的系統(tǒng)多是提供基礎(chǔ)信息的系統(tǒng)或者平臺(tái)。他們承擔(dān)著數(shù)據(jù)最底層的管理工作,他們的結(jié)構(gòu)決定了前端展示的信息數(shù)據(jù)項(xiàng)。由于涉及的細(xì)分系統(tǒng)眾多,這里指列舉了部分主要系統(tǒng)。

API

API主要是傳輸通道,理論上不做邏輯運(yùn)算。但現(xiàn)在很多實(shí)際的情況下API也需要夾雜很多業(yè)務(wù)規(guī)則的計(jì)算和處理。API主要包括幾個(gè)部分的功能:

(1)數(shù)據(jù)傳輸

API的基本功能,完成基本數(shù)據(jù)的傳輸,往往是以頁面為單位計(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)品迭代過程中,考慮到APP發(fā)版時(shí)間限制等制約因素,一些處理邏輯可能需要放在API進(jìn)行操作,比如部分信息項(xiàng)的篩選、ABtest、灰度發(fā)布切換邏輯。另外有些功能為了快速上線且后續(xù)可以進(jìn)行延展,一些固定的邏輯也會(huì)考慮先不做后臺(tái),在API中通過配置文件的方式來實(shí)現(xiàn)。比如提示文案、icon等。

(4)緩存功能

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

數(shù)據(jù)統(tǒng)計(jì)系統(tǒng)

數(shù)據(jù)統(tǒng)計(jì)系統(tǒng)主要用來處理用戶端埋點(diǎn)的信息,用于監(jiān)測流量數(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í)提高可行性和合理性。

分享名稱:電商O2O用戶設(shè)計(jì)分析
URL地址:http://m.rwnh.cn/news23/162673.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供小程序開發(fā)、App開發(fā)、建站公司、靜態(tài)網(wǎng)站標(biāo)簽優(yōu)化、響應(yīng)式網(wǎng)站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

成都網(wǎng)站建設(shè)
喀什市| 石柱| 台中县| 太谷县| 苏尼特右旗| 黎城县| 太谷县| 余江县| 滦平县| 工布江达县| 安达市| 临湘市| 屏东市| 环江| 攀枝花市| 霍林郭勒市| 张家界市| 许昌县| 虞城县| 奈曼旗| 襄樊市| 邵东县| 合山市| 永福县| 甘孜县| 连南| 海晏县| 陈巴尔虎旗| 泗洪县| 乌兰察布市| 仲巴县| 宣恩县| 菏泽市| 楚雄市| 成都市| 丰镇市| 和静县| 长沙县| 绥中县| 天柱县| 柘城县|