Tag Archives: Policy

Supporting Google Play developers regarding local market withholding tax regulations

Posted by Gloria On, Program Manager, Google Play

Many developers are increasingly focused on growing their businesses globally, and there were more than 94 billion apps downloaded from Google Play in the last year, reaching more than 190 countries. The regulatory environment is frequently changing in local markets, and in some countries local governments have implemented withholding tax requirements on transactions with which Google or our payment processor partners must comply. We strive to help both developers and Google meet local tax requirements in markets where we do business, and where Google or our payment processor partners are required to withhold taxes, we may need to deduct those amounts from our payments to developers.

Due to new requirements in some markets, we'll be rolling out withholding taxes soon to all those doing business in those countries. We wanted to bring this to the attention of Google Play developers to allow you time to prepare for these upcoming changes and take any necessary measures to meet these obligations. We strongly recommend developers consult with a professional tax advisor on your individual tax implications in affected markets and for guidance on the potential impact on your business so that you can make any necessary preparations.

The first countries where we will roll out these changes will be Saudi Arabia, Kuwait, and Myanmar. You can refer to the Google Play help center page to stay informed on future updates and changes.

How useful did you find this blog post?

★ ★ ★ ★

Improving the update process with your feedback

Posted by Sameer Samat, VP of Product Management, Android & Google Play

Thank you for all the feedback about updates we’ve been making to Android APIs and Play policies. We’ve heard your requests for improvement as well as some frustration. We want to explain how and why we’re making these changes, and how we are using your feedback to improve the way we roll out these updates and communicate with the developer community.

From the outset, we’ve sought to craft Android as a completely open source operating system. We’ve also worked hard to ensure backwards compatibility and API consistency, out of respect and a desire to make the platform as easy to use as possible. This developer-centric approach and openness have been cornerstones of Android’s philosophy from the beginning. These are not changing.

But as the platform grows and evolves, each decision we make comes with trade-offs. Everyday, billions of people around the world use the apps you’ve built to do incredible things like connect with loved ones, manage finances or communicate with doctors. Users want more control and transparency over how their personal information is being used by applications, and expect Android, as the platform, to do more to provide that control and transparency. This responsibility to users is something we have always taken seriously, and that’s why we are taking a comprehensive look at how our platform and policies reflect that commitment.

Taking a closer look at permissions

Earlier this year, we introduced Android Q Beta with dozens of features and improvements that provide users with more transparency and control, further securing their personal data. Along with the system-level changes introduced in Q, we’re also reviewing and refining our Play Developer policies to further enhance user privacy. For years, we’ve required developers to disclose the collection and use of personal data so users can understand how their information is being used, and to only use the permissions that are really needed to deliver the features and services of the app. As part of Project Strobe, which we announced last October, we are rolling out specific guidance for each of the Android runtime permissions, and we are holding apps developed by Google to the same standard.

We started with changes to SMS and Call Log permissions late last year. To better protect sensitive user data available through these permissions, we restricted access to select use cases, such as when an app has been chosen by the user to be their default text message app. We understood that some app features using this data would no longer be allowed -- including features that many users found valuable -- and worked with you on alternatives where possible. As a result, today, the number of apps with access to this sensitive information has decreased by more than 98%. The vast majority of these were able to switch to an alternative or eliminate minor functionality.

Learning from developer feedback

While these changes are critical to help strengthen privacy protections for our users, we’re sensitive that evolving the platform can lead to substantial work for developers. We have a responsibility to make sure you have the details and resources you need to understand and implement changes, and we know there is room for improvement there. For example, when we began enforcing these new SMS and Call Log policies, many of you expressed frustration about the decision making process. There were a number of common themes that we wanted to share:

  • Permission declaration form. Some of you felt that the use case descriptions in our permissions declaration form were unclear and hard to complete correctly.
  • Timeliness in review and appeals process. For some of you, it took too long to get answers on whether apps met policy requirements. Others felt that the process for appealing a decision was too long and cumbersome.
  • Getting information from a ‘real human’ at Google. Some of you came away with the impression that our decisions were automated, without human involvement. And others felt that it was hard to reach a person who could help provide details about our policy decisions and about new use cases proposed by developers.

In response, we are improving and clarifying the process, including:

  • More detailed communication. We are revising the emails we send for policy rejections and appeals to better explain with more details, including why a decision was made, how you can modify your app to comply, and how to appeal.
  • Evaluations and appeals. We will include appeal instructions in all enforcement emails and the appeal form with details can also be found in our Help Center. We will also be reviewing and improving our appeals process.
  • Growing the team. Humans, not bots, already review every sensitive decision but we are improving our communication so responses are more personalized -- and we are expanding our team to help accelerate the appeals process.

Evaluating developer accounts

