電商入門(2):購物車功能要點和背后邏輯

QJQ
27 評論 43793 瀏覽 233 收藏 14 分鐘

本文主要分為四個部分:簡單說一下購物車、購物車與后臺的密切關系、購物車中商品的分組和排序、關于購物車你至少應該知道些什么。

1.先簡單說一下購物車

對前臺電商產品經理來說,設計一個好的購物車,整個網站的靈魂基本上就有了,“設計購物車”可絕對不是說設計購物車的外觀表現形式,而是它背后的東西——購物車的邏輯。

前臺購物車主要與后臺商品中心、庫存中心、營銷中心發生關系,你品味一下這三個問題:加車的商品是什么?加車的商品還有么?加車的商品有優惠么?

關于購物車的作用,大家可以類比一下線下商場的購物車,這種類比方法我已經在上一篇中提到過了。提一下購物車最直觀的幾個作用:

存儲用戶精挑細選的商品、方便多個商品組合起來做促銷;如果你看得長遠一點就會發現,購物車甚至能幫助自營平臺節省物流成本,把同類型商品提前歸集,統一派分到同一倉庫。

思考一個問題:假設A書和B書在同一個倉庫,如果沒有購物車,A書和B書只能分兩次結算,是不是意味著會生成兩個訂單?分配到倉庫后,倉庫管理員有這個能力合單?(當然,也不是完全做不到~)

在設計前臺購物車的時候有兩個重要的關乎用戶體驗的點:購物車中商品的分組和排序,即在購物車中,哪些商品需要歸為一類?商品在購物車中怎么排列?

大家需要注意一點,購物車中的計算、商品數量調整、促銷活動修改、優惠券領取,甚至是商品選中等等操作,都是后臺邏輯,前臺只是獲取服務器端的數據加以展示而已。

2.舉個例子說明購物車與后臺的密切關系

舉個例子:比如商品數量調整,需要從服務器端check該商品是否有對應數量的庫存,對應兩種情況:庫存充足和不足。實時check商品庫存能緩解‘結算按鈕’的計算壓力,同時能讓用戶購物更流暢。

怎么理解呢?其實在處理前臺商品數量增減功能時,如何判斷庫存的問題上,有兩種處理方式:一種是實時check商品庫存,一種是非實時check商品庫存。

說一下后者,第二種方式是在商品加車的那一瞬間(或者刷新購物車頁面)服務器端就已經告訴前臺某某商品購物車最大可加車數量是多少了。

再舉個具體的例子對比2種方式的區別,希望能幫助大家深入理解:假設A商品庫存為2,用戶甲將A加入購物車,并在購物車中調整A的數量,最多能調整到2;這時用戶乙也將A加入購物車,并且結算了一件A。此時,我們知道現在A的實際庫存只有1件了。

實時check庫存:用戶甲購物車只能將A數量調整為1;

非實時check庫存:用戶甲購物車仍然能將A的數量調整為2,然而只有當用戶甲點擊“去結算按鈕”時,才會再去check一遍庫存,這時候前臺告訴用戶,A商品已經不足了,您需要返回購物車調整(或者直接在彈層提示上調整A的數量)。

這就是我之前說的實時check商品庫存能緩解“結算按鈕”的計算壓力,同時能讓用戶購物更流暢。所以,對于前臺產品來說,你的購物車基本上沒有多少與你有關系的東西。

不過,你可以從用戶體驗上約定一些規則,比如check庫存的實現方式,如果技術說有難度會造成服務器壓力,那你該怎么辦呢?只能嘗試說服對方,或者退而求其次在‘結算按鈕’附近優化彈層提示,盡量讓用戶體驗更流暢,這就是一個好的前臺產品了,絕對不是按鈕多大、怎么擺放的問題了。

這么來看,對于一個前臺產品,購物車的核心就落在了購物車中商品的分組和排序邏輯上。

所以,接下來的重點內容就是:

  • ①如何制定相關規則,讓購物車中的商品有序,讓用戶體驗更好。
  • ②關于購物車你至少還要知道些什么?

3.購物車中商品的分組和排序

