App Store 关键词自相残杀：自家两个 App 抢同一个词

有个客户拿着一张表来问我们：为什么我们家的两个 App，搜同一个词的时候，一个排前面一个排后面，能不能都排上去。

我看完那张表，先问了一句：这两个 App 是给同一批人用的吗。他说是，一个是主 App，一个是当初为了试水做的精简版。

那这个问题就变了。真正的答案是：它们排不到一起，不是技术问题，是它们本来就在争同一个位置。

先说结论

关键词自相残杀这件事，分两种，混淆了会做错决定。

第一种是自家多个 App 抢同一个词。第二种是同一个 App 的几个字段和几种语言版本在抢同一个词。前者通常意味着产品线没想清楚，后者通常意味着字符预算被浪费了。

两种的解法完全不同：前者要分流，后者要合并。

我见过最多的情况是：团队把第二种当成第一种去处理，辛辛苦苦做了两个 App 的差异化定位，回头发现真正丢的量是主 App 内部两个语言版本互相打架。

自家 App 互抢：商店不会因为你是一家公司就手下留情

这是最容易被忽略的一点。商店的排序逻辑不认识"同一家公司"这个概念，它只认这个 App 和这个词的匹配程度、以及这个 App 的受欢迎程度。

所以两个自家 App 抢同一个词的时候，它们的关系跟两个竞品抢同一个词没有任何区别。你输赢都是自己输赢，但总量不会因为你多上了一个 App 就翻倍——因为搜索结果的展示位置是有限的，用户往下划的耐心更有限。

更麻烦的是内部资源分配。投放预算分给两个 App，评论运营分给两个 App，更新节奏分给两个 App。每一个单独看都不够用，合起来看是一个都做不好。

除非你在做的是有意的覆盖——这个下一节说。

内耗比外耗更难发现

第二种情况更隐蔽，因为它不出现在报表上。

同一个 App 的中文版和英文版，如果都用了同一个英文长尾词，在某些市场的搜索结果里它们会互相挤。你看到的是"这个词我们有两个位置，其中一个位置掉了"，很容易归因成算法波动。实际是自家兄弟把它挤下去的。

还有一种：同一个 App 的标题、副标题、关键词字段，为了保险把核心词在三个地方都写了一遍。这在字符上是三次支出，在索引上只有一次收益——因为关联是二值的，写三次和写一次在"是否关联"上没有区别。

这种内耗的特点是：不报错、不掉量、就是效率低。所以它能活很久。

语种版本互抢，是最容易被当成 bug 的

单独说这个，因为它最像技术故障，实际是结构问题。

同一个 App 上多个语种版本，本来是为了覆盖不同语言的用户。但语言和地区不是一一对应的：一个英文版可能在好几个英语市场都上架，一个中文版也可能同时服务几个地区。当两个版本在同一个市场都能被搜到，而它们的字段又用了同一批英文词，抢就发生了。

表现是什么样的？你在后台看到一个词的曝光在涨，但安装没涨；或者一个版本的位置掉了，另一个版本的位置上去了，加起来不变。团队会怀疑是不是商店在调权重、是不是审核出了问题。其实只是自家两个版本换了个位置坐。

更难判的是：有些市场的用户会用非母语搜索。这时候英文版和本地语言版同时出现在结果里，是合理的，也是应该的——但前提是两者的字段要各自服务各自的搜索习惯，而不是把同一批词复制两遍。

处理方式跟前面一样：先确认这两个版本是不是真的在服务两批不同的人，是就分流词表，不是就该考虑合并成一个版本、用本地化文案去覆盖。

什么情况下"多马甲"其实是策略

这里得说句公道话。多 App 覆盖不是原罪，有几种情况是成立的。

一种是人群差异大到主 App 装不下。面向专业人士的版本和面向新手的版本，功能深度、界面复杂度、收费模式都不一样，硬塞进一个 App 会两边都不满意。

