马甲包被识别？元数据重命名技巧让Google认不出你

说起马甲包这个事，我们团队真的是一把血泪史。2024年初的时候，我们同时运营着12款马甲包，都是同一款消除游戏的换皮版本，上线第一个月数据还不错，第二个月开始陆续被识别。到第三个月，12个包只剩2个还在榜上，其他10个全部被 Google 标记为"关联应用"，轻则合并下架，重则连带主包一起被处理。

那段时间我每天早上一睁眼就是看 Google Play Console 的后台，看今天又少了几个包。被识别的那几个包，共同特点是：icon 风格差不多、描述差不多、甚至游戏内购的价格都一样。Google 的识别系统越来越聪明了，它不只是看你的包体内容，还会分析你的商店信息、开发者账号信息、甚至你用的服务器 IP。

后来我们花了三个月时间研究如何让马甲包更难被识别，其中最重要的一环就是元数据重命名。今天把我摸出来的经验整理成文，给正在做马甲包的团队一些参考。

一、Google 识别马甲包的6个维度

1.1 应用名称相似度

Google 会扫描所有上架应用的名称，计算名称之间的相似度。如果你的多款应用名称高度相似，比如"天天消消乐"、"开心消消乐"、"乐消消天天"，这三个名称的字符重叠率超过70%，很容易被识别为同类应用。

我们早期犯的错误就是给每个马甲包取名的时候，习惯性地沿用同一个套路，结果名称相似度极高。最严重的一组5个包，名称相似度达到 85%，上线两周就被合并处理了。

1.2 icon 和截图风格

icon 是 Google 识别马甲包的最重要视觉特征之一。即使你换了颜色、调整了布局，如果整体设计风格接近，审核系统还是能识别出来。我见过一个团队，5个马的 icon 主体都是一只卡通动物，只是动物种类不同，但审核人员一眼就看出是同套设计。

截图也是一样的道理。如果你多款应用的截图布局、UI 风格、甚至是截图里的文字颜色都一样，那被识别几乎是必然的。

1.3 应用描述文本相似度

Google 会用 NLP 技术分析你所有应用的商店描述文本，计算文本之间的相似度。如果你的多款应用使用了相同的描述模板，只是替换了游戏名称和少量关键词，很容易被检测到。

我们做过一个测试：两篇描述的相似度超过 60%，就会被标记为高风险；超过 75%，几乎必然被处理。

1.4 包体结构和代码特征

这是 Google 识别马甲包最核心的手段。即使你改了包名、换了 icon，只要包体结构、第三方 SDK 列表、代码特征没有变化，Google 就能通过 APK 分析识别出来。

具体来说，Google 会检测：APK 的包名和签名证书、应用内使用的广告平台 SDK、游戏引擎和版本号、内购产品 ID 列表。甚至应用启动时访问的服务器域名也会被记录。

1.5 开发者账号信息

如果你多个应用使用同一个开发者账号，这个账号本身就是一个关联信号。即使你用不同的公司主体注册了不同的开发者账号，如果这些账号使用了相同的付款信息、相同的地址、相同的联系人，Google 也能识别出来。

1.6 用户行为数据

这是一个比较隐蔽的识别维度。如果你的多款马甲包在同一天上线、同样的时间段内做同样的运营推广、用户画像高度重叠，Google 会通过这些数据关联起来。这种识别方式不太常见，但一旦被识别，处理力度往往最大。

二、元数据重命名的5个核心技巧

2.1 名称设计要有足够差异

应用名称的差异不能只是换个词缀，要从整体结构上做区分。推荐的做法是：

使用完全不同的命名体系：比如一个叫"彩虹消消乐"，另一个叫"星光泡泡龙"，两个名称的字符重叠率控制在 30% 以下。

不要用同一个词族：比如"消消乐"这个关键词，你的所有包都带上，那 Google 会认为这些包都属于同一个系列。不同包最好用不同的核心词。

