0.引言
春节看了一系列国内产品系列的书，发现市面上此类书籍大多以“生造理论+案例堆砌”为主，读起来味如嚼蜡，收获寥寥。难怪和同事说起我最近读的书时候常常换来“读的书太理论化，读了容易忘记，难以指导实际工作”的过来人忠告。一度我还认为看此类书籍倒不如选择阅读一些有价值的公众号文章加上一些社会学等杂书（此处提名张维迎《博弈与社会》）来的有收获。
直到我遇到了出版日期也不算很新的《淘宝产品十年事》。首先声明并非因为他是讲淘宝这个巨头产品我就先入为主的认为这值得一读。相反，因为作者上一本《人人是产品经理》的缘故，我反而降低了期待。但我发现，此书描述的淘宝发展进程中遇到的部分问题与我在应用宝实习期间遇到的问题，竟惊人的相似。作者的经验总结和相关思考也带给我对于平台型产品的很大启发。
先贴上本书读书笔记，再来谈为我从淘宝发展历程和自己在应用宝实习经历中看到了什么。（为什么简书没法支持更大更清晰的图。。。）
1. 海量item引发的分类问题
淘宝上的商品需要管理，管理的核心是分类，分类是为了更好滴匹配需求关系。但随着商品量暴增，早期类目树越来越越繁杂，类目体系出现交叉和重合们。
对于平台小二而言，这种分类体系难以支撑日常管理，体现在
- 一个商品既属于这个类目也属于这个类目，类目越来越多,类目之间却无明显维度划分。（例如女装、短袖、学院派都是类目）
- 难以满足频繁变动的导购需求（例如夏天需要调整超短裙，缩短导航层级以便更容易被用户看到，冬天又可能换成了羽绒服类似需求）
对于卖家而言，这种分类体系因为导购需求带来的变更增加了反复的工作成本
淘宝先后做了以下事情来解决这件事
- 引入了“属性”的概念；对于一个商品，它从属于唯一一个类目，但可以有多种属性（属性也有自己的属性树）。属性挂在叶子类目下面，相当于从属性树中取出一些属性“小叶子”挂在类目树上的叶子类目下来描述商品。类目层次分明，又能多维度描述商品。
- 前后台类目拆分；卖家通过后台类目发布商品，卖家通过前台类目根据导购需求展示商品。这样即使导购需求频繁变更，也不会影响到卖家发布商品的后台类目体系。
诶？这跟应用宝什么关系？
因为做过一些知识图谱-类目梳理的基础工作工作，有段时间天天跟标签体系打交道。工作中我认为应用宝同样面临APP分类体系繁杂、组织不灵活的问题。参考淘宝管理商品的做法，我认为可以这么做：
增加场景作为描述APP新属性；一个APP只属于当前一个类目，但是可挂载多个场景属性。场景基于目前的标签体系聚合而成，例如导航（出行类）天气（生活工具类）翻译（语言类）保险（理财类）加上原来就有的旅行类可以聚合成“出国游”场景。这样一个APP除了原属类目，还会有更多关联场景。事实上我们在做强感知专区项目的时候已经有用过类似“跨类目组织场景”的方法，只是没有沿着路径深入系统化地去整理场景而已
有了场景属性好处有二
- 一是可以配合个性化推荐强需求项目，铺开做基于场景的推荐
- 二是增加更多维度描述APP，增加APP之间的关联性，为以后平台打造的人工智能感知能力做前置准备（某次开会GM大鹏也提到了与今日头条相比，当前的标签体系颗粒度很粗，难以支撑机器更好的学习理解）
2. 淘宝搜索排名规则与应用宝推荐策略
此处让我印象深刻的不是具体的产品策略，而是作为一个商业化平台，处处体现需要拿捏平衡的产品哲学，主要有以下几点
短平快与系统化
跟所有平台一样，总是会有些突发性运营需求；此时要么采取短平快做法，遇到一个做一个，这样见效快,风险低，平台大环境也基本不会受很大影响；另外一种做法是跳出需求本身，提炼该类需求共性问题，抽象成平台性的基础需求，此种做法需往往牵扯到多条业务线，开发工期长，把控不好则对平台大环境的影响具有一定的不确定性。
应用宝也遇到过类似的选择，年末的时候往往因为活动运营需求，一些APP需要“聚量”来提高曝光，采用短平快的做法的话只需要把那些APP手工加入多个场景的召回池中，但是后来把这个做成了一套平台能力项目，可对单个APP做加权处理，可在多个位置出现该APP要数据还是要多样性
淘宝搜索排名有一个主要指标是"人气排序“，因此商家们都热衷于打造爆款来提高排名，不太关注爆款本身质量；羊群效应下的用户门对此也很买账；这就造成了头部商家拿走了大部分流量，中长尾商家活的很不好。但此时的转化率数据都是很好看的，头部商家越集中的领域，数据差异越大，理论上作为平台方应该是很喜欢这种高转化平台生态；同样的事情还体现在应用宝的某些推荐策略上，反反复复推荐给用户一些很头部的应用，数据表现也很漂亮。数据导向来说这样没问题，但长期而言会造成中长尾商家（APP）的消亡，会造成以后大家搜出来的东西将趋于千篇一律，平台多样性失衡，无法支撑可持续发展把蛋糕做大
3.平台型产品经理新认识
以前一直对平台型产品经理的认识停留在“这是一个需要很懂技术的产品岗”；然而经过读书加上实践后，我发现平台型产品经理的工作是"满足共性需求，然后造出供平台使用的“轮子”"，最大的能力要求不在于技术，而是以下2点特质：
- 业务大局观。对于功能点设计、产品策略不能仅考虑当前主体，而是要尽可能同时考虑对涉及业务线的所有对象的影响
- 问题拆解-模块抽象能力，为很多时候做的是基础平台产品，很与各条业务线都有交集，往往需从逻辑上解耦原有业务流程，将其拆成独立单位以便于灵活组合做成模块化工具。
4.其他引申
- 为什么要做个性化推荐？
个性化推荐这项技术兴起的背景就是信息过载，目的是为了海量信息下，更好地匹配需求关系；
基于不同业务背景，个性化推荐的侧重点不太一样。
资讯新闻类、视频类的个性化推荐更关注时效性，需要将最新的内容第一时间呈现在用户面前，尽管有时候会出现”原料不足“的情况——实在是没有足够多新”新闻“
图书、音乐等兴趣导向的更关注用户显性反馈（指用户明确表示对物品喜好的行为，如：评分、喜欢与厌恶），希望能通过用户的主动选择来让推荐越来越精确，提升用户体验；
而淘宝、应用宝这类综合平台的个性化推荐更是结果导向，单个用户消费金额或者下载多，就可以认为个性化推荐达到了目的；
但不是每个平台都需要做个个性化推荐，item数目少的情况下平台做好分类管理就可以满足大部分需求了；只有在真正达到“海量”，用户获取所需的成本越来越高，个性化推荐才能发挥他的价值
- 那到底什么才是好的个性化推荐？
做个性化推荐的团队，总是希望自己的用户数据源越来越广，算法越来越强大，用户的选择成本越来越低，甚至不用选，我们推荐给用户的就是最合适的...但这样，对于用户而言，他就永远待在自己的舒适区了，不会接触到新的东西，而对于整个系统，因为没有“买家选择”这种行为，整个系统就停止了进化接近死亡了；听起来像是一个悖论：“好的推荐系统让人不做选择，人不做选择无法做出一个好的系统”； - “把一个复杂问题拆分成三个子问题，并给出三个解决方案，三个方案之间各有利弊，互相补充”；这是旺旺在做anti-spam时候的思路，居然与我们做个性化项目的思路几乎一模一样。
读此书的时候各种感慨，提笔开始写收集更多资料的过程中却发现自己作为实习生的观察只是管中窥豹；无论是应用宝还是淘宝已经做的工作其实做的比我观察到的多得多，也许我刚刚想到的，别人早就做了；也许两个产品形态差异导致经验根本难以借用；但我想，淘宝和应用宝同样是拥有海量item的平台，其商业的本质是未曾改变的：平台通过满足两端需求，帮助提高效率来创造价值。