一种是场景差异大到需要不同的第一印象。比如一个偏工具、一个偏内容社区，用户在搜不同词的时候期待看到的东西不一样。

判断标准不是"我能不能做第二个 App"，而是：这两个 App 各自有没有一个词，是只有它能拿下的。如果两个 App 的目标词表高度重叠，那第二个 App 的意义就要打问号。

还有一层容易被忽略：分流不等于让两个 App 一模一样地活着。有些团队做了第二个 App，功能砍了一半，界面换了个皮，定位其实还是同一个。这种"多马甲"不叫策略，叫同一个产品做两遍，成本翻倍、上限不变。真正的多马甲，是每个 App 都有一个自己的入口理由——用户不是被迫选它，是主动想要它。

怎么判断是不是在自相残杀

三个信号，从粗到细。

第一个：把你家所有 App 的目标词表并排放，看重叠率。重叠的部分如果集中在几个核心大词上，基本就是在互踩。

第二个：搜这个词，看结果页里自家 App 出现了几次。出现两次且位置都不靠前，那不是双保险，是双内耗。

第三个：看两个 App 的用户重合度。如果同一个用户很可能两个都装，那它们在你的产品矩阵里就是重复的。

这三个信号里，第三个最有说服力，但也最难拿数据。前两个用公开的搜索结果就能粗判。

处理办法不是删词，是分流

发现重叠之后，最容易犯的错是让两个 App 各删掉一半的词。这是把两个都做弱，不是把两个都做强。

正确的做法是分流：给每个 App 划一个它最适合的搜索意图区间，然后让两边都不越界。

比如主 App 拿品类大词和品牌词，精简版拿"轻量""极简""不占内存"这类修饰型长尾词。这两组词背后的用户期待是不同的，搜前者的人想要功能全，搜后者的人想要不打扰。

分流之后有个副作用是好的：两个 App 的定位都被逼清楚了。原来模糊是因为可以靠重叠的词互相兜底，现在兜底没了，只能自己想清楚。

母品牌词的特殊情况

有一种重叠是合理的：品牌词。

用户搜你的品牌名，看到你所有 App 是正常的，甚至是应该的。这时候不存在自相残杀，因为用户已经知道他要找的是你，他在做选择而不是在发现。

但这里有个前提：品牌本身得是一个会被主动搜索的词。如果品牌还没建立认知，那品牌词在字段里占的位置就是纯消耗。

顺带说一句，品牌词的搜索结果里出现多个自家 App，用户体验上是可以接受的，只要每个 App 的介绍能让人一眼分清它是干什么的。分不清才是问题。

什么时候这件事根本不用管

如果你的 App 数量就是一个，那这篇文章的前半部分跟你无关，只需要看"内耗"那两节。

如果你的品类还没做起来，搜索量本身很小，那讨论抢词是没有意义的。这时候该做的是把品类词做起来，不是分配。

如果你的两个 App 面向完全不同的市场，词表天然不重叠，那也不用管。

判断要不要处理这件事的标准很简单：重叠的词带来的安装量占比有多大。占比小就别花时间，占比大就必须处理——因为这是唯一一种"努力方向正确但总量不变"的浪费。

最后提醒一句：这件事没有一次性做完的说法。你每上一个新 App、每开一个新语种，重叠就重新产生一次。把它写进上架前的检查清单，比事后救火便宜得多。

可以先做这几件事

1. 把自家所有 App 的目标词表拉出来并排放，标出重叠的部分。这一步不用任何工具，一张表就够。 2. 对重叠的每个词，搜一次，看结果页里自家 App 出现了几次、分别在第几位。 3. 给每个 App 写一句"只有它能拿下的词是哪几个"。写不出来，说明这个 App 的存在理由还没想清楚。 4. 分流之后，把两边删掉的词记下来，一个月后看这些词的曝光去了哪里。如果总量没掉，说明原来的重叠本来就是浪费。