說這個分組和排序問題之前,如果大家對這個概念還不太理解,建議先去淘寶或者京東這樣的電商平臺看看它們的購物車,特別是產品新人。

再說一說分組和排序大概是要解決一個什么問題,可以看一看下圖:

從上圖的結構可以看出來,購物車中的商品是按照活動A和B以及未參加活動三個組來展示的,由此也可以看出層級關系為:(店鋪 >>)活動 >> 商品(注:別忘了店鋪是最大一級)。

基本上每個電商平臺都有店鋪的概念,也就是允許第三方商家來平臺開店,豐富平臺商品類目、sku。在這種情況下,購物車中的商品按照店鋪分組無可厚非了,但是今天為了讓模型更簡單一點,假設平臺只有一個店鋪(或者是純自營平臺),這是大前提。所以,接下來要說的就只涉及到參與同一個活動的商品分到一組這種分組的形式(建議再回頭看看上圖)。

然后是關于排序,我們知道給任何一組數據排序都需要給定排序規則,不然就是隨機紊亂呈現的。對于購物車中的商品,能作為排序依據的無疑是它的加車時間,每個商品加入購物車都會記錄一個加車時間。

接下來需要解決三個問題:

  • ①還原商品排序和分組的邏輯判斷與過程;
  • ②新加車商品D,該放在哪兒?
  • ③如果修改某個商品參加的活動,購物車該如何變動?(第三點是最能體現用戶體驗的問題。)

假設有如下表所示5個商品,該表記錄了它們的商品名、加車時間以及參加哪個活動5條記錄。另外,需要補充一句是:一般新加車的商品,排在購物車最上方,不然有可能導致用戶打開購物車看不到自己剛加車的商品。

先解決第一個問題:還原商品排序和分組的邏輯判斷與過程;

購物車的分組與排序是結構化的,程序員的思路也是結構化的,所以大家在考慮產品邏輯的時候,也要有結構化的思維(為了和猿友好相處),一個商品加入購物車首先第一步是判斷(它是哪家店鋪的?),它是哪個活動底下的?它的加車時間是什么?(從大到小的邏輯順序)有了這個過程之后,這個商品的位置自然也確定了,如下表所示:

你可以看到商品B1加車比商品A2晚,但是卻排在了商品A2之后,這是什么原因呢?

這里需要將排序問題分為三類:組與組之間排序、組內排序、組與非組(單個商品)之間排序。

  • 先說第一類,有一個規則是組內最晚加車的商品為該組的加車時間,以組的加車時間為依據進行組與組之間排序。
  • 再說第二類,按照組內后加車商品在上規則排序。
  • 最后說第三類,組的加車時間與單個商品加車時間,后加車者在上規則排序,類似于第二類情況。

下面再解決第二個問題:新加車商品D(12:00加車),該放在哪兒?

如果D沒有參加任何活動,很明顯按照第三類規則,需要將D置于購物車第一位,這里不用表來展示了;但是如果D參加了活動B,那么當用戶進入購物車頁,他將看到什么呢?如下圖所示。

注意,由于商品D參加了活動B,導致商品B1和B2都跟著往上移動了。

最后再來說最重要的一個問題:如果修改某個商品參加的活動,購物車該如何變動?

說這點之前,先說為什么它很重要,第2個有關排序的問題發生場景其實不在購物車頁,而是用戶在進入購物車場景前,就已經發生了,用戶進入購物車看到的是一個靜態的頁面;但是第三個問題,發生場景就在購物車中,正所謂是牽一發而動全身,試想一下,用戶只是調整了一下購物車中商品所參加的活動,購物車排序大動,導致用戶找不到剛調整過的商品,這種體驗可想而知。

還需要說到另外一點是,這也是前文制定這樣一個排序和分組規則的原因,當然也是為了解決問題3,提升用戶體驗。

假設商品C參加了活動A或B(一開始只是用戶故意選擇不參加任何活動),那么當用戶將商品C修改為參加活動A或B后,它的位置將如何變動?這里我就不再提供表格,大家去思考一下,實在不明白可以在文后提問我。

