决定转行做电商产品有一段时间了，之前一直在顺着兴趣学Python，这才又切回来。趁着双十一买了一本《淘宝产品十年事》，下载了《淘宝技术这十年》。最近抽空读了两遍产品事，其实没准备看两遍，第一遍看完觉得兴奋，于是又读了一遍，品味其中细节。
将主要内容整理出来，算是进一步巩固吧。
导购
淘宝或者说电商，其实就是流量分发的平台，类似线下的商场。用户购物时，一般有这么几种心态：
- 有明确目标，比如买一台iPhone X；
- 有模糊目标，比如买一件衣服，或者再明确一点，买一条裤子；
- 没有明确目标，就是想逛逛。
回头再看看首页，有明确目标的用户使用搜索，有模糊目标的用户使用分类，没有明确目标的用户可以看看各类促销信息（当然，实际用户使用的过程肯定不会这么绝对）。
搜索
搜索对于淘宝买家而言，属于导购工具之一，因而它的主要目的是帮助用户找到满意的商品。对于卖家而言，则是流量分配的工具。
与通用搜索区别：
1、淘宝面对的是结构化数据，因而搜索结果可以会出现导航（即类目属性）。
2、多维度排序
3、突出图片
4、商品信息和筛选，例如按销量、价格排序等
主要讲讲搜索结果的排序。书中介绍了四种排序方式：下架时间、橱窗推荐、人气排序和阿基米德。
下架时间：按下架时间倒序排列，淘宝初期的排序方式，简单有效，做到对每个卖家都公平。后来面临了卖家的作弊，比如卖家发布一万件商品；
橱窗推荐：橱窗推荐商品由卖家设置，排序时给予更高的权重。橱窗推荐模仿的线下店铺的橱窗展示，放在橱窗中的肯定是商家认为的优质商品。这在初期数据量小且技术做不到的情况下，是一种有效将优商品优先排序的方式。
人气排序：橱窗推荐是借卖家之手挑选优质商品，那么人气排序就是借买家之手了。人气排序存在两个问题：一方面导致了马太效应，淘宝生态失衡；另一方面由于买家一般翻页不会超过三页，因此会导致商品覆盖率低。
阿基米德：阿基米德是一个综合各方面因素的排序方式，除了上面提到的方式，还会综合商品质量以及卖家服务质量考量。
随着淘宝用户量、商品数量的快速发展，精细化与个性化成为了优化的方向。精细化使得搜索结果更准确，而个性化则使得搜索结果千人千面。
搜索还有两个点提一下：合并同款与款式打散、合并卖家与卖家打散。
可以看出来，淘宝搜索背后的逻辑：
- 公平与效率、卖家与卖家的平衡；
- 大卖家和中小卖家的平衡；
- 短期和长期利益的平衡；
- 手握卖家的生杀大权，解释下，搜索对于卖家是一种经营环境，经营环境的改变，必然会引起利益的再分配。
分类
这个分类想想都纠结，商品有非常多的属性，比如材质、品牌、价格等。而淘宝最开始的分类是类目树，当商品越来越多时，类目树会越来越深，导致不知道该怎么分类了，因为商品的属性并没有明确的树结构，好像谁做谁的子类都可以。比如，男装、T恤、耐克，按男装->T恤->耐克可以，按按耐克->T恤->男装也可以。越来越深的类目树会导致用户的购物路径变长，流失率也就增高了。
淘宝的产品经理通过类目+属性来解决这个棘手的问题。
比如图中的类目是男装->T恤，那么在这个类目下，可以挂品牌、版型、袖长等很多属性，这样类目树路径变短，用户购物路径也随之变短。
由于运营的需要，类目属性经常要变，从而导致商家必须对商品属性进行变更，否则强制下架。如果卖家的商品数量较多，一次类目属性的变更，他就得花很长时间去调整，而淘宝小二变更类目属性的频率又比较高，可想而知，卖家要疯了。
解决的方案是这样，做两套类目属性，前后台各一套，这样只需要将前台类目属性与后台关联起来就可以了，小二随便调整，卖家是不受影响的。这其实也是从线下大型超市学来的，超市卖场物品的陈列跟仓库是不同的，但却运行的井井有条。
属性可以分为三类：
- 可枚举，例如性别；
- 可枚举，可输入，例如品牌；
- 不可枚举，可输入，例如重量。
一旦允许用户输入，那么不规范的数据一定会随之而来。比如，会出现Adidas，阿迪达斯等等。另一个问题是，不同类目下，相同属性的ID却不同，举个栗子就是，男装->耐克和女装->耐克没有关系，如果统计属性为耐克的商品数量，就得把这两个耐克的商品加起来。
这个问题，淘宝通过使用专门的团队管理类目属性，最大程度上避免不规范的数据。
SPU、商品、SKU
SPU：品牌+货号确定唯一产品，例如苹果+A1530确定是iPhone5s；
商品：SPU+商家，例如100个商家都在出售iPhone5s，那么就有100个商品；
SKU：标准库存单位，就是放在仓库里的最小可售卖单元，例如深空灰 16G iPhone5s。
何时减库存
拍下减库存
会面临拍了不买的问题，甚至面对『恶拍』。应对办法是增加库存保留时间、限购以及禁止恶意帐号购买。
付款减库存
会面临超卖的问题。应对办法是设置安全库存、尽可能晚的验证是否有库存还有就是在页面上增加提示不保证库存有的文案。
感悟
- 系统不是设计出来的，是根据业务发展迭代出来的，产品超前设计反而有可能失败；
- 平台即生态，大的平台做需求不是简单的做A或做B，而是平衡与妥协，重要的是维持生态的平衡；
- 多向线下借鉴学习；
- 不是所有问题都能够、需要通过技术手段解决。