Recently, another account has been associated, which is different from the previous one. Now we are still appealing, and we don’t have too much expectation for the result of appeal. After this time, I decided to comb through the account association problem again. Hopefully, through painful lessons, we can provide some solutions for developers facing the same problem.
Time line:
– On May 6th, the APP was approved and released;
– May 14, version updated;
– May 19, version updated;
– On May 19th, payment function docking for APP began; Submit the first test account A at the same time;
– On May 21, the second test account B was added in the background;
– On May 22, the developer account association was blocked;
The final judgment this time is that the test account leads to the developer account association; The test accounts A and B were not developer accounts, but they had logged in on the mobile phones that had used the blocked developer accounts. Special ACCOUNT B, when submitting the test, one of the commonly used devices is still logged in to the developer account that was blocked in the past. It was because of the carelessness of the test account that the account was closed. There is no violation of any rules in the APP on the developer account this time. It is a pure tool APP, including the advertising points inside are very clean. There were no takedown or violation warnings before the account was suspended.
After these days of summary, reorganize the developer account related content. It is more certain that the test account led to the closure this time. Take a look at the picture below:
Focus on the location of the tag; The current accepted arbiter of Google’s relevance is the machine. In other words, Google compares various information and behaviors of developers’ accounts through machine algorithms, and then determines whether they are associated accounts based on the comparison results.
If you’re familiar with scorecards, you can compare Google’s rules to a scorecard system, where the machine compares various fields related to a developer’s account with a blacklist library. Each field then has a specific score. When the score exceeds a certain value, it is judged as an associated account. And some of these fields, hit alone will directly get a higher score. To determine the account association relationship. (This is an assumption; the actual system should be much more complex than this.)
For fields with higher scores, the current judgment is: equipment related, payment/receipt related, and active association of information.
1. Equipment related
Needless to say, there are a lot of introductory articles. Many developers have had the experience of having their developer account blocked by logging in to a local computer (if the local computer has been blocked before). We tried to reset the system, clear the cache, and so on. However, there are still some tricks, and later did not dare to verify (too expensive, and can not determine what rules caused the association), and then directly adopt the VPS server way. This is the basis for avoiding account association.
For equipment, the VPS server is already the best solution. Of course, if you have only one developer account and no record of any violations. You can still log in locally, and with a stable virtual private network you won’t have any problems.
2. Payment/receipt related
In terms of payment, I’m referring to the $25 payment card used to open the developer program. Last year many people were able to use their own credit card (VISA or Master required), but recently there have been frequent payment failures, it’s not clear why. I believe that there are still a lot of payment method is adopted, but also can pay successfully.
If you pay with your own card, the card information is already recorded. This correlation is very strong if the same card is used to pay for other developer accounts. If YOU let me make account association, payment card information is definitely the first choice.
To avoid this, the best way is to have one account for one card. Ideally, each account corresponds to a different person. If that’s not possible, try paying with a different card by yourself.
Others have someone to pay or buy a card. I’m not going to talk about that here. If you want to know, you can contact Eva customer service to leave a message.
Payment card, this part is mainly when your APP has payment items, must be carefully filled out. Make sure the payment information is clean and you can use your own payment card. On how to receive payment, there are relevant introduction articles, we can go to view (how to set up the payment bank card). I won’t repeat it here.
The principle here is, different developer accounts, separate payment information. Don’t mix.
3. Actively associate information
I don’t know if you’ve noticed that developer accounts can be actively associated with platforms like AdMob, Google Analytics, Firebase, etc., as well as adding test accounts. Assuming you’re not actively involved, Google knows about those accounts. But it’s not so sure that you’re together when you’re actively engaging. The rules clearly say you’re in it together!
Let’s say you have an AdMob account, and you’ve given ads to an APP, and the APP has been removed for violation of rules, and the developer account for the APP has been shut down. At this time, a new APP was made, and the AdMob account was still connected. How often was the new APP associated? When you associate this AdMob account in the background of the corresponding developer account of the new App, is this directly and actively telling Google that you are the same person? I think at this point, the Google machine must be shutting down the account!
conclusion
The fields listed in the figure should be completely separate when applying for a developer account, as opposed to an account with a bad history. It’s hard to really figure out what Google’s rules are. And at different times, the judgment rules will be different. The same game APP, financial APP and tool APP will also have different judgments, and the specific needs to be explored by developers through experience.
For developers, the biggest problem is that they are judged to be associated and directly banned without any chance (if a developer appeals successfully, they can leave a message to share their experience with you), which is unacceptable to us. That is, most of the time, you do not know how you died, and only caution can reduce the risk of being associated.
The above content, I hope to bring help to you, if you have the same situation can also communicate with each other. For developers to publish on Google Play, they need to follow their rules. If you break the rules and get your account suspended, it’s not worth the loss.
Under Google’s current machine rules, if you’re a bad guy once, you’re a bad guy forever, and it’s best policy to keep information about your offending account locked away forever and never use it in a new developer account. I don’t know if Google’s developer blacklist is valid for 2 years or 5 years. But for developers, there is certainly no cost or time to explore and wait.
To share these contents today, on the one hand, is some analysis summary of the situation encountered. It’s also an interpretation of Google Play’s developer policy. Google may be big, but when it comes to developer rules, it’s not as good as IOS. Much of Google’s policy review is carried out by a machine with myriad rules, to which mechanistic responses are most effective.