【案例分析】你真的了解購物車需求嗎？

01-23

導讀：

上篇文章有一道練習案例，許多朋友的回答都有一點偏差，伴生性需求似乎並不是那麼容易掌握，這篇文章，針對這個練習案例以及大家的留言，做個分析

練習案例

淘寶app中的購物車模塊，以下哪些功能屬於伴生需求？
1、商品編輯；
2、商品失效管理
3、批量支付；

4、促銷引導或提示
5、湊單；
6、拆單；
7、個性化推薦。

背景分析

我們已經知道伴生性需求的第一特徵：對某功能有極強的依賴性質，無法單獨存在，是作為某功能模塊的一部分而存在。

在這個練習案例里，購物車便是主體功能模塊，他服務的目的在於將人們想要購買的物品放到一起，最終實現支付場景的整合。

購物車的原型來自於在現實超市商場人們的購物習慣，我們往往在商場里會購買許多商品，每選擇一個商品就進行一次支付，顯得特別繁瑣，機緣巧合的情況下，一位商人在1937年發明了購物車，隨後在1994年，這個購物車被做成了互聯網某產品的logo,這款互聯網產品便是」亞馬遜」

關於購物車的故事可以看這篇文章：原來他是購物車的發明者 - 推酷
這篇文章會讓我們知道購物車是作為解決什麼問題而被設計出來的。

實際上，購物車是作為購物籃的升級產品被設計出來的，其目的在與通過增加購物籃的裝載空間，減少人們的體力負擔，conn個人增加人們購買商品的數量。這和我們互聯網的購物車有本質的區別。

互聯網的裝載空間幾乎無限，也幾乎沒有體力負擔，我們現在所使用的購物車，第一階段的目的反而是作為「購物籃」而被設計出來的，很遺憾，沒能找到購物籃的設計背景，我們不妨大膽的設想一下。

在有購物籃之前，人們去超市買商品，一次性只能攜帶少量商品，是我們雙手所能掌握的商品，這會導致面對較多購物訴求時，會形成非常高的往返成本，會非常的繁瑣，以至於產生排斥心理，從而降低人們的購物慾望。

而購物籃的設計，解決的是人們的裝載問題，將原本的雙手空間擴大為一個籃子的空間，讓我們能夠裝下更多的希望購買的商品。

案例分析

我們在案例里提到了7個選項，分別是商品編輯，商品失效管理，批量支付，促銷引導或提示，湊單，拆單，個性化推薦

我一定還沒有告訴你，每一個功能都有一個受眾的對象，即該功能操作的目標是什麼，如果站在功能的受眾角度去進行分析，很容易將這7個功能分成兩類，其一是對購物車內的商品進行的操作，其二是對購物車外的商品進行操作。

商品編輯，商品失效管理，批量支付，拆單，這四個功能都是針對已經加入購物車內的商品進行操作。

而促銷引導或提示，湊單，個性化推薦這三個功能則是針對購物車外的商品，希望人們更多的去購買商品。

這就像超市隨處可見的小廣告一樣，不論你購買的東西多或者少，作為超市的經營者，都希望你能更多的購買商品，再多買一點。

儘管，購物車的設計初衷是為了讓人們更多的購物，但他的切入方式卻和廣告不同，購物車提高商品銷量的核心價值在與減少人們購物的壓力，而不是推薦購物。

作為幫助人們購物的一款工具而言，更方便，更快捷，更高效率的購物是購物車的使命。 購物車本身不會參與商品推薦的任務，他所提供的是一種購物方式，增加人們購物的愉悅感，推薦商品則是由超市的宣傳單來完成。

當然，我們完全可以將宣傳單放在購物車內，這是一種組合使用的方法，但並不是說，我們一定要將宣傳單放到購物車裡。

這表示購物車本身的受眾對象是針對已確定購買的商品，即購物車內的商品，而非推薦性質的購物，

在這一點上，我們便可以將促銷引導，湊單，個性化推薦排除了。

現在，作為購物車的伴生性需求，我們可以選擇的選項還剩下商品編輯，商品失效管理，批量支付，拆單。

深入分析

剩下的四個功能，我們能夠分析的內容還有許多，這裡以批量支付為例重點來分析一下，這個功能是比較特殊的一個功能。

在這個案例里，購物車是指淘寶的購物車，因此我們需要正確的來辨識這個批量支付的含義，根據淘寶app的實現方法而言，這裡的批量支付是指批量選擇進行支付。

他並不是說我們可以一次性支付購物車內的所有商品，而是我們可以一次性在購物車內選擇支付多件商品。

在某些電商產品里，購物車的批量支付是不能選擇的，我們會將商品選擇好，最終不買的，會將他移除購物車，最終實現批量支付。

顯然，淘寶的眼睛裡，購物車除了裝載人們想要購買的商品，也可以作為「收藏欄」來使用。

我們在分析伴生性需求時，除了功能的受眾對象固定以外，也可以判斷該功能被取消的情況下，原有功能模塊是否仍然可以正常使用。

我們將淘寶的批量支付里，屬於「收藏欄」這部分的概念剔除，只保留對整個購物車的支付操作，這樣的購物車仍然是可以被使用的。

實際上不只是批量支付，像是商品編輯，失效管理，拆單，也都屬於缺失後，會影響功能的使用，但並不會導致功能無法使用這樣的範疇。

