最近又有账号被关联了，这次关联和以往不一样，现在还在申诉，对申诉结果没有过多的期待。经过这一次，决定重新梳理一遍账号关联问题。希望通过惨痛的教训，能给面临同样问题的开发者提供一些解决思路。
- 5月6日，APP审核通过发布上架；
- 5月14日，版本更新；
- 5月19日，版本更新；
- 5月19日，开始针对APP进行付费功能对接；同时提交第一个测试账号A；
- 5月21日，后台添加第二个测试账号B；
- 5月22日，开发者账号关联被封；
这次最后的判断是，测试账号导致开发者账号关联；测试账号A和B都不曾是开发者账号，但是都曾经在使用过被封开发者账号的手机上登录。特别B账号，提交测试时，常用设备之一依然登录着过去被封的开发者账号。正是因为这次对测试账号的大意，导致账号被封。这次开发者账号上的APP无任何违规，是纯粹的工具类APP，包括里面的广告点都是非常干净的。在账号被封之前，没有收到过下架或者违规警告。
经过这几天的总结，重新梳理开发者账号相关的内容。对此次因为测试账号导致封号更加确定。大家看下图：
重点关注标记的位置；Google的关联关系，目前公认的判定者是机器。也就是谷歌通过机器算法，针对开发者账号的各种信息和行为进行对比，然后根据对比结果来判定是否是关联账号。
如果大家对评分卡有一定的了解，那么可以把Google的这个判定规则比做一套评分卡系统，简单的理解就是机器通过对开发者账号相关的各种字段与黑名单库进行对比。然后每一个字段都会有具体的分值。当分值超过某一个值时，就判定为关联账号。而这其中，有一些字段，单独命中就会直接得到较高的分值。从而确定账号关联关系。（这是一种假设，实际的系统应该比这复杂很多）
对于较高分值的字段，目前的判断是：设备相关，付款/收款相关，主动关联信息。
1、设备相关
这一块不用多说，有很多介绍的文章。很多开发者都有在本地电脑登录开发者账号导致封号的经历（前提是本地电脑曾经登录过被封账号）。我们曾经尝试过重置系统，清除缓存等策略。但是依然有中招的，后来就不敢再验证了（成本太高，而且无法确定是什么规则导致了关联），后来就直接采用VPS服务器的方式进行。这也是目前避免账号关联的基础操作。
设备这块，VPS服务器已经是最好的解决方案了。当然，如果你只有唯一一个开发者账号，而且从未有过违规记录。还是可以在本地登录的，配备一个稳定的虚拟专用网络就没有任何问题。
2、付款/收款相关
关于付款，指的是开通开发者计划所支付的25刀所使用的付款卡，去年很多人都可以使用自己的信用卡支付（需要是VISA或Master），但是最近一段时间来，经常会出现支付失败的情况，这个具体是什么原因不得而知。我相信依然还是有很多是采用这种支付方式的，也是可以支付成功的。
如果是采用自己的卡支付，那么卡相关的信息已经被记录了。如果使用同样的卡支付其它的开发者账号，那么这个关联关系是非常强的。如果让我去制定账号关联关系，支付卡这一条信息，肯定也是首选的。
为了避免这种情况，最好的办法就是一个账号对应一张卡。最好是每个账号对应的人都是不一样的。如果实在做不到，可以尝试一个人不同卡进行支付。
其它还有找人代付或者是买卡。这块这里就不多说了。
收款卡，这一块主要就是当你的APP有付费项目时，一定要慎重填写。填写的收款信息一定要是干净的，可以使用自己的收款卡。关于如何收款，有相关的介绍文章，大家可以前往查看（如何设置收款银行卡）。这里不再赘述。
这里的原则就是，不同开发者账号，收款信息分开。不要混用。
3、主动关联信息
不知道大家是否注意到，开发者账号可以主动关联AdMob，Google Analytics，Firebase这些平台，还有就是添加测试账号这些内容。假设你没有主动关联的时候，谷歌也知道你所使用的这些账号。但是它不会非常确定说你们是一起的，当你主动关联的时候。它的规则就明确说，你们是一起的！
假设你有一个AdMob账号，之前给某一个APP对接广告，后来这个APP违规被下架了，然后APP对应的开发者账号被封了。这个时候，重新做了一个APP，对接的依然是这个AdMob账号，新的APP被关联的情况是多大呢？当在新App对应的开发者账号后台关联了此AdMob账号，这是不是直接主动告诉了Google你们是同一个人？我想这个时候，谷歌的机器肯定是要把这个账号关闭掉！
图中列出的字段，在申请开发者账号的时候，最好是做到彻底独立，与过往有黑历史的账号区别开来。想要真正搞清楚谷歌的判定规则，是非常难的。而且在不同的时候，判断规则也会有所侧重。同样的游戏APP、金融APP、工具APP也会有不一样的判定，具体还需要开发者通过经验不断的摸索。
对于开发者来说，最大的问题就是被判定关联，直接封号，没有任何的机会（如果有开发者申诉成功了，可以留言给大家分享下经验），这才是我们不能接受的。也就是很多时候都不知道自己是怎么死的，唯有慎重才能降低被关联的风险。
以上这些内容，希望能给大家带来帮助，如果大家有同样的情况也可以互相交流。对于开发者来说，要在Google Play平台上发布应用，需要遵守他们的规则。如果因为触犯规则导致账号被封，那就得不偿失了。
在谷歌目前的机器规则下，你一次是坏人，那么永远就是坏人，把曾经违规的账号相关信息永远封存，不再用于新的开发者账号中是最优策略。不知道谷歌开发者黑名单有没有有效期的这种说法，如果有不知道是2年还是5年。可是对于开发者来说，肯定是没有任何成本或时间去试探和等待的。
今天分享这些内容，一方面是对遇到情况的一些分析总结。另外也是对Google Play开发者政策的一种解读。Google也许是大的公司，但是在开发者规则这一块，做法明显是不如IOS的。谷歌的政策审核工作，大量是通过一台写着无数规则的机器执行的，面对机器，机械式的应对是最有效的。
【扩展阅读】谷歌应用市场上架(开发者账户关联)相关问题汇总以及解决方案
选自 知乎 贾Sir
目前互联网公司出海做业务的时候，必须要跨过的2座大山就是Facebook和Google. Facebook掌管着全世界优质的用户流量, Google掌管着app的上架入口。而其中Google Play 的 app上架则是出海要解决的第一个问题。我会用几篇文章一一说明下上架过程中遇到的问题以及解决办法.
开发者账户注册到上架的流程包括哪些?
为了app的安全稳定的上架，上面是我总结的app的整个的上架流程.
首先先说一下远程vps(远程虚拟主机)的事情。
购买远程vps的目的是为了规避上架操作环境(ip 电脑mac地址 浏览器cookie等信息)和其他开发者帐号关联。那么我们要去哪里采购这种vps呢?
有这么几种方式: 大厂vps(阿里云, aws) ，小厂vps，自建/私有机房
当然鉴于自身条件和投入成本的话，大部分人还是选择的使用大厂的vps. 如果你有资源优势的话，自建机房搭建vps是最安全的，当然维护成本一般人承受不起。
然后说一下账户是自己注册还是购买的问题。
自己注册开发者帐号的话，为了避免关联，自己要提前准备好完全新的资料，信用卡和vps环境(具体教程大家自己去百度好了，一大把)。这里有个小秘诀，开发者帐号注册完毕后，等个2-3天再上传app。如果在上传app之前开发者帐号就被关联封号的话，这说明你注册过程中就有关联的因素没处理好，这样就省的浪费刚弄好的app包了。
稍微提醒大家的就是， 如果是自己注册账号一定要多看看，多问问，保证环境干净，遇到问题别慌，记住 我们要的是成功率，不是速度。
购买别人的账户的话，要找靠谱的渠道，账户需要是已经注册了1个月以上的老账户，安全，稳定。
综上，如果你有能力搞定全新的申请资料的话，那建议自己注册，如果你没有，那么建议还是找渠道，至于怎么找，你懂的.
账户关联是指什么?可能的关联点有哪些?
账户关联是指gg识别到你的多个app可能是类似的马甲包或者上包环境可能是相同环境, 会一撸到底的全部下架,封号. 让你之前所有的努力和辛苦，一夜之间灰飞烟灭，整个公司的业务都会停滞，严重的情况下，可能直接解散也不是不可能。。。
可能的关联点:
(1) 后端接口: 接口的ip, 域名
(2) 上包环境: 远程vps的ip, mac地址. gmail邮箱绑定的手机号, 开发者绑定的信用卡.
(3) 客户端: 代码重复度大, UI类似.
如何避免关联?
先针对上面的关联点一一进行解释，然后再针对性的看解决方案:
(1) 后端接口: ip要换新的, 域名也要换新的，更改接口结构, 加密数据传输
(2) 上包环境: 确保注册开发者账户使用的信用卡和gmail邮箱没人使用过或者没有绑定过其他开发者账户. 也可以去购买现成的账户. (购买有风险, 需要仔细识别)
(3) 客户端: 代码重复性因为不确定改动到何种地步就算重复性低了，简单的方式就是修改UI, 加密字典, 方法名, 类名. 可能的情况下，完全重构是最好的
(4) 开发者账号: 在使用过程中要做好隔离, 只能在固定的机器和ip下使用.
(5) 客户端使用的第三方: 上架前，对自己的进行抓包分析, 检查第三方是否非法上传用户数据或者诱导用户下载app. 不同的app要使用不同的第三方账户. 包括但不限于 第三方sdk的密钥，第三方的账户(不同的app绑定要绑定不同的Facebook账户下的不同的appid)
有没有万无一失的办法?
目前没有万无一失的办法. 因为gg的风控也在学习，进步, 升级. 当然如果有人声称有稳定上包的办法, 麻烦你推荐给我, 我去拜师.
当然现在有些公司就是不断的上架app，每天上架很多app，期望能有几个app能审核通过，用量取胜，博几率。其实这里面有个小问题，就是如果上架的app越多，gg能学习到的app代码样本就越多，这样是不是也给了gg更多的代码关联检测依据呢? 大家思考下....
大家也别费劲去猜测和询问gg的上架风控策略，这个是绝密，就连gg内部非审核团队的人都是不知道的。原因你懂的。
其实最稳定的上架策略就是仔细研读和遵守Google Play的开发者政策，这样才能保证我们上架的过程顺利。
【扩展阅读】Google 开发者账号及关联被封后怎么解决？
选自 第一出海视角
近期谷歌下架了600多款安卓应用，App被暂停、下架，账号被封停这些事情遇到太多，损失可谓惨重！下面将结合实际经验分享一下如何应对开发者账号被封停，2020年2月份以来，Google封禁的力度和技术水平提升了不少，在踩过很多坑以后，我觉得有必要总结一下我们踩过的坑，给其它朋友作为参考。
Google封禁关联账号，主要是把控两个部分， Google开发者账号的申请，申请Google开发者账号用的PC，基本原则：一台PC对应一个Google开发者账号。
PC+香港VPN
更换一台全新的PC+香港VPN（之前没用过的），找一个修改PC信息的工具，想走捷径，可以直接用阿里云在香港的windows云服务器去申请，这样可以省去VPN的费用，一台PC登录过其他Google开发者账号，忘记清除登录信息，结果会凉凉
第一次申请时账号没问题，等到这个账号被封，我们更换了windows云服务器的IP地址和操作系统，想再去申请，发现总是被封，猜测是云服务器被Google记录了，具体是通过记录哪些信息来识别的，还不太清楚。
申请Google开发者账号用的支付账号真实的信用卡，一个信用卡只用来支付一个账号的费用，第三方虚拟信用卡平台，我们用的是全球付。和信用卡一样，一个虚拟信用卡只用来支付一个账号的费用。
其它每个Google开发者账号都要对应一套全新的信息。除了上面说的PC和支付账号外，还包括：手机号，隐私权网址：我们这边是先随便乱填一个，等Google找我们时再填一个正确的，开发者个人和住址信息
提交到Google上的的apk， 静态马甲包，就是指新提交的包和以前被封的包存在相似的地方，被Google检查出来了，这种是纯静态检测，即我们自己解压apk包就能看到的东西。具体包含哪些呢？
Android aar包，Unity游戏必然要引入各种Android aar包，这些包里面一般都是第三方公共的SDK，看起来应该没问题，我们就往aar包加了一个自己的类，结果就被封了。移除这个类就没事！
解决方案，从0开始导入第三方的SDK，如果自己要新加类，麻烦更换类名和包名，不要和之前提交的一样，找个第三方加固工具（比如360的应用加固），加固一下apk。
资源包，也就是apk解压后assetsinData下的文件（以Unity工程为例）Google是通过比较文件名和文件内容的相似度来判断两个包是否是马甲包，不管你是用mono方式打包，还是IL2CPP方式打包，这个目录下会有一大堆用hash值命名的二进制文件，hash值来源于原始的文件名，这意味着如果两个apk里面有大量的二进制文件同名，那么对应的也就会有大量的实体资源文件同名，这个很危险。
最佳选择，把用到的资源单独打一个AssetBundle包，并对这个包进行加密（简单的按位取反就行），这样就不会有太多二进制文件暴露在assetsinData目录下了，这个最优选择也有个问题，就是如果这次提的包被封了，下次提的包AssetBundle文件就和这次相同了，解决方法就是换一种加密方式。
服务器网络，如果你提交的包被封了，那么下次提交时一定要更换服务器的IP地址和域名，很多互金朋友可能不知道，自己游戏的HTTP请求是明文的，就是客户端发送给服务器的HTTP请求把服务器的域名写的很清楚，Google会毫不客气地封掉这个域名，所以光换IP地址，不换服务器域名，是没有用的，没有用的，没有用的！
代码（针对Unity工程）这个没什么好说的，直接用IL2CPP方式打包，如果你坚持用mono打包，也可以，自己修改一下libmono.so，实现对dll的加密就行。
千万不要去淘宝买Google Play账号，淘宝那些卖账号的只顾自己赚钱，一台机器一张信用卡申请很多账号，然后卖给你，如果卖出的这些卡号一个有问题，就全部封杀了！切记。实在不行可以挂失你的信用卡，补发一张给你。注册手机借朋友的或者用阿里小号就可以了。
以前的IP也不能用了，重新换个IP地址，电脑问题，建议你换一台电脑电脑，如果预算不够，那么可以租个便宜的云服务器做个打包平台，你可以在你的电脑上码代码，打包在云服务器打包，app的代码和素材以及宣传等
谷歌反作弊
如果仅仅前面3步你以为能逃脱强大的Google Ai了？谷歌反作弊系统会分析你的代码的，以及各种特征。最好的办法是以前的都不要用了。不然每次封杀你，你可能会怀疑人生，做到以上4点好像看起来就跟以前完全脱离了。没错，就是这样，你一定要把自己当做全新的一个开发者。不要侥幸。你对面的是全球最强大的人工智能。而你只有一个人。
上传应用部分
多个马甲包，隔天上传，每个马甲包隔1天上传，发布成功一个，则上传下一个。因为同一天可能被同一个人审核，以避免造成同时被拒/下架
用Firefox传包，据说可以隔离本地数据
应用描述、应用截图，与之前不同
应用描述不包含竞品品牌词，apache、base测试版发布，测试人员账号，与之前不同
APK打包部分
《隐私协议》《用户数据授权说明》《其他文本协议》，与之前不同
APP前端文案（展示文案&提示文案…），与之前不同，细化到每个词，不仅仅是顺序调整
APK内数据传送域名、API、IP、域名主体、SSL证书主体，与之前不同
APK文案中联系方式（WhatsApp、email、手机号、地址…），与之前不同
APK内三方服务信息（如firebase、google analytics等），与之前不同
APK应用签名，与之前不同
APK打包机器和IP，与之前不同
代码混淆，相似度越低越好，相似性<40%，有条件重构最好。
文件名、类名、协议名、函数名、属性名；图片、样式表等资源文件命名及路径，与之前完全不同
APP启动弹出隐私授权声明，需用户同意，才能进入下一环节，用户同意后，才可进行数据采集授权，用户同意授权后，才可进行数据收集
图片、视频等媒体文件，hash值与之前不同（需打乱）
UI与之前完全不同，从外表看与被下架的产品有结构上的区别
来源：Enjoy出海
