这篇文章可以看做是《移动出海立项笔记：垂直工具的集合化》的续集。
不过为了便于阐述，可能就不会分究竟是游戏还是工具了。
首先，先界定下什么不是集合型产品，这点很重要，免得写岔了。举例：比如微信，微信的聊天、支付、公众号、视频号等功能集合起来，不是我说的集合型产品，只是个 all in one。要不是苹果拦着，你写个微型操作系统都可以，但操作系统不是集合型产品。
那具体的集合型产品是什么，前一篇提到了 AI 伴侣，计算器可以集合化。这一类集合化有个特征，就是集合的成员，它们的基类（面向对象术语）是相同的。例如计算器集合，它的子集们再怎么变化，都是计算器；AI 伴侣，它们的子集再怎么变，那也是个伴侣。
如果是功能集合，那么开发者每次添加一个集合成员，要额外开发功能（代码级），如果是内容集合，那么大部分时候可以不需要加入新代码就可以添加成员。
最典型的例子还是游戏，假如开发了三个小游戏，是单独发布三个产品好，还是合成一个产品，作为集合发布好？这个就得看，是三合一有价值，还是分拆出售有价值。
可以用巧克力来做类比，假设有几款不同的巧克力。其中一款是纯巧克力，另一款是酒心巧克力，然后是草莓巧克力，榴莲巧克力和三五样不同水果风味的巧克力。那么问题来了，要是想把这些巧克力放进巧克力盒里出售，应该怎么分配这些巧克力？在这例子里，巧克力盒就是 app，巧克力可以类比功能。
这里给出的参考方案如下：
纯巧克力。单独盒装出售。
酒心巧克力。单独盒装出售。
水果巧克力。混合出售。
因为纯巧克力和酒心巧克力，都是大众认可的食物了，简单的讲就是“很多人好这一口”。而水果巧克力，却有些众口难调，面对众口难调，或者过于小众的需求，就把它们混合出售，这样就算某个味道不符合某类人口味，但是胜在品种多啊，用户有挑的空间，而且琳琅满目的丰富感以及挑选的趣味性，很大程度上削弱了部分品类不合口味的弱点。
类比到游戏里亦然，如我在《Block Blast 案例分析》中提到的 1010 玩法，这个玩法本身受众非常广，用户来玩游戏就是为了玩它的，那么做成集合型产品也不能说就不行，但是未必能起到正面效果，而且还影响了主力产品体验上的一致性和品牌价值。就好比用户就想买酒心巧克力，你拿着酒心巧克力和草莓巧克力一起卖，也不是说不行，但是收益毕竟不能形成叠 buff 效应。
那什么游戏类比“草莓巧克力”呢，就是那些玩法不算太出彩，但也勉强能玩一玩的游戏，可能有很少数人会沉迷，但是因为玩的人数太少，过于小众，或者留存太低，游戏时间太短等，总而言之就是单品收益过低，单独出售收益过小，而如果和别的产品混合起来，能起到琳琅满目叠 buff 效果，起到了氛围组和被选择的作用。参考游戏玩法案例有：数字华容道。
到这里，什么时候可以集合化，什么时候不可以，思路就比较清晰了。可以成为集合的功能，必然是因为单打独斗收益太小，但同时胜在开发成本也很小，至于为什么单打独斗收益过小，理由要具体分析。而这些集合成员里，也有可能孵化挖掘出“超级个体”，但是对于“造物主”开发者来说，这不是坏事情，完全可以把孵化出来的超级个体为它单独出一个 App，并为它增加不太方便在集合里做的专属功能。
这样子，开发者可以做出两个以上的产品来，一个是集合产品，一个是被孵化出来的独立个体产品，而不用担心什么 4.3 问题。
在 AI 伴侣领域，最近有款 AI 类产品很值得关注，参看下图。
很醒目的 Billions 。可谓是超级集合类产品了。后面可能会针对性的分析下这个产品，并且会再写一篇集合型产品可以针对“集合”这一设定做出单一功能做不到的增益价值来。
完。
附：
移动开发者联盟入群指引