We have also heard concerns from some developers whose accounts have been blocked from distributing apps through Google Play. While the vast majority of developers on Android are well-meaning, some accounts are suspended for serious, repeated violation of policies that protect our shared users. Bad-faith developers often try to get around this by opening new accounts or using other developers’ existing accounts to publish unsafe apps. While we strive for openness wherever possible, in order to prevent bad-faith developers from gaming our systems and putting our users at risk in the process, we can’t always share the reasons we’ve concluded that one account is related to another.

While 99%+ of these suspension decisions are correct, we are also very sensitive to how impactful it can be if your account has been disabled in error. You can immediately appeal any enforcement, and each appeal is carefully reviewed by a person on our team. During the appeals process, we will reinstate your account if we discover that an error has been made.

Separately, we will soon be taking more time (days, not weeks) to review apps by developers that don’t yet have a track record with us. This will allow us to do more thorough checks before approving apps to go live in the store and will help us make even fewer inaccurate decisions on developer accounts.

Thank you for your ongoing partnership and for continuing to make Android an incredibly helpful platform for billions of people around the world.

How useful did you find this blog post?

★ ★ ★ ★ ★

Reminder SMS/Call Log Policy Changes

Posted by Paul Bankhead, Director, Product Management, Google Play

TLDR; As previously announced and directly communicated to developers via email, we'll be removing apps from the Google Play Store that ask for SMS or Call Log permission. If you have not submitted a permissions declaration form and your app is removed, see below for next steps.

We take access to sensitive data and permissions very seriously. This is especially true with SMS and Call Log permissions, which were designed to allow users to pick their favorite dialer or messaging app, but have also been used to enable many other experiences that might not require that same level of access. In an effort to improve users' control over their data, last October we announced we would be restricting developer access to SMS and Call Log permissions.

Our new policy is designed to ensure that apps asking for these permissions need full and ongoing access to the sensitive data in order to accomplish the app's primary use case, and that users will understand why this data would be required for the app to function.

Developers whose apps used these permissions prior to our announcement were notified by email and given 90 days to either remove the permissions, or submit a permissions declaration form to enable further review.

More about app reviews

We take this review process seriously and understand it's a change for many developers. We apply the same criteria to all developers, including dozens of Google apps. We added to the list of approved use cases over the last few months as we evaluated feedback from developers.

Our global teams carefully review each submission. During the review process, we consider the following:

  • Likelihood that an average user would understand why this type of app needs full access to the data.
  • User benefit of the feature.
  • Importance of the permission relative to the core functionality of the app.
  • Risks presented by all apps with this use case having access to this sensitive data.
  • Availability of more narrow alternatives for enabling the feature.

With this change, some uses cases will no longer be allowed. However, many of the apps we reviewed with one of these permissions can rely on narrower APIs, reducing the scope of access while accomplishing similar functionality. For example, developers using SMS for account verification can alternatively use the SMS Retriever API, and apps that want to share content using SMS can prepopulate a message and trigger the default SMS app to show via intents.

Tens of thousands of developers have already resubmitted their apps to support the new policy or have submitted a form. Thank you! Developers who submitted a form received a compliance extension until March 9th.

Next steps

Over the next few weeks, we will be removing apps from the Play Store that ask for SMS or Call Log permission and have not submitted a permission declaration form. If your app is removed and you would like to have it republished, you can do one of the following in the Play Console:

  • submit a new version without these permissions, or
  • submit a new version of your app that retains the permissions. Doing so will require you to complete a permissions declaration form inside the Play Console (coming soon) and will give you an extension until March 9th to remove the permissions or receive approval for your use case.

Keeping our overall Android ecosystem healthy is very important, and protection of user data is vital to the long term health of all developers. We know these changes have required significant work from you and we appreciate your efforts to create innovative experiences while protecting user's privacy.

Get your ads ready for iPhone X

Every interaction a user has with your app matters. That’s why we’re constantly evolving our advertising recommendations and policies to ensure that no matter where and on what device users are engaging with your apps, they have good experiences.

With the launch of the iPhone X, app developers now need to plan for new design considerations as the rounded corners, notch, and home screen indicator on the extended screen can obscure content and lead to poor ad experiences for users when ads are placed in these areas.

Example of ad appearing outside of “safe area” on iPhone X
That’s why we’ve put together a guide to help you adapt your ad strategy for iPhone X. This includes guidance for how you can shift placement of banner or native ads to designated “safe areas” for this new device.

We’ve also updated our policies to indicate that ads must not be placed where objects may interfere with the user's typical interaction with the ad or app, such as under the home screen indicator on the iPhone X.

Please review these policy updates and our suggested implementation guide to ensure you’re compliant by November 20th.

If you have any questions, visit the AdMob Help Center or contact your Google account team.

Posted by Pablo Alvarez, Product Manager, AdMob