名称长度要有变化：我见过一些团队为了省事，只是在名称末尾加了序号，比如"游戏A1"、"游戏A2"、"游戏A3"，这种命名方式几乎等于告诉 Google 这是一套包。

2.2 icon 设计的差异化策略

icon 是马甲包差异化成本最低的部分，但也是最重要的部分。我的经验是：

不同风格的 icon：最好让不同包使用完全不同的设计风格——一个用卡通风格、一个用写实风格、一个用扁平风格。不要只是换个颜色或者换个动物。

不同的 icon 形状：Google 也会分析 icon 的视觉特征，包括形状、颜色分布、主体位置等。这些特征的相似度要控制在 50% 以下。

截图 UI 重新设计：截图的布局要重新设计，包括按钮位置、信息排布、甚至字体都要有变化。不要只是换一套截图，内容和布局完全一样。

2.3 描述文本的伪原创技巧

描述文本的相似度检测主要是通过 NLP 的语义分析，所以简单的同义词替换是骗不过去的。我的做法是：

不同文章结构：不要用同一个模板，改用不同的段落顺序、不同的开头方式、不同的案例引用。

不同的产品定位：即使游戏本身是一样的，也要在描述里赋予不同的产品定位。比如一个强调"休闲解压"，另一个强调"智力挑战"，第三个强调"随时随地玩"。

不同的字数和密度：关键词密度不要一样，不同包的描述长度也要有变化。

2.4 包体的技术伪装

包体层面的伪装是最技术活的部分，也是最难被检测到的部分：

不同的包名：即使游戏代码一样，包名一定要不同。包名是 Google 识别马甲包的最直接信号。

不同的第三方 SDK 组合：不同的包最好接入不同的广告平台 SDK，比如一个包用 AdMob，另一个包用 Facebook Audience Network，第三个包用 Unity Ads。但要注意某些 SDK 组合可能有兼容问题。

不同的服务器域名：应用访问的后端服务器域名要不同，最好是完全独立的域名。

代码混淆程度要有差异：不同包的代码混淆程度可以不同，比如一个用高强度混淆，一个用中等混淆，这也会影响 Google 的识别结果。

2.5 商店信息的时序错开

最后一个技巧是上线时间的错开。不要同时上线所有包，最好分批次，每批间隔两周以上。这样即使 Google 的识别系统发现了关联，也有时间窗口让你保留一部分包。

同时，上线后的运营推广也要错开，避免在同一个时间段、用同样的预算、对同样的用户画像推广多款包。

三、实战检测工具

3.1 Google Play 自检工具

在提交审核之前，可以用 Google 提供的预审工具先跑一遍。虽然这个工具不能检测所有关联风险，但能帮你发现一些明显的问题。

3.2 第三方相似度检测工具

市场上有一些第三方工具可以检测你应用的 icon、名称、描述和已有应用的相似度。我用下来觉得比较有用的方法是自己建一个图片库，把所有 icon 丢进去跑相似度比对。

3.3 内部检测机制

我们团队自己开发了一个小工具，把所有包的 icon、名称、描述、包结构信息全部录入，然后跑一个相似度矩阵。这个矩阵里的高相似度组合会被标记出来，我们再去针对性修改。

如果你没有能力开发这类工具，也可以用 Excel 手动维护一个信息表，定期检查相似度。

总结

马甲包这条路越来越难走了。Google 的识别能力每年都在提升，而且从2025年开始，明显加大了对马甲包的打击力度。以前那种简单换皮的玩法，现在已经很难行得通了。

我的建议是：如果你要做马甲包，必须在每个环节都做到足够的差异化。名称、icon、描述、包结构、SDK、甚至服务器 IP，每一个环节都不能马虎。成本确实比简单换皮高很多，但至少能保证包的存活率。

你做马甲包被识别过吗？最严重的一次是什么情况？评论区聊聊，看看有没有共同踩过的坑。