補充說明一點,為什么會有不參加活動的選項?

大家思考一下這個問題:假設平臺滿30包郵,不滿則出6元郵費,現在商品E(單價=30元)參加了滿30減5的活動,用戶購買一件E,問,該用戶應該參加活動么?為什么? (這個問題有一個前提是,平臺計算是否滿包郵的條件是以優惠后應付金額為準)

本文最重要的一部分算是講完了,之后該講一點其他細枝末節的東西了,關于購物車你還應該知道些什么?

4.關于購物車你至少應該知道些什么?

我覺得關于購物車你還應該知道的應該在下面這張腦圖里了,第一是購物車中的商品從哪兒來到哪兒去,第二是購物車至少需要具備那幾個功能點(我這里說的是骨架),至于其他錦上添花的功能,讀者可以留言分享給大家。

另外在設計購物車的時候,還有一個影響體驗的細節——購物車合并問題,當一個用戶在未登錄狀態加車,在他下次登陸賬戶時,應該將未登錄狀態已加車商品并入已登錄賬戶購物車中。這里也有一個前提是:默認未登錄狀態也可以加購物車。

本篇到這里算是結束了,很多東西感覺沒有說透,可能需要讀者自己去深入研究,如果有什么心得體會,也歡迎大家一起交流。

相關閱讀

電商入門(1):先從線下到線上說起

電商入門 (3):電商CMS,一勞永逸的建站方案

 

作者:QJQ,微信公眾號:倔牛的人生

