Tag Archives: Policy

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.

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

How to Resolve Google Play Policy Issues

From time to time, you may encounter Google Play policy issues with your apps. The Google Play policy team has been working hard to provide you with the resources and support you need to resolve policy issues.

If the app review team notices a policy issue with your app or app update, you’ll receive an email with the subject line “Notification from Google Play.” (If you didn’t receive this email, make sure to update your email address on the account details page in your Developer Console.)

The policy notification email includes the policy your app violated and the steps you need to take to resolve the issue. If your app is rejected, you can fix the issue and submit the app again for another review - you don’t need to reach out to the policy support team.

If you disagree with a policy violation, or if you’d like help resolving your policy issue, you can always contact our support team. Simply use the contact details in the notification email or click on the question mark at the bottom of each page in the Developer Policy Center.

For the quickest response, make sure to include your package name. As soon as you submit the form, you’ll receive an automated response with a case number in the subject line. This means your appeal has been submitted successfully. A specialist will review your case and respond to you within 72 hours.

If you’d like to learn more about Google Play policy, check out the “10 tips to stay on the right side of Google Play policy” video on the Android Developers YouTube channel or below.

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

Posted by Chris Jones, Social Team, AdMob.

Source: Inside AdMob

10 Tips to Stay on The Right Side of Google Play Policy

In a previous blog post, we introduced the Google Play Developer Policy Center. To go along with making the policies more accessible and useful to developers, the policy team has created an engaging video to help developers stay on the right side of Google Play policy.

Here are the 10 tips to stay on the right side of Google Play policy;

Review the Policy Center: It’s recommended that you review the Policy Center whenever you're unsure if your app violates policy.

Describe your app appropriately: Take the time to describe your app appropriately in order to avoid metadata policy violations. Remember that every translation of your app description needs to be compliant with the metadata policy.

Use images you have the rights to: Your app icon and any graphic assets in your Store Listing should only include images you have the rights to use. If you have been granted permission to use assets owned by others, you can notify the app review team using this form. Make sure that all text and images used in your Store Listing are appropriate for app lovers of all ages.

Rate your app accurately: When answering the content rating questionnaire, it’s important to provide accurate responses in order to receive an accurate rating.

Handle user data with care: User data can include information provided by a user, collected about a user, or collected about a user’s interactions with the app or device. If your app is collecting personal or sensitive user data, you’ll need to handle it securely and include a privacy policy in your Store Listing and in your app.

Make sure ads in your app are policy compliant: Ad behavior should be straightforward - it’s against policy to show ads that are disruptive or deceptive, including ads that pose as system notifications, ads that aren’t dismissible, or ads that appear after a user closes the app. Additionally, ad content in your app should not include adult images, violence, or anything else that would violate the restricted content policy. You may want to check with your ad provider to learn about filtering options.

Don’t forget the restricted content policy: Check your app and your Store Listing for any restricted content, such as adult content, violence, or drugs. If you're concerned about any content in your app, read through the restricted content policy for more details and examples. If any content in your app is user-generated, you’ll need to take additional precautions in order to provide a policy compliant app experience. Check out the user generated content policy to learn more.

Update your email preferences: Make sure to update your email address on the account details page in your Developer Console. That way, if a policy issue does come up, we can contact you with the steps to address it.

Fix any policy issues found in review: Even though you’ve checked your app against the policies, it’s always possible that your app gets rejected or suspended after review. If your app or app update gets rejected, keep in mind that many violations can be fixed! Just follow the steps in the “Notification from Google Play” email you received.

Reach out to us for support: If you disagree with a policy violation, or if you’d like help resolving your policy issue, you can contact our policy support team.

In the next blog post, we’ll talk more about our enforcement process and policy support resources.

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

Posted by Chris Jones, Social Team, AdMob.

Source: Inside AdMob