Source: Inside AdMob


Clarification around Pop-Unders

At Google, we value users, advertisers and publishers equally. We have policies in place that define where Google ads should appear and how they must be implemented. These policies help ensure a positive user experience, as well as maintain a healthy ads ecosystem that benefits both publishers and advertisers.

To get your attention, some ads pop up in front of your current browser window, obscuring the content you want to see. Pop-under ads can be annoying as well, as they will "pop under" your window, so that you don't see them until you minimize your browser. We do not believe these ads provide a good user experience, and therefore are not suitable for Google ads.

That is why we recently clarified our policies around pop-ups and pop-unders to help remove any ambiguity. To simplify our policies, we are no longer permitting the placement of Google ads on pages that are loaded as a pop-up or pop-under. Additionally, we do not permit Google ads on any site that contains or triggers pop-unders, regardless of whether Google ads are shown in the pop-unders.

We continually review and evaluate our policies to address emerging trends, and in this case we determined that a policy change was necessary.

As with all policies, publishers are ultimately responsible for ensuring that traffic to their site is compliant with Google policies. To assist publishers, we’ve provided guidance on best practices for buying traffic.

Posted by John Brown, Head of Publisher Policy Communications

Source: Inside AdSense


Introducing page-level enforcements and a new Policy center

As a publisher you face many challenges. One of the broadest and most encompassing of these is growing your user base while making sure your content remains high-quality and policy compliant. Your feedback has helped us understand this challenge, and we’re always working to improve. A few weeks ago, we announced two new AdSense features: page-level enforcements and a new Policy center. Today, we’re excited let you know that these features are available globally for all AdSense publishers.

Page-level enforcements for more granular policy actions
To allow more precise enforcements, and provide you with feedback about policy issues as we identify them, we’re introducing page-level enforcements. A page-level enforcement affects individual pages where violations of the AdSense Program Policies are found. As a result, ad serving is restricted or disabled on those pages. Ads will continue to serve where no policy violations have been found, either at the page- or site-level.

When a new policy violation on one of your pages is identified, you’ll receive an email notification and ad serving will be restricted on that page. As this is a new feature, you may already have current page-level enforcements that were not surfaced through these email notifications. To make sure you’re not missing anything, head over to the new Policy center to review existing violations.

After you've addressed all policy violations on a page, you may request a review (previously known as an “appeal”). Reviews typically take one week but can sometimes take longer. We'll restore ad serving on the affected page or pages if a page is reviewed at your request and no policy violations are found. Alternatively, you can simply remove the AdSense ad code from that page and the page-level enforcement will disappear from the Policy center in about a week.

More transparency with the new AdSense Policy center

The AdSense Policy center is a one-stop shop for everything you need to know about policy actions that affect your sites and pages. You’ll be able to see:
  • Non-compliant page(s) or site(s)
  • Why a page or site is non-compliant
  • Steps needed to make your page or site compliant 
  • Steps to request a review of the actioned page(s) or site(s)


Follow these steps to see your current page-level enforcements, and request a review of the actioned page(s):
  1. Sign in to your AdSense account.
  2. In the left navigation panel, click Settings, then click Policy center.
  3. In the "Page-level enforcements" section, find the site or sites that have page-level violations and click Show details.
  4. In the "Page" section, click the Down arrow to learn more about the enforcement, the violation(s) on the page, and how to fix them. 
  5. Click Request review and tick the box after you’ve made sure the violations on the page are fixed.
Our beta participants provided a lot of great feedback and suggestions on how to make the AdSense Policy center as useful as possible. We’re constantly looking to improve the clarity with which we communicate our policies and policy enforcements, so let us know what you think through the ”Send feedback” link in the AdSense menu.

Learn more about these updates in the AdSense Help Center or head over to the Policy center to try it out.

Posted by: John Brown, Head of Publisher Policy Communications, 
Richard Zippel, Publisher Quality Product Manager and 
Nick Radicevic, AdSense Product Manager

Source: Inside AdSense


Using Splash Pages to Avoid Unexpected Launch Interstitials

In this post, we’re going to discuss an easy way to help avoid violating our policy against interstitial ads that unexpectedly launch (Layout Encourages Accidental Clicks - Unexpected Launch Interstitials): implementing a splash page (Loading/Title Screen) in your app. A splash page is a static screen, containing no clickable content, which launches before the user gets to the ‘Home Screen’ of your app.

First, we’ll talk about the violation itself. If you choose to implement interstitial ads in your app, you need to ensure that your implementation won’t encourage users to click on it accidentally. An example of a violating implementation can be found below (Fig.1):

Fig.1: This interstitial ad implementation violates our policies, as an interstitial launches on the ‘Home Screen’ of the app without any action by the user.

