一、什么是马甲包

马甲包是利用App store 规则漏洞,通过技术手段,多次上架同一款产品的方法。马甲包和主产品包拥有同样的内容和功能,除了icon和应用名称不能完全一致,其他基本一致。

二、为什么做马甲包,做马甲包有什么好处?

1、抗风险

正常情况下,任何一款产品都是要不断的更新功能的。如果我们直接在主包上更新,一旦新功能不被用户接受那就损失大了,我们前期大量投资带来的用户将会流失,这对很多产品开发者来说是不可承受之痛。

如果使用马甲包,则可以随意测试新功能,好的功能就在主包上迭代,不好的也无所谓,马甲包本身就是来背锅的。

1、苹果近期审核动态分析

2、2018年App Store算法重大调整首次曝光一、苹果近期审核动态分析

1、机审越来越完善

众所周知,应用在上架至App Store前,必须通过神秘的苹果审核团队的审核。能否在短时间内顺利通过审核,对App推广节奏和策略、以及迭代等的应该是非常大的!

首先讲一下提审的流程

目前应用提审的整个流程大体分为五个阶段,这个登录过iTC后台或操作过App上架的小伙伴应该都知道:Prepare For Upload(准备上传)、Waiting For Review(等待审核)、 In Review(审核)、Pending Developer Release(等待开发者发布)、Ready For Sale(准备销售)。

其中 Waiting For Review(等待审核)和In Review(审核)这两个阶段是不受开发者控制的,也就是说,这两个阶段由审核人员操控。

下面说一下机审和人工审核

苹果审核大体分为三部分,预审、机审和人工审核。包上传后首先进入的是预审,会被扫描API等,没问题的话才会在iTC里出现 然后才可以提交至 Waiting。

在审核前期,也就是 Waiting For Review(等待审核)阶段一般是机审,去年闹得沸沸扬扬的4.3就是通过机器扫描扫代码;

机审不通过则直接被拒,通过后会进入人工审核,即In Review(审核)阶段,这个阶段主要看的是App的元数据,例如标题、描述、截图等,以及检测App的功能使用情况,常遇到的ipv6也在此处检测。

判断是进入了机审状况还是人工审核状态,除了看时间外,还有一个方式,就是去看后台,如果有美国iP登录,应该就是人审了;如果只有App启动但没有深度访问,说明在机审呢,正在扫代码。

当然,利用上述两种方式也可以来判断App是机审被拒,还是人工审核被拒,然后确定解决侧重点。

目前机审机制越来越完善了,而且也越来越受重视,这个从2.1和4.3出现的频率就可以看出来!其实苹果重视机审也是可以理解,减少人工成本并增加审核严格度,也更倾向于人工智能这个大方向!不过如果机审机制太完美,对我们可能不是好事,过审也许会越来越不容易。

2、审核时间逐渐缩短,但延期审核现象增多

虽然大家一直在吐槽苹果的审核时间,但相比于之前,例如78天阶段、34天阶段,现在已经很不错了。而且通过近三个月的审核数据对比,App审核的周期又有了进一步缩短的趋势。

苹果曾在2017年6月WWDC大会上表示,接下来会进一步缩短审核时间。从目前趋势来看,确实是在进一步缩短。不过现在又出现了一个现象或者说处罚方式——延期审核。

延期审核一般针对的是大量同种类的App,比如游戏(斗地主等),还有涉及敏感题材的App,比如金融、彩票、VPN等。特别是对于游戏,苹果已经摸清了此类App开发者的套路(马甲包、隐藏支付等),但由于一些开发者隐藏工作做得好,苹果又无法拿到确凿证据,所以只能故意拖延。如果被延期轻则需要十几天,重则拖延1个月甚至几个月。

有小伙伴可能想了解延期审核后怎么办?在此说几点,如果没有明显违规,除了打电话,在iTC后台点【联系我们】这些方式外,还有一些稍微冒险的方式,申诉或加速审核。如果这两个方式还不行,又不想等,果断换账号重新提包吧!还有个方法是将免费App设置为付费,但也只是可以缩短waiting时间,审核的时间也可能会很久,这个不是很好管控。