本文由 @QJQ 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自pixabay,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 時時查詢怎么查?查詢周期多久?是一某一個商品時時查詢?還是勾選的商品都時時查詢?這種邏輯是不是有問題?

    回復
    1. 實時查詢應該會有一個規則的吧,我覺得這個問題需要產品和技術一起去評估,需要考慮實際情況

      來自浙江 回復
  2. 你好,請問,關于check商品庫存處理方式這一段,“說一下后者”后面的文字應該解釋的是實時check商品庫存吧?
    順便請教一下,如果是實時check,用戶A將商品C加入購物車之后又去找其它商品了,這時用戶B過來結算了一件商品C,當用戶A再進入購物車的時候,商品C的數量如何處理呢?是后臺自動刷新數量并顯示當前數量嗎?是否需要給出提醒呢?
    抱歉,產品小白

    來自廣東 回復
    1. 加入購物車后就要占庫存總量的緩存

      來自重慶 回復
    2. 后面的文字解釋的是 非 實時check商品庫存,仔細讀,我開始也以為作者寫錯了

      來自浙江 回復
  3. 有沒有發現購物的時候,增加商品數量沒有提示只是1變成了2,2變3如是這樣,但是減少商品的時候就要二次確認,是否減少商品數量

    來自內蒙古 回復
  4. 總結得很棒,受益匪淺

    來自浙江 回復
  5. 京東貌似是在提交訂單時提示用戶庫存不足,而且提示用戶是否移除,用戶移除后訂單繼續提交,用戶被打斷一次,但是整體流程還是相對順暢的;我覺得在提交訂單時再次校驗庫存比在結算時校驗對訂單提交成功率來說更好一點,畢竟越早打斷用戶越容易終止。

    來自浙江 回復
    1. 你的意思越早打斷那不就是在提交訂單的時候嗎?和前面成功率高的結論相反了

      回復
  6. 商品C修改為參加活動A或B后,它的位置將如何變動?

    來自北京 回復
    1. 一年過去了啊,我想了一下,以加入購物車的時間為準,不管在購物車中怎么修改,不記錄修改時間。

      來自浙江 回復
  7. 為什么購物車加減要實時?意義在哪?求教

    來自浙江 回復
    1. 文章里其實提到了,你可以再返回去看看京東和淘寶對比的例子:操作流程上不連貫(或者說是,非一氣呵成的生成購物清單)

      來自北京 回復
    2. 可是如果用戶A加車50件,遲遲不下單,會影響到實際庫存,B用戶就沒有辦法購買了。我的做法還是認為等用戶A下單成功了再減少庫存為好。

      來自浙江 回復
    3. 這也是我疑惑的點,希望求大神解答

      來自浙江 回復
    4. 我之前 的疑問消失了,作者的意思如下,你可以再看一遍他的原文哦
      舉例子說明吧
      A產品有100個庫存
      我把1個加入購物車,我朋友把2個加入他自己的購物車,實際庫存是不變的,還是100個,顯示給他人的庫存還是有100個
      當你提交訂單之后,庫存才會變成99個。
      然后我朋友的購物車里看到庫存的數量會變成99個,而不是之前的100個。

      來自浙江 回復
  8. 當一個用戶在未登錄狀態加車,在他下次登陸賬戶時,應該將未登錄狀態已加車商品并入已登錄賬戶購物車中。這里也有一個前提是:默認未登錄狀態也可以加購物車。
    這個未登錄狀態下加車,是不是說:比如一個用戶A未登錄,她選了一些商品加車了,之后另外一個用戶來用這個手機登錄了賬戶B,那么A加車的商品就加到了賬戶B下了。是這樣嗎?
    如果是這樣的話,未登錄狀態加車的商品綁定的是PC或APP嗎?
    我個人覺得,這個未登錄狀態加車的功能應該僅限于手機端吧?

    來自上海 回復
    1. 沒有局限于哪個端,至于實現方式我只能提供一個參考:pc端一般存在瀏覽器緩存,平臺每次會去檢查瀏覽器緩存是否有加車記錄,手機端一般是存在本地專屬文件夾里,檢查原理和pc端一致。

      來自北京 回復
    2. 感覺有風險

      來自上海 回復
    3. 這是普遍的實現方式,至于風險,就算被人知道未登陸前添加的購物車商品又有什么關系呢?

      來自北京 回復
    4. 我看了下淘寶和京東在這個細節上的做法:淘寶是加車前需要登錄才能加車;京東是像你說的一樣,用戶登錄后自動把登錄前加車的商品加到購物車
      兩種方式我覺得各有利弊,但是我個人還是比較傾向淘寶的做法
      所謂的風險就是你說的“被人知道未登陸前添加的購物車商品又有什么關系呢” 這個關系我覺得還是有的 比如我加了一些個人隱私的東西 然后被其他人掃描登錄了 就會看到我加車的商品

      來自上海 回復
    5. 這里是有很多機制可以防范你說的問題的,更多的你需要考慮的是為什么淘寶和京東的模式不一樣?(你可以從淘寶小店和京東自營的區別去考慮)

      來自北京 回復
    6. 你的意思是因為數據的原因嗎?
      淘寶要求加車前登錄是因為可以給入駐在淘寶平臺上的店鋪一定的用戶數據;京東自營是因為本身就是平臺,進入平臺就開始產生數據,是這個原因嗎?
      另外 你說的那些防范機制方便告知一下嗎?謝謝~

      來自上海 回復
    7. 有個問題,未登錄加車也需要扣減庫存嗎,我覺得不需要吧,跟登錄加車應該是2個邏輯

      來自浙江 回復
  9. 我認為活動和優惠券兩個信息可以合并為一個信息欄,系統自動計算出最優解(即最優惠)展示出來。

    回復
    1. 這顯然對用戶是很友好的,但是背后涉及到的后臺邏輯,可沒那么簡單哈~你可以想這樣一個問題看看能不能輕松解決【你的問題比我這個問題難度高幾何倍數】:假設A商品參加了甲乙丙三個活動,當用戶加車A時,你如何制定一個規則,自動給用戶選擇參加(甲乙丙)中的某個活動?另外想兩個問題:用戶領了優惠券,就一定要花出去么?對平臺來說用戶使用了優惠券是利好么?【所以建議設計成手動使用優惠券】

      來自北京 回復
    2. 嗯嗯,仔細思考確實存在問題,手動會更好一些。
      1.自動使用優惠券客戶甚至沒有感覺到平臺購物的優越性
      2.手動使用優惠券利用了價格歧視原理,能區分出對價格敏感的客戶,可以進行精準運營。

      回復