伴生性需求之案例分析.docVIP

　　伴生性需求之案例分析 上篇文章有一道练习案例，许多朋友的回答都有一点偏差，伴生性需求似乎并不是那么容易掌握。这篇文章将针对这个练习案例以及大家的留言做个分析。 练习案例 淘宝app中的购物车模块，以下哪些功能属于伴生需求？ 商品编辑 商品失效管理 批量支付 促销引导或提示 凑单 拆单 个性化推荐 背景分析 我们已经知道伴生性需求的第一特征：对某功能有极强的依赖性质，无法单独存在，是作为某功能模块的一部分而存在。 在这个 练习案例里，购物车便是主体功能模块，他服务的目的在于将人们想要购买的物品放到一起，最终实现支付场景的整合。 购物车的原型来自于在现实超市商场人们的购物习惯，我们往往在商场里会购买许多商品，每选择一个商品就进行一次支付，显得特别繁琐。机缘巧合的情况下，一位商人在1937年发明了购物车，随后在1994年，这个购物车被做成了互联网某产品的logo，这款互联网产品便是”亚马逊”。 实际上，购物车是作为购物篮的升级产品被设计出来的， 其目的在与通过增加购物篮的装载空间，减少人们的体力负担，conn个人增加人们购买商品的数量。这和我们互联网的购物车有本质的区别。 互联网的装载空间几乎无限，也几乎没有体力负担，我们现在所使用的购物车，第一阶段的目的反而是作为“购物篮”而被设计出来的，很遗憾，没能找到购物篮的设计背景，我们不妨大胆的设想一下。 在有购物篮之前， 人们去超市买商品，一次性只能携带少量商品，是我们双手所能掌握的商品，这会导致面对较多购物诉求时，会形成非常高的往返成本，会非常的繁琐，以至于产生排斥心理，从而降低人们的购物欲望。 而购物篮的设计，解决的是人们的装载问题，将原本的双手空间扩大为一个篮子的空间，让我们能够装下更多的希望购买的商品。 案例分析 我们在案例里提到了7个选项，分别是商品编辑，商品失效管理，批量支付，促销引导或提示，凑单，拆单，个性化推荐 我一定还没有告诉你，每一个功能都有一个受众的对象，即该功能操作的目标是什么，如果站在功能的受众角度去进行分析，很容易将这7个功能分成两类，其一是对购物车内的商品进行的操作，其二是对购物车外的商品进行操作。 商品编辑，商品失效管理，批量支付，拆单，这四个功能都是针对已经加入购物车内的商品进行操作。 而促销引导或提示，凑单，个性化推荐这三个功能则是针对 购物车外的商品，希望人们更多的去购买商品。 这就像超市随处可见的小广告一样， 不论你购买的东西多或者少，作为超市的经营者，都希望你能更多的购买商品，再多买一点。 尽管，购物车的设计初衷是为了让人们更多的购物，但他的切入方式却和广告不同，购物车提高商品销量的核心价值在与减少人们购物的压力，而不是推荐购物。 作为帮助人们购物的一款工具而言，更方便，更快捷，更高效率的购物是购物车的使命。 购物车本身不会参与商品推荐的任务，他所提供的是一种购物方式，增加人们购物的愉悦感，推荐商品则是由超市的宣传单来完成。 当然，我们完全可以将宣传单放在购物车内，这是一种组合使用的方法，但并不是说，我们一定要将宣传单放到购物车里。 这表示购物车本身的受众对象是针对已确定购买的商品，即购物车内的商品，而非推荐性质的购物， 在这一点上，我们便可以将 促销引导，凑单，个性化推荐排除了。 现在，作为购物车的伴生性需求，我们可以选择的选项还剩下 商品编辑，商品失效管理，批量支付，拆单。 深入分析 剩下的四个功能，我们能够分析的内容还有许多，这里以批量支付为例重点来分析一下，这个功能是比较特殊的一个功能。 在这个案例里，购物车是指淘宝的购物车，因此我们需要正确的来辨识这个批量支付的含义，根据淘宝app的实现方法而言，这里的批量支付是指批量选择进行支付。 他并不是说我们可以一次性支付购物车内的所有商品，而是我们可以一次性在购物车内选择支付多件商品。 在某些电商产品里， 购物车的批量支付是不能选择的，我们会将商品选择好，最终不买的，会将他移除购物车，最终实现批量支付。 显然，淘宝的眼睛里，购物车除了装载人们想要购买的商品，也可以作为“收藏栏”来使用。 我们在分析伴生性需求时，除了功能的受众对象固定以外，也可以判断该功能被取消的情况下，原有功能模块是否仍然可以正常使用。 我们将淘宝的批量支付里，属于“收藏栏”这部分的概念剔除，只保留对整个购物车的支付操作，这样的购物车仍然是可以被使用的。 实际上不只是批量支付，像是商品编辑，失效管理，拆单，也都属于缺失后，会影响功能的使用，但并不会导致功能无法使用这样的范畴。 淘宝的核心价值在于让人们足不出户便能购买各种商品，他提供给用户的最大吸引力在于丰富的商品以及较低的价格，而购物车的功能完善，并不会让用户感到惊喜，但若购物车的功能存在缺失， 却会让用户感到不是那么愉快甚至会感觉到过于繁琐了。 实际上，伴生性需求往往是承