3、苹果审核侧重点不断调整,且新的被拒理由层出不穷

苹果审核侧重点不断调整,且新的被拒理由层出不穷。用这句话来形容近期苹果的审核应该不会有人反对吧?

这个现象我们从近3个月被拒条款排行榜即可窥得一斑。当然这里所说的“新的被拒理由”有些是一直存在的,只是没有侧重这方面审核或者说审核没有升级到这一步而已。下面结合数据分析一下,里面会涉及一些被拒现象的分析。

①如下图所示,2017年12月,在统计的所有样本数据中,条款2.3(元数据问题)占据近乎四分之一的比例;其次是条款5.1.1(主要是用户隐私问题),占比约16.88%;而条款2.1(主要是App完成度问题,此时被拒大礼包还没集中出现)以577例居第三。除此之外,Top5中还有5.2.1。

这里说一下5.2.1吧,在因该条款被拒的App中,金融理财类App占比较大,而关于此类问题的处理方式大家一般采取的是买账号、代上架然后在线转移、套壳然后采用登录做区分等方式、PS等。不过随着越来越多人使用,和监管的力度的加强,PS、套壳等过审几率已经没有以前高了。

②在2018年1月被拒条款排行中,条款2.3(元数据)继续位居榜首,紧跟其后的是原本在2017年12月排在第二名的条款2.1(App 完成度)。而新晋条款3.2.1以 231例,7.15% 的比例成为第四名。

在因3.2.1被拒的App中,很多人是收到了下方的内容,要求提供营业执照、金融许可证等7项内容。对于3.2.1,现在已经出现了待操作、过审,我简单说一下过审的App大体都做了啥吧!

1-3条要求的证照直接上传或放在附件中。然后提供营业执照时,在营业执照中标出了营业范围,例如证明经营范围里有网络借贷信息中介服务等。