淘寶的核心價值在於讓人們足不出戶便能購買各種商品，他提供給用戶的最大吸引力在於豐富的商品以及較低的價格，而購物車的功能完善，並不會讓用戶感到驚喜，但若購物車的功能存在缺失，卻會讓用戶感到不是那麼愉快甚至會感覺到過於繁瑣了。

實際上，伴生性需求往往是承擔了大部分抱怨的需求，看上去每個需求都能提升用戶體驗，但卻沒有辦法為產品帶來直接的價值，當購物車的需求與商品本身的需求產生衝突時，我們便會優先考慮去更多的體現商品，讓用戶對商品產生更大的購買慾望，而不是去完善購物車的功能。

這便是我在上篇文章提到的，伴生性需求的另一個特色，他是可以被捨棄的 。

我們可以想像一下，假如淘寶購物車的商品不能編輯，也沒有失效的商品管理，也不能拆單，這所有的功能都需要我們反覆的取消商品，選擇商品來完成，我們還會使用淘寶嗎？

實際上，我們還是會使用淘寶，原因很簡單，我們並不是為了使用購物車的商品管理功能而去購物，我們是為了購物才使用購物車的商品管理功能的。

這次的練習案例，正確的答案是1236，也就是說在淘寶的購物車模塊里，商品編輯，失效商品管理，批量支付，拆單，都是屬於購物車的伴生性需求。

公眾號留言點評

「@」曾慧娟：

127是伴生性需求

點評：

關於第7點，不妨思考一下，離開了購物車，我們也可以做商品的個性化推薦，實際上各大電商產品都在許多地方使用了個性化推薦，最常見的使用方式在於首頁和搜索，由此可見，第7個選項，個性化推薦對於購物車來講，只是一個入口，而不是由購物車伴生的需求。（他也可能是一個響應性需求，市場同事提出來的希望在購物車裡植入的模塊）

「@」悟道人生：

4567是伴生需求，購物車的主要功能是實現貨物存放支付，湊單，拆單，推薦和暗示性廣告都是在購物車必須功能編輯取消和支付實現後提高成交量的，

點評：

這個地方是將功能的必要性和伴生性混淆了概念，伴生性是指需求的一種性質，並非判斷需求是否為必要需求，實際上伴生性需求可以是必須具備的，也可以是補充的。

此處案例里，4，5，7 雖然不是必須存在的功能，但也同樣不需要依附於購物車這個功能主體來實現。而1236，儘管是必須具備的功能，但實際上缺少這部分功能並不會讓整個購物體系崩潰，最大的可能性是會減少人們購物的愉悅感，讓我們感到繁瑣。

「@」spring:

購物車核心是用於批量加入商品，結算。商品的編輯我理解是商品添加和刪除所以2到7都是半生性。

點評

你提到了商品編輯，但在答案里卻給出了是失效商品管理和個性化推薦，實際上商品編輯和失效管理都是屬於購物車的伴生性需求，而個性化推薦卻不是。

「@高原」24567都是伴生性需求，購物車的核心功能是編輯商品、支付，其他如失效品管理、引導、湊單、拆單都是伴生性需求。

點評

伴生性需求除了不是核心需求以外，還要和核心功能有明顯的依附關係，是無法離開核心而單獨存在的，站在這個角度來思考，就會排除第457選項

同時，核心需求與必須存在的需求還有差別，必須存在的需求並不是要最先做的，而核心需求是要最先做的，同時，必須存在的需求也可能是伴生性需求，其表現形式，我們可以認為這部分需求在一些場景里極容易被延期，被取消，比如商品編輯。

總結

在大家的回答里，有很明顯的傾向，我們很容易認為商品編輯和批量支付是購物車必須存在的需求，實際上並不是這樣的

對於商品編輯來講，我們在淘寶的使用頻率大概不到1% ，實際上並不是所有的商品我們都需要去編輯數量，這只是少部分商品帶來的需求。

而對於批量選擇支付來講，實際情況是在於我們將購物車的使用方法與收藏欄的使用方法混淆了，這為我們的需求分析帶來了困惑，我想，我們的購物車裡一定有一些商品放進去了，卻不再理會了。

同時，並不是所有電商類產品都需要購物車，正如購物車的存在使命，是為了方便人們一次性購買多件商品，更適合於商品豐富的超市，商場類電商，我們一定要更客觀的辨別出用戶一次性購買多件商品的需求是高頻率還是低頻率。

禮品電商在初期並不需要購物車，而是應該用訂單的思路來做，畢竟許多時候的禮物是一件一件購買的，而非一次性買許多禮物

大型物品，奢侈品電商在初期是不需要做商品編輯的，在此類電商里，針對單個商品購買兩件以上的概率較低，決定購買後再修改商品數量的概率則更低一些。

現在，如果你正在做電商產品或者正準備從事電商產品，相信你對購物車以及購物車的功能已經有了更深刻的理解了。切忌，無須因為功能必須存在，就將他定義為更高級的需求，很多必須存在的需求，並不一定很緊急，很多伴生性的附屬需求，其實都是必須存在的。

我想大家現在對於伴生性需求也有了更深一點的認識了。

下一篇文章，我仍然會繼續寫一下伴生性需求，大家有合適的練習案例，不妨留言給我，

感謝大家的閱讀。