31 Aug 2015
Posted by Lily Sheringham, Developer Marketing at Google Play
Editor's note: A few weeks ago we shared some tips from game developer, Seriously, on how they've been using notifications successfully to drive ongoing engagement. This week, we're sharing tips from Christian Calderon at US game developer, Dots, on how to successfully optimize your Play Store Listing. -Ed.
A well thought-out Google Play store listing can significantly improve the discoverability of your app or game and drive installations. With the recent launch of Store Listing Experiments on the Google Play Developer Console, you can now conduct A/B tests on the text and graphics of your store listing page and use the data to make more informed decisions.
Dots is a US-founded game developer which released the popular game, Dots, and its addictive sequel, TwoDots. Dots used its store listings to showcase its brands and improve conversions by letting players know what to expect.
Christian Calderon, Head of Marketing for Dots, shared his top tips with us on store listings and visibility on Google Play.
Do's and Don'ts for optimizing store listings on Google Play
|Do be creative and unique with the icon. Try to visually convince the user that your product is interesting and in alignment with what they are looking for.
||Don't spam keywords in your app title. Keep the title short, original and thoughtful and keep your brand in mind when representing your product offering.
|Do remember to quickly respond to reviews and implement a scalable strategy to incorporate feedback into your product offering. App ratings are important social proof that your product is well liked.
||Don't overload the 'short description'. Keep it concise. It should be used as a call-to-action to address your product's core value proposition and invite the user to install the application. Remember to consider SEO best practices.
|Do invest in a strong overall paid and organic acquisition strategy. More downloads will make your product seem more credible to users, increasing the likeliness that a user will install your app.
||Don't overuse text in your screenshots. They should create a visual narrative for what's in your game and help users visualize your product offering, using localization where possible.
|Do link your Google Play store listing to your website, social media accounts, press releases and any of your consumer-facing channels that may drive organic visibility to your target market. This can impact your search positioning.
||Don't have a negative, too short or confusing message in your "What's New" copy. Let users know what updates, product changes or bug fixes have been implemented in new versions. Keep your copy buoyant, informative, concise and clear.
|Do use Video Visualization to narrate the core value proposition. For TwoDots, our highest converting videos consist of gameplay, showcasing features and events within the game that let the player know exactly what to expect.
||Don't flood the user with information in the page description. Keep the body of the page description organized and concise and test different structural patterns that works best for you and your product!
Use Google Play Store Listing Experiments to increase your installs
As part of the 100 Days of Google Dev video series, Kobi Glick from the Google Play team explains how to test different graphics and text on your app or game's Play Store listing to increase conversions using the new Store Listing Experiments feature in the Developer Console.
Find out more about using Store Listing Experiments to turn more of your visits into installs.
31 Aug 2015 5:05pm GMT
27 Aug 2015
Posted by Josh Gordon, Developer Advocate
Today we're releasing the Desktop Head Unit (DHU), a new testing tool for Android Auto developers. The DHU enables your workstation to act as an Android Auto head unit that emulates the in-car experience for testing purposes. Once you've installed the DHU, you can test your Android Auto apps by connecting your phone and workstation via USB. Your phone will behave as if it's connected to a car. Your app is displayed on the workstation, the same as it's displayed on a car.
|The DHU runs on your workstation.||Your phone runs the Android Auto companion app.|
Now you can test pre-released versions of your app in a production-like environment, without having to work from your car. With the release of the DHU, the previous simulators are deprecated, but will be supported for a short period prior to being officially removed.
You'll need an Android phone running Lollipop or higher, with the Android Auto companion app installed. Compile your Auto app and install it on your phone.
Install the DHU
Install the DHU on your workstation by opening the SDK Manager and downloading it from
Extras > Android Auto Desktop Head Unit emulator. The DHU will be installed in the
Running the DHU
Be sure your phone and workstation are connected via USB.
- Enable Android Auto developer mode by starting the Android Auto companion app and tapping on the header image 10 times. This is a one-time step.
- Start the head unit server in the companion app by clicking on the context menu, and selecting "Start head unit server". This option only appears after developer mode is enabled. A notification appears to show the server is running.
Start the head unit server in the Android Auto companion app before starting the DHU on your workstation. You'll see a notification when the head unit server is running.
- On your workstation, set up port forwarding using ADB to allow the DHU to connect to the head unit server running on your phone. Open a terminal and type
adb forward tcp:5277 tcp:5277. Don't forget this step!
- Start the DHU.
On Linux or OSX:
At this point the DHU will launch on your workstation, and your phone will enter Android Auto mode. Check out the developer guide for more info. We hope you enjoy using the DHU!
27 Aug 2015 5:36pm GMT
Posted by Ian Lake, Developer Advocate
Android devices do a lot, whether it is taking pictures, getting directions or making phone calls. With all of this functionality comes a large amount of very sensitive user data including contacts, calendar appointments, current location, and more. This sensitive information is protected by permissions, which each app must have before being able to access the data. Android 6.0 Marshmallow introduces one of the largest changes to the permissions model with the addition of runtime permissions, a new permission model that replaces the existing install time permissions model when you target API 23 and the app is running on an Android 6.0+ device.
Runtime permissions give your app the ability to control when and with what context you'll ask for permissions. This means that users installing your app from Google Play will not be required to accept a list of permissions before installing your app, making it easy for users to get directly into your app. It also means that if your app adds new permissions, app updates will not be blocked until the user accepts the new permissions. Instead, your app can ask for the newly added runtime permissions as needed.
Finding the right time to ask for runtime permissions has an important impact on your app's user experience. We've gathered a number of design patterns in our new Permission design guidelines including best practices around when to request permissions, how to explain why permissions are needed, and how to handle permissions being denied.
In many cases, you can avoid permissions altogether by using the existing intents system to utilize other existing specialized apps rather than building a full experience within your app. An example of this is using
ACTION_IMAGE_CAPTURE to start an existing camera app the user is familiar with rather than building your own camera experience. Learn more about permissions versus intents.
However, if you do need a runtime permission, there's a number of tools to help you. Checking for whether your app has a permission is possible with
ContextCompat.checkSelfPermission() (available as part of revision 23 of the support-v4 library for backward compatibility) and requesting permissions can be done with
requestPermissions(), bringing up the system controlled permissions dialog to allow the user to grant you the requested permission(s) if you don't already have them. Keep in mind that users can revoke permissions at any time through the system settings so you should always check permissions every time.
A special note should be made around
shouldShowRequestPermissionRationale(). This method returns true if the user has denied your permission request at least once yet have not selected the 'Don't ask again' option (which appears the second or later time the permission dialog appears). This gives you an opportunity to provide additional education around the feature and why you need the given permission. Learn more about explaining why the app needs permissions.
Read through the design guidelines and our developer guide for all of the details in getting your app ready for Android 6.0 and runtime permissions. Making it easy to install your app and providing context around accessing user's sensitive data are key changes you can make to build better apps.
27 Aug 2015 4:51pm GMT