提供了该营业执照在国家企业信用信息公示系统(网址:http://www.gsxt.gov.cn/index.html)的查询方式。提供增值电信业务经营许可证时还提供了增值电信业务经营许可证查询链接:https://tsm.miit.gov.cn/pages/home.aspx

此外,虽然其他4点不如前3点重要,但也进行一一回复。

第4条是要求给出平台的服务协议和条款;第5条是如发生争议,应用程序和服务提供什么样的解决机制;第6条需要说明是在这种情况下有什么责任,这些责任是否在条款中明确规定;第7条是涉及的责任各方如何追查。把这些内容都按照要求提交,并在截图中标明了重点。

此外还提供了产品的介绍、与支付公司合作协议。其他大家可以自己去探索一下,提示一点:官方材料尽可能多。

③而在最近的2月被拒条款排行中,条款 2.1(主要是被拒大礼包),以28.48% 的比例占据了榜首。紧跟其后的是条款2.3(元数据)。新晋条款 4.2(最低功能要求)以147例,5.94% 的比例成为第五名。

因条款 4.2被拒的App多数是因为功能过于简单或缺失或审核人员没有get核心功能。对于这一问题解决方式除了按要求添加些小功能,对细节进行优化外,也可以考虑解释产品可用性,例如用户的需求,和其他产品区别等。

还有一点很想和大家一起讨论一下。这阵子收到的人不少,就是1月28日集中出现的、叫很多人叫苦不迭的2.1大礼包。1.1.6、2.3、2.3.1、3.1.1、4.3等都被罗列其中,而审核人员的要求是:你自己去排查吧!在被拒的App中,不仅包括金融,还有电商、游戏等。

img

上图是比较普遍的2.1大礼包,我们先看一下每条被拒理由和常规解决方式吧!

1.1.6 –包含虚假信息,功能或误导性元数据

一般是因为标题或者icon和截图等有误导的嫌疑,或有些关键词是被苹果列入黑名单的,例如红包包、话费等,但审核条款又没有明确指出。对于上述情况的解决办法是使用保守的文案或素材。

2.3.0 – 含有不经审核也可更改App功能

如改变App功能的热更新,这种情况需要把热更新去除,或者对热更新模块代码做深度混淆处理!

2.3.1 – 含有隐藏功能或为记录的功能,包括定向到赌博或彩票网站的开关。

常规解决方式:去除隐藏功能模块代码或将需要隐藏功能的代码及定向跳转链接网址做混淆处理,适当增加逻辑复杂度。3.1.1 –应用内购以外的支付机制来解锁App中的功能或功能。

对于第三方支付,尽可能避免使用易扫描的SDK版本,推荐使用H5版本支付。支付跳转链接相应的做屏蔽混淆处理。

4.3.0 –是另一款应用的复制品,或与另一款应用明显相似。

被认为是重复App或马甲包,变更UI和名称,填充无用代码等,下面会具体讲。

5.2.1 –未由拥有并负责提供该应用程序提供的任何服务的法律实体提交。

未提供 App 上架所需的行业资质,比如:金融营业许可证、游戏版号等。这个上面讲过些常规方式。

5.3.4 – 含有货币游戏(如:体育下注、赌场游戏等),但未提供相关许可资质。

同上,提供资质,审核时最好不要勾选中国区,或使用海外账号。

①如果App没有违反上述任何一点,其实直接回复没有违反即可!当然,如果想增加过审几率也可以按照邮件中罗列的审核指南一一进行解释,说明自家 App 并不存在这些规则中的问题,尽可能描述详细。如果回复后并没有推进,可以配合加速审核或审核申诉,不过需要注意,加速审核次数不要用太多,审核申诉可能引来审核团队更严格的审核,需要谨慎。

注:2.1刚出现的时,即使App有违规行为直接回复也是有可能过审的,但是目前有点用烂了,苹果那边应该是敏感了,目前过审几率极低,而且有可能被延期。

②如果App违反上述某点,建议认真修改后回复苹果,重点看上次或历史被拒记录,确定回复侧重点。如果回复后并没有推进,也可以配合加速审核或审核申诉,不过有延期等风险。

③除了这些方法,有人还用过一种方式过审,即用新账号上传,上面说过“苹果审核人员应该并没有开始审核,仅是针对App的历史违规记录或开发者账号的违规记录等发送了这封邮件。”但这种方式并不适合所有App,而且苹果可能会发现新账号的App和旧账号以及旧App的关系而产生连带处罚,要看运气。

下面是小助手收集的几个问题,在这里做一下回复:

A、2.1有解吗?有,目前出现了代过审,具体操作方式都是私下进行的,和5.2.1和3.2.1一样,大家都去用,反复刺激苹果,审核机制又会被更改。

B、只有更新的App才有可能收到被拒大礼包?其实不是,收到这封邮件的App中既有新提交的App,也有要更新版本的App。

C、2.1是机审?目前数据和被拒的现象来看,主要是机审,人工审核比例不高,多数是针对的代码、App或开发者账号的历史违规记录等发送的邮件消息。

pp的历史违规行为和账号的历史违规行为都有可能触发2.1大礼包。

当然除了以上被拒原因外,4.3(重复App)、IPv6、3.2(f)、PLA1.2等仍是被拒常见原因!下面说一下4.3。

4.3主要针对的是重复App,就是马甲包,4.3被拒主要在机审阶段,解决这个问题通常采用的方式简单来说分以下几步:

A、改名字;

B、修改素材及UI色调等,例如修改icon,修改主色调;

C、修改功能界面等,可改功能可做小开关;

D、填充代码(最好50%以上)或注释块;

除以上步骤外,还需要注意相同的马甲包提交至少要间隔一天以上,避免被同一个审核员看到。当然,还可以配合着升级套路:升级version(版本)号、换bundle id,换开发者账号再提交审核。

如果以上步骤不奏效,还可以尝试采用修改应用价格、发布地区、产品分类等方式。不过注意,App上架后价格、发布地区是可以修改的,但产品分类不可以,对这个有要求的慎用!

IPv6的话,确认代码没问题的话,重新提交1~2次就好了。多数是审核人员所在的网络环境导致的问题,如果不放心,重新提交时将截图或拍下视频放附件里或直接向苹果申诉。如果 App本身有问题,例如不兼容 IPv6,最好的办法是让App兼容 IPv6 或通过升级服务器来支持IPv6,其他代码问题问问技术就OK了。

二、2018年App Store算法重大调整首次曝光

2月末,App Store算法进行了一次重大调整:很多产品并没有优化排名或更新版本等,但关键词数据却出现了明显波动(增多或减少)。群里很多小伙伴应该都有感知。

该现象集中出现在2月22日,而通过数据分析对比发现,其波动范围非常广,中国区App Store的大批量关键词覆盖与排名数据都受到了不同程度的影响。

七麦研究院曾对2月22日的所有分类榜31000余款App作为样本进行对比,发现和2月21日相比关键词覆盖数变化率占比在82.41%以上。其中,关键词覆盖数增加的数量比例达60.82%,减少比例为21.59%。

img

②主要曝光和获量区间(Top10和Top3)的关键词数量也有较明显提升,其中,Top10关键词数量增加的达7701款,占比22.60%,减少App为8389款,占比24.62%;Top3关键词数量增加的达6066款,占比17.80%;减少的App数量为5154款,占比15.12%。

目前该现象还没有明显恢复,且仍有不断调整的迹象。截至当前,此次算法调整有哪些趋势呢?我们应该重点关注哪些因素呢?下面谈谈我的看法。

1、公司开发者账号成为影响App权重的一大因素

针对上述31000余款app的种类以及关键词覆盖数变动对比,发现:本次调整中,公司开发者账号下的App关键词覆盖与排名增加得更多;而个人开发者账号相比较而言,关键词覆盖与排名受到的负面影响更多。在算法变动中,公司开发者账号成为了影响App权重的一大因素,并间接对排名优化产生影响。

将样本App以公司开发者账号和个人开发者账号(34000余款样本中,公司开发者账号有16266款,占比 47.73%;个人开发者账号有 17811 款,占比 52.27%)进行区分后,分别从“所有关键词”、“Top10关键词”、“Top3关键词”三个维度进行了对比分析。其中,

① 从关键词总数上来看:如下图所示,相比2月21日,关键词总覆盖数减少区间内,个人开发者账号下的App数量明显比公司开发者账号下的App数量多,关键词覆盖总数减少超过11的App中,个人开发者账号下的App所占比例更大。

img

②从Top3和Top10关键词总数上来看:如果大家觉得上图对比不太明显,可以看下方Top3和Top10关键词覆盖总数变动详情图。减少区间(-1以下)中,个人账号下的App数量和公司账号下的App数量对比,相差很悬殊。

A、从Top3关键词总数上来看:

关键词增加数量大于11的App中,公司开发者账号下的App数量高于个人开发者账号下的App数量;且关键词增加数量在0以下,即关键词减少区间在1~100之间的App中,个人开发者账号下的App占比较大。如下图所示

img

关键词增加数量在11以上的App中,公司开发者账号下的App数量同样多于个人开发者账号下的App数量;而关键词减少数量在1~100之间的App中,个人开发者账号下的App占比也非常大。如下图所示

img

2、下载量在算法中仍占重要比重

此外,我们还从“进入总榜”和“不在总榜但进入分类榜”两个维度对样本App进行了数据分析,通过计算两类App在不同涨幅区间中的占比发现:App的榜单排名在此次调整中是不可忽略的因素。

例如,在覆盖总量变化的几个区间中,仅进入分类榜的App关键词覆盖数降低、不变、少量增加(1~10)的比例更多;而总榜App关键词覆盖总量增加超过10以上的App比例呈逐渐增多趋势。

img

除此之外,Top 10/Top 3 关键词覆盖数变化的几个区间中,总榜所受到的正面影响也优于分类榜。

img

众所周知,下载量、评论、日活、留存等是影响App榜单排名的重要因素,而下载量是主要因素。此次榜单排名更好的App受到正面影响更大,其实可以证明,App下载量,或者说自然新增多的产品在此次算法调整中受到的正向影响较多,下载量在此次算法调整中占重要比重。

3、评论优化权重有所增加

在数据统计和分析过程中发现,本次调整中很多处于相同维度的App,评论优化较好的产品,关键词数量和排名增加的现象更明显。

下面举一个比较明显的例子,大家可以看一下这款产品的评论和关键词覆盖数量变动情况。

img

保持稳定周期性地对产品做一些真实用户的好评优化,更有利于增加产品权重,且在遇到类似于本次算法调整的时候,产品受到的正向影响的几率会更大,负向影响的几率会更小。

4、苹果对量级(CPSA)的考察时间变长,投放效果延迟

近期关键词排名优化效果出现了延迟现象,12小时候内出现效果的比率降低。很多App优化效果出现在投放后第二天或第三天,有些延迟时间甚至更长!

我们根据抽取的样例进行统计和分析,关键词排名优化后,效果集中出现在20~28小时。

img

关键词排名优化效果的延迟很可能是苹果对搜索下载量的考察时间增长,针对目前的调整,建议优化某个关键词排名后,观察时间最好延迟1~2天,然后在根据实际情况调整接下来的优化策略。

例如,

①产品进行ASO优化初期,建议每天少量测试多个关键词,缩短关键词投放测试周期,延长关键词优化后的观察时间,重点关键词延长测试时间至2-3天;

②关键词排名有明显提升后,再进行下阶段的优化,提升关键词排名至目标排名;

③排名提升不明显的关键词暂时放弃,或隔段时间再进行测试投放。

最后还有4.3问题解决方案

基础知识:

1.苹果的审核,分为机器审核和人工审核;

目前大多数4.3是死在机器审核阶段。

2.苹果对开发者帐号会进行权重管理;

权重越低的帐号,审核越严格;

同样的包,可能在权重高的帐号上就能过,在权重低的帐号上就是4.3;

3.目前苹果还只是对新提交应用进行相似应用的检测(包括新包和升级包);

对新包的检测严厉程度和升级包相仿(还是看帐号权重)

预判,随后会对之前已上架的包也进行相似应用检测,只是时间的早晚;

规避4.3的重心:

切断当前马甲包与以往马甲包的所有相似性关联;

相似性关联包括:

\1. ipa包特征;

\2. 开发者帐号;

\3. 打包电脑;

\4. 上传IP;

\5. 材料相似;

分项细述:

\1. ipa包特征:

包括有代码相似性,资源相似性;

代码相似性解决办法:

​ a. 已有代码的混淆(改类名、改函数名)

​ b. 添加一些无用的代码;

资源相似性解决办法:

​ a. 资源改名;

​ b. 适当添加一些无用的资源;

\2. 开发者帐号:

两个马甲包不要关联到同一个开发者帐号的信息;比如打包时关联。

\3. 打包电脑:

有条件的最好用不同的MAC来打包(每台MAC上最好打包马甲包不要超过5个)

\4. 上传IP:

上传马甲包时,IP不要跟其他马甲包的IP相同;

\5. 材料相似:

itu后台材料如宣传图,ICON,版权人不要出现相同;

【注:即使是前边没审核过的包,也不要跟他们有关联。尤其是前边被4.3拒绝的包,更不能跟他们有相似性】

———-

以上的能做到,基本大部分马甲可以顺利通过4.3这道坎了。更高级的技巧,待后续整理。

———-

补充 关于被拒大礼包问题,就是一个字怼,不能怂。怂了账号也就废了 与其这样不如放手一搏。

版权声明:本文为niit-soft-518原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/niit-soft-518/p/10383800.html