In the example above, an interstitial ad launches while the user is idle on the ‘Home Screen’ of the app. This implementation is in violation of our policies, as interstitial ads should only be implemented at logical breaks in between your app's content . One potential way to fix this violation, without removing the interstitial ad altogether, would be to implement a splash page that launches as the first screen of the app, before the ‘Home Screen’. This page will show while the interstitial ad pre-loads. The Interstitial ad should then launch in the transition between the splash screen and the ‘Home Screen’. You can find an example of this correct implementation below (Fig.2):

Fig.2: This implementation does not violation policy. The first screen the user sees is a splash page, followed by an interstitial. Then, when the user closes the interstitial, they are shown the ‘Home Screen’ of the app.

Now that the user sees that content is loading, they won’t be encouraged to accidentally click on the interstitial ad once it launches. Then, when the user closes the ad, they are shown the ‘Home Screen’ of the app.

NOTE: When the user closes the interstitial ad, they must be shown a new screen. Interstitial ads are only to be implemented at logical breaks in between your app's content, so you can’t have the splash page still be there when the user closes the ad. That would be a policy violation.

To have the interstitial ad trigger at the right time, you may need to preload it. You can find more information about preloading interstitials here. As mentioned, as the developer of your app, the design of your splash page is up to you. The only requirement is that the screen doesn’t contain any elements that might encourage users to accidentally click on the interstitial ad once it launches.

It is important to note that, as a developer, it is your responsibility to ensure compliance with our policies. You can consult our Help Centre for even more helpful information regarding our policies and best practices.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Posted by: Tom Ambrose, AdMob Publisher Quality Team

Source: Inside AdMob


Preloading Interstitial Ads

In today’s topic, we’re exploring how you can help stay compliant with AdMob policies when using the AdMob interstitial ad format. If you have ever received a policy message for “Layout encourages accidental clicks - Interstitial Ads”, or have had trouble with implementing interstitials to trigger on time, read ahead for our best practices.

App layouts that encourage accidental clicks are a common policy issue for publishers. When implementing interstitial ads within a mobile app, there may be a slight delay in when the ad gets triggered after a user selects an action. In the example below we can see that an interstitial ad launches unexpectedly with a delay on the second screen after the page has already loaded. This delay can occur due to carrier latency when requesting the interstitial ad.

Carrier Latency causing a delay in the interstitial ad

Pre-loading your interstitial ads will allow you to avoid latency when the ad is displayed to the user.
In the corrected example below, the user now clicks on a transitional button and an interstitial ad is shown immediately on action. Once the user closes the interstitial ad they will now be on the next loaded page.

Pre-loading the interstitial ad to trigger on action

To learn more about how to preload your interstitial ads, please follow the AdMob Interstitial Ad developer guidelines for apps developed for Android and iOS.

Implementing these ads in the right way is better for your users, advertisers and for you. AdMob policies are designed to create a positive user experience. For further tips on AdMob Interstitial Ads and Best Practices, check out our official best practices video.

Remember to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Posted by: Zac Campbell, AdMob Publisher Quality Team

Source: Inside AdMob


Archiving Ad Units

In today’s topic, we’re going to discuss a feature of the AdMob front-end interface that you may have overlooked in the past: archiving ad units in your apps. When you archive an ad unit, all ad serving and settings associated with the ad unit will be disabled and active campaigns linked to the ad unit may stop running. You’ll no longer be able to access the ad unit from the monetize tab in the AdMob user interface; however, you can still view historical reporting related to that ad unit. It should be noted that you’ll be unable to reverse this process. Once an ad unit has been archived, it will be archived permanently.

It may seem counterintuitive at first. Why archive an ad unit and disable ad serving to your own apps, potentially leaving money on the table? Well, if you're in control of a large portfolio of apps, things aren’t always so simple. Perhaps you no longer have access to your app’s source code, or you have so many apps that it can be difficult to keep track of them all. These “legacy apps” can make it hard to ensure that all of your apps remain compliant. Policy violations that go unfixed can lead to the temporary suspension of your AdMob account.

The easiest way to avoid this issue is to archive any ads in your legacy apps. If your apps aren’t showing ads to users or generating revenue, then they likely aren’t violating AdMob policies. You don’t need to make any changes to the source code in your app, as you can take care of everything in the AdMob front end by following the steps below.

In the AdMob user interface, navigate to “MONETIZE” in the top bar.

You’ll be able to find a list of the apps in your portfolio along the left side of the screen, and clicking on any of them will bring up the app’s ad units.

To archive any of these ad units, select the box beside the ad unit, and then click on “ARCHIVE”.

Once you’ve archived the ads, they’ll stop generating revenue and users will no longer see them. It is important to remember that this is a permanent solution, and archiving cannot be reversed.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Posted by: Tom Ambrose, AdMob Publisher Quality Team

Source: Inside AdMob