Appstore Blogs

Appstore Blogs

Want the latest?

appstore topics

Recent Posts

Archive

Showing posts by Mike Hines

August 21, 2013

Mike Hines

As readers of this blog, you probably already know that Kindle Fire devices run Android. While these devices may not look like Android because we use an Amazon-designed launcher, they are Android indeed. The original Kindle Fire released in 2011 runs Gingerbread (API level 10) and the Kindle Fire devices released in 2012 run Ice Cream Sandwich (API level 15).

What you may not know is how easy it is to get your existing Android apps up and running in the Amazon Appstore on Kindle Fire and other Android devices. We recently tested more than 1,600 app submissions to the Amazon Appstore Android tablet apps on Kindle Fire. In our tests we found that more than 75% of these apps just work on Kindle Fire devices with no additional development required.

While some developers may choose to just submit their Android apps, others may also decide to integrate Amazon APIs like In-App Purchasing, GameCircle or Mobile Ads to provide a richer customer experience and monetization.

We’ve seen Android apps like ‘Match the Pics’ take minutes to get submitted to Amazon and others like ‘Temple Run’ easily integrate Amazon APIs with their apps.

“Publishing our content on the Amazon Appstore was extremely easy since our Android games just worked on Kindle Fire. Creating the developer account and submitting the first app for review took a matter of minutes, and the app got published the next day.”        Appoh

"We've integrated with Amazon's In-App Purchasing and GameCircle APIs, which was a breeze. We've seen significantly higher customer engagement with Temple Run since the integration, making the few, short steps worth it.”         Imangi

You may be asking, why don’t 100% of Android APKs submitted run on Kindle Fire? Of the minority that doesn’t get to the store on their first try, some reasons for failure are:

  1. App functionality doesn’t match the product description. We’ve found that this is the top reason.
  2. For apps designed to run on phones, the app loses state or data when it receives a message or phone call. The app should preserve its state when receiving or placing text messages and phone calls.
  3. The icons don’t match. Sometimes, the icons submitted in the developer portal don’t match the icons included in the application. They need to match.
  4. App stability or failure to launch. One in 20 of the app failures is stability related. For example, because the SD card path is not necessarily the same for all devices, assumptions about the SD card path can cause failures. Another common example is failing to include referenced libraries.
  5. Not replacing unsupported APIs with the Amazon equivalent API.
  6. Security. One example we’ve seen is writing plain-text login credentials to the log. Apps need to be secure for customers.
     

Since your app will most likely just work with zero development effort in the Amazon Appstore, it seems like a no-brainer to create a developer account – at zero cost - and submit your app. Take a look at what one of Amazon’s Appstore developers says about how easy it is to set up your account and submit your Android app.

Some of the details went by fairly quickly in the video. Here’s a comparison summary of the assets in a Google Play submission and how they transfer to an Amazon Appstore submission.

It’s really not hard to have your app fly through testing. Just open a developer account on the Amazon Mobile App Distribution Portal today. You can then start submitting your existing APKs to the Amazon store, exposing them to new customers in nearly 200 countries worldwide.

Click here to get started.

August 15, 2013

Mike Hines

Note: Effective 08-26-2015 Free App of the Day (FAD) has been replaced with Amazon Underground.

Occasionally, we'll have a developer ask if the financial benefit of participating in the FAD program is worth it. Will it help them ultimately grow their app revenue?

Below is a guest post by Tasharen Entertainment, a small independent developer in Toronto that created Starlink – a strategy game – available in the Amazon Appstore, Google Play and the Apple App Store. They recently issued a blog post highlighting their success with the Free App of the Day program and we thought we’d share it with you.  It’s always compelling to see a developer try something new, measure the actual results across several app stores and find out their test was successful. The article was originally posted on Tasharen’s blog post here.


Starlink has recently participated in the Free App of the Day promotion on the Amazon App Store. Before joining the promotion I did my research, and saw that there was some controversy about it, but I went for it anyway. Two weeks later, I am happy to share the results.

With Starlink being a rather obscure strategy game released with zero marketing a few months ago, its player base has been expectedly small: of the 2500 players before the promotion, around 80% were pirates who got it for free. Number of daily players was around 100 — which was actually a fairly high percentage, all things considered. The sales died down quickly after the release. I think the “best” day earned around $65 in sales, but the average daily income since release has been around $10 — a rather sad amount. Nonetheless, factoring the fact that Starlink is a first game I’ve released on the mobile platforms, and that an average first-time release is only expected to earn around $500 during its lifetime, Starlink’s ~$1400 lifetime income was actually already ahead of the curve.

Enter the Amazon’s Free App of the Day promotion. The process was started by Amazon themselves who got in touch with me and asked if I’d be interested — I said of course. After some emails back and forth, the date was assigned: July 19th — a Friday. Perfect for a game!

On that day, over 102,000 players have downloaded the game. North American rating of the game averaged at 3.5/5, with the majority being along the lines of “I don’t get it”, complaining about the sparse tutorial and the game being too difficult even on the beginner difficulty. Curiously enough, Japanese players rated the game 4.5/5.0 (over 7500 downloads). Apparently Japanese players had an easier time understanding an English-language game than native English speakers!

After the promotion I wanted to wait two weeks to see the effect the promotion would have on the sales of the game on all of the platforms it was available on. Now, keep in mind. I myself did nothing. I didn’t say the app would be promoted, didn’t release any news about it, no new videos, nothing! I wanted to see the raw effect the promotion would have. Some of you may go “wtf” at this, but keep in mind — Starlink for me is, and always has been — an experiment. My goal has never been to make it the next Angry Birds, but to experiment with the different platforms, methods of monetization, cross-promotion, etc.

So here is the raw effect of the promotion. Before the 19th, the statistics looked like this:

  • Amazon sales: 3 units per week
  • Google sales: 5 unit per day
  • iOS sales: 1 unit per day
  • Daily players: ~100

Two weeks later, the statistics seem a lot healthier:

  • Amazon sales: 34.5 units per day (almost 8,000% increase)
  • Google sales: 22 per day (340% increase)
  • iOS sales: 10.2 per day (920% increase)
  • Daily players: 2,041 (almost 2,000% increase at exactly 2 weeks after promotion)

Total estimated income for the 2 week period immediately following the promotion: $1,385, or almost the same amount of money they game has earned in the 3 months leading up to the promotion.

  • $646 from Amazon
  • $464 from Google
  • $186 from iOS
  • $69 from Desura
  • $20 from PayPal

So the obvious question is — from my point of view, was the promotion worth it?

And the answer is a resounding “Yes“! And if you are an indie dev who’s considering participating in the Amazon’s Free App of the Day, here’s a small suggestion for you: don’t concern yourself with the players who will obtain your game for free. Instead, think of all the players that will follow and will buy your game based on the attention it will receive and the word-of-mouth talk that will follow.

Or in other words, think of it as free marketing done right.

Thanks, Amazon!


If you have an interesting story or experience to share with other developers through a guest post on our blog, email us at mobile-app-marketing(at)amazon.com for consideration.

August 14, 2013

Mike Hines

We’ve gotten a few questions recently about Adobe AIR support on Kindle Fire. Here is the quick FAQ:

Do Kindle Fire devices have Adobe AIR embedded?

Yes.

The Original Kindle Fire has Adobe AIR 2.7.1 embedded as a Shared Runtime. The Kindle Fire, Kindle Fire 7” HD, and the Kindle Fire 8.9” HD devices (the Kindle Fire devices running ICS) all have Shared Runtime support for Adobe AIR 3.1.

Can I use a newer version of AIR for my app?

Yes.

The current version of Flash Builder includes support for Captive Runtime, a way that you can package the most recent version of Adobe Air with your app. Everything you app needs to run is packaged directly into the apk. Note: The ADT –package command is now packaging AIR 3.7 and higher as a Captive Runtime by default. See this note from Adobe for more details.

Does Kindle Fire have any Adobe AIR Native Extensions (ANEs)?

Yes.

We have two free Adobe AIR Native Extensions for the Kindle Fire. One for In-App Purchasing, and another for GameCircle integration. You can read the press release here.

 

August 08, 2013

Mike Hines

Join us at the MoDevTablet, Aug 15-17 in Seattle! MoDevTablet is a unique mobile conference event dedicated to tablet design, development, marketing strategies and training. Attending will be more than 30 mobile leaders from Amazon, Rovio, Samsung, Major League Soccer, Microsoft, and others. This should be a good opportunity to learn from some big names that have been doing tablet development for a while, and a good chance to network with hundreds of your peers.

The three day event features:

  • Deep-dive workshops featuring essential tablet design, content, and cross-platfrom development strategies from industry experts, including Amazon's own Mike Hines who will share Amazon’s experience testing thousands of tablet apps.
  • An exclusive sneak peek at the upcoming edition of Angry Birds Star Wars (Episode 1) — a month before the public sees it.
  • Keynotes and industry insights from across the mobile ecosystem.
  • A high-stakes startup competition, Disruptathon, featuring the best mobile startups from Seattle, Portland, and Vancouver squaring off for over $10,000 in prizes.

See the full schedule and speaker list at http://modevtablet.com. Save an additional 25% on your registration with code AMZN13.

 

August 06, 2013

Mike Hines

Starting today, you can submit your web apps and mobile optimized web sites and have them merchandised alongside native apps on Amazon and Kindle Fire in nearly 200 countries worldwide, without any third-party software or doing any native app development. Amazon Web App Resources (http://developer.amazon.com/webapps) provides the tools that you need to optimize your web apps for Kindle Fire and Android devices to sell them in our store, including powerful tools to help you test and debug your web apps and monetize using Amazon’s In-App Purchasing API for JavaScript. Plus, we’ve made sure your web apps achieve native-like performance on Kindle Fire with our new fast web runtime, based on the Chromium engine.

Rialto

Tools

To make sure your web app works great on Kindle Fire and Android devices, you can use the Web App Tester, which you can get from our store here. The Web App Tester allows you to test your web app in a production-like environment before submitting it to Amazon, and offers a suite of tools to help with on-device debugging of your web apps, ensuring that they’ll work great on Android and Kindle Fire.

We’ve also created and made available the Amazon In-App Purchasing API for JavaScript, allowing you to easily build sales of digital goods like gems, level unlocks, and subscriptions into your web apps.

Kindle Fire web runtime

Kindle Fire’s web runtime is based on the open source Chromium project, and is GPU-accelerated and optimized for fluidity to make sure your web apps run smooth on Kindle Fire, just like a native app. The new runtime supports the latest HTML5/web features and includes standards-based extensions that give you access to offline storage and location sensors. Read more about the updated web app runtime here.

Get started today

Web developers with HTML5 apps and mobile-optimized web sites can easily get started at the Amazon Mobile App Distribution Portal. Once you’re logged in, go to “My Apps”, hover over the green “Add New App” button and click “Add new Web App”.  More information on how to prepare and submit your web apps is available here.

August 05, 2013

Mike Hines

In previous posts, we’ve touched on the eCPM benefits and ease of implementation of the Amazon Mobile Ads service. But easy to implement doesn’t mean inflexible. We’d like to cover some easy ways you can do Ad Targeting.

In addition to being able to specify the ad unit size, there are a number of targeting options you can include in the request that's sent to the Amazon Mobile Ad Network.

The properties you can send to get more accurately targeted ads are:

 Property

 Argument

 UserGender

 MALE | FEMALE

 GeoLocation

 true
 [this will return current lat/long position to Amazon, and you must declare  coarse_location and fine_location in you permissions request.]

 Age

 integer

For example, to get ads that are better suited to 35 year-old males in the use’s specific region, do the following:

public void onCreate(Bundle savedInstanceState) {
   ...
    AdTargetingOptions adOptions = new AdTargetingOptions();
    adOptions.enableGeoLocation(true);
    adOptions.setGender(AdTargetingOptions.Gender.MALE);
    adOptions.setAge(35);

}

Easy, isn’t it.

You can also customize the floor price for the ads you receive. For example, if you want to get ads that will pay no less than $0.85 per thousand ads returned, you can do that by setting Advanced Option “ec” to 850000 micro-dollars.

For example, add the following line to the example above:

adOptions.setAdvancedOption(“ec”, “850000”);

and you will only get ads with CPM => $0.85. 

Note: The Amazon Mobile Ad Network is designed to maximize your revenue opportunity at the default setting. Setting a floor price may limit your revenue potential as it might prevent several paid campaigns from running on your placement. Amazon recommends not setting this value.

You can also specify a list of advertiser names, advertiser product categories, or URLs that aren't appropriate for your customers. Use the restrictions page under the Settings menu item in your dev portal. Please note that blocking ads may negatively impact your revenue and fill rates, and restrictions currently apply to all of your apps with ads. 

How do you see your results? That’s easy too. Check it out on the Mobile App Distribution Portal Dashboard (your dev portal home page), or by clicking on Reporting and selecting either Mobile Ads Performance to see:

  • Requests
  • Impressions
  • Fill rates
  • Click-through rates (CTR)
  • Revenue per thousand impressions (RPM)
  • Earnings

 

Or you can click on Mobile Ads Payments to see payments dispersed.

We’re happy that we’ve been able to make targeting Amazon Mobile Ads easy and straightforward. Click here to see the Mobile Ads API video and to get the Mobile App SDK. We hope you’ll give it a try in your app today.

 

June 19, 2013

Mike Hines

I had to take a class in accounting before I understood the difference between sales and earnings. Fortunately, learning about Amazon Mobile App Distribution Program sales and earnings reporting is quite a bit simpler than that accounting class. 

While there are 7 possible reports to choose from, in this blog post, we’ll cover three popular financial reports:

  • Sales reports – show basic sales less returns over customizable time periods and countries.
  • Earnings reports – show more details (including adjustments) in a fixed one-month period.
  • Payment Reports – show you what you are actually paid every month.

Sales Reports show trends in sales and returns over standard or custom time periods. You can get daily breakdowns in CSV reports, and you can see sales broken out by individual marketplace or by the almost 200 countries in which you app could be sold. Data in sales reports are updated every few hours but do not reflect processed financial data for the current month. They do not include adjustments and other data that will affect your payment.

Below are two examples of reporting that can be customized by app and international marketplace. The first is a map view. Note the drop-down buttons for ‘Date’, ‘All Apps’ and ‘All Marketplaces’. These let you show a specific date range and show sales by marketplace (like amazon.co.uk or amazon.fr) or by the country (such as Brasil or Norway).

The next example shows a tabular view of the Sales report with detail such as Units Sold, Units Returned, Units Refunded and Gross Revenue.

Sales Report

Sales Summary

Earnings Reports represent the sales, refunds, app earnings and adjustment data used to calculate royalties earned during a given month. Data in earnings reports are released on a monthly basis once royalties earned in the previous month have been processed and approved. Monthly summary information is available in the Amazon Mobile App Distribution Portal and daily breakdowns are available through CSV export.

Earnings Report

Payment Reports represent the actual disbursement of funds from Amazon. Monthly summary information is available in the Amazon Mobile App Distribution Portal on the payment reports section.

Accessing Reports Getting these reports is easy. Log in to the Amazon Portal and click on the Reporting link (shown below). Then select the report you want, then select your customization filters below that.

(Note: of the seven reports shown in the screen shot below, all but the Beta Engagement report now allow reporting by country of sale)

Accessing Reports

The Amazon Moblie App Distribution Program gives you useful reporting data that is pretty easy to access and understand. My accounting teacher would be proud. Try getting a few reports now, and see how easy it is to get data on your apps today.

June 14, 2013

Mike Hines

Recent news has many users increasingly concerned about privacy, and we know that your customer’s privacy is as important to you as it is to us. That’s why it’s important that you include links to your privacy policy on the product detail pages for your apps.

We require all apps that collect personally identifiable information or personal information to provide a link to their privacy policy, so if you haven’t already done so, please take a moment to submit the privacy policy link for each of your apps today. It’s quick, simple, and it’s also the right thing to do.

Please follow these steps to update the product detail page for your app with a link to your privacy policy:

  1. Sign into the Amazon Mobile App Distribution Portal with your developer account
  2. Go to the My Apps page then click on your app name
  3. Click on Edit in the bottom right corner of the page
  4. Add a link to your privacy policy in the Privacy Policy URL field, then click Save

Privacy Matters

Once you have followed the steps above and added a link to your privacy policy, the link will show up on your app’s product detail page.

June 13, 2013

Mike Hines

If you have decided on publishing an interactive periodical title, congratulations! Having an interactive periodical means that users can scroll articles on a page, play a music sample, manipulate a map, or otherwise interact with your content in ways that are just not possible with static content. While interactive publications are more work than simply rendering a PDF replica of your print publication, they are often well worth the extra effort. Interaction can drive deeper engagement with the content, more time per page, better reader usage reporting and other advertiser-friendly benefits.

In this two-part series on Interactive Periodical Publishing on Kindle Fire I will discuss some of the technical considerations for those who will write their own periodical application or who will use a publication platform such as Woodwing or Adobe. The first part introduces thoughts on layouts, resolutions and interactions, and part two will cover how to submit your periodical app to the Amazon Appstore to minimize time investment on your end and optimize user experience.

A 10,000 Foot View of Layouts

If your content is text-centric, you can look into using a fluid layout (Liquid Layout) design. The Wall Street Journal app for Android and iOS uses a set of relative layout templates into which the daily text of the newspaper flows. Once your templates are set, you can simply stream content and the templates handle the layout.

WSJ

WSJ can flow text into templates easily

If your periodical is image-heavy, or you wish to exercise more exacting creative control, you can probably constrain your digital layout work to two fixed aspect ratio layouts, one for the 4:3 aspect ratio iOS tablets, and another 16:9 layout for Android tablets. True, not all Android tablets are 16:10, but if you are comfortable with a small amount of letterboxing, non-standard devices can be accommodated. 

Table 1

Wired Magazine Layout

WIRED Magazine has precise layout needs

Working with Resolutions

Publication platforms like those from Adobe can take a specific layout from InDesign and generate multiple renditions in which you can bundle images that are specific to the screen resolution of the target device. This can help reduce total package size and reduce asset scaling artifacts. Other platforms ask that you submit the largest assets you have, and will then scale down the assets to match the screen resolution of the target device. If you write your own app, you can make either choice, or even stream appropriate images to your app if your application returns the properties of the device on which is it running. If you do write your own app, please be aware that periodicals are often read in both landscape and portrait orientations. Your app should accommodate accordingly.

Building Interactions

If you are creating your own app, you can use just about anything you want to create interactions; Native code, Java, HTML, even HTML5. If you are using a platform like Adobe, you still have a fair amount of flexibility within the scope of the tools and webkit provided by the platform. In either case, be aware that the code you put onto any single page will use heap memory, and if you cache multiple heavy pages at the same time, you could find yourself running short on memory and fighting with the garbage collector should you ever hit onPause(). Avoiding this usually requires coordination between the content folks (who usually don’t think about heap size) and the IT group (who usually don’t think about editorial requirements). If you can flatten some of your non-interactive elements to PDF, you can save a good deal on file size and memory usage.

That covers (at a very high level) some of the important considerations to keep in mind when designing your periodical app. The next installment of this series will cover submitting your app to the Amazon Appstore, setting up In-App-Purchasing for subscriptions and individual issue sales and more.

 

June 12, 2013

Mike Hines

It’s easy to see how hackathons can spawn creative teams and fantastic ideas, but I’ve also seen great ideas die because bad pitches sink good hacks.

In a Hackathon event like AngelHack, developers, designers and entrepreneurs gather on a Saturday morning to mingle and meet like-minded folks, form teams, and decide on a cool project to work on. These teams will then spend all night building the project they design. Sunday afternoon, it’s pencils down time, and the teams get between 3 and 5 minutes to present what they’ve done to a panel of judges, who in the case of AngelHack, will decide who to send to the Bay Area to meet with venture capitalists for potential funding.

To be sure, hackathons are won with great hacks. Liam Boogar, hackathon judge and the brains behind rudebaguette.com, says “For me, people win hackathons with awesome hacks, not thoroughly thought out business models. A business model is a means to justify the long-term growth of an amazing product - without the amazing product, the business model is useless.”

Point well made. No business or presentation wizardry will save your team if you have a worthless hack, but a great hack that understands the business end will beat a great hack that doesn’t. 

Questions You Need to Answer:

The good news is that communicating the business side is as easy as addressing these 5 questions:

  1. Who is going to use your app and what is their need?
  2. How does your hack address that need? (this is where you demo your awesome hack)
  3. How does the user acquire the solution? (if the monetization approach is clever, demo it here)
  4. Is your hack unique? How is it unique?
  5. Can the hack be scaled to be a viable business?

Most teams miss one or more of the points above, and a few teams miss all of them. So even if you copy/paste this list to a document, write the answers underneath, and then read that doc to the judges, you’ll be doing better than most. (Seriously, don’t worry if you’re not a great public speaker. At one event, a team whose speaker read the entire presentation from his laptop still progressed to the finals because it was a good hack and the judges understood the business.)

Building the Demo:

Once you have answers to the 5 questions above, it’s time to build the presentation and demo. This does not have to be complicated, and it shouldn’t take long. Here is some guidance from AngelHack judges:

PowerPoint or not? Some teams use a slide deck, some don’t. I’ve seen valuable and impactful presentations done both ways.  Just make sure you demo what you have built. I was on a judging panel where the team showed only slides. Great business model, but the hack was completely missing. That did not turn out well!

Demo the hard part. Most solutions have easy parts and hard parts. Rendering a simple list on the screen isn’t a hard part. Getting the correct data to render often is. If you try to hand-wave your way around the hard problems, you’re in trouble. Don’t show loading screens or other trivial stuff. Liza Kindred, AngelHack Judge and founder of Third Wave Fashion, says via Twitter: “We don't want to watch you log in! Have it ready to go, your three minutes are too short!”

Tell a story. If you can, weave the points above into a story.   Here is how one team used a story to weave in a lot of points in short time:

One speaker told a story about how his grandmother couldn’t respond to text messages even though she wanted to stay in touch more often (Question 1, time: 15 seconds). He showed the hack, demonstrating how their project removed the barriers that prevent the elderly from using technology (Question 2, time: 2 minutes). The speaker described the ways that grandma might come to own their product (Question 3, time: 20 seconds). 

The only part of their message they didn’t weave into a story was their product’s differentiating factors and how they scale to be a viable business. Whether or not the judges agreed that this was the right solution for helping grandma doesn’t matter. We all remembered the story. We talked about the story. Stories work.

If you can’t tell a story.  Some projects or some teams just don’t work with stories. That’s okay. You’ll just need the discipline to avoid detail overload when outlining your points. Good hacks can get great scores even without a story.

Discuss what you built over the weekend. Rebecca Lovell, CEO at Vittana.org, says: “We want to know what you were actually able to accomplish over the weekend. If it's an existing company and you built a Kindle app, tell us. If you just thought of the whole idea this weekend, we'll be duly impressed with whatever you were able to hack over such a short period of time.  Above all: be transparent with the status of your product development and achievements.”

Presentation Time Management Tips

As long as you end up covering all of your points, you’ll have a good demo. These tips are designed to help you make sure you can get your message across in what seems like no time at all.

  • Practice your presentation. For goodness sake, practice the whole thing, end to end, with demo components. You’ve only got 3-5 minutes to pitch your hack at these events. Many teams fail to complete their presentation due to poor time management. Practicing will help alleviate this.
  • Leave enough time to demo your hack. …and then be sure to demo the hard stuff, not splash pages, loading screens, or login dialogs. I’d suggest leaving no less than half your time to demo the hack. I’ve seen speakers go into so much detail describing how they built the solution that they leave only 30 seconds to show it!  We need to see the great hack if you’re going to win a hackathon.
  • More than your name may not matter. Don’t spend time with introductions longer than your first name unless it’s describing experience directly relevant to the project.
  • Don’t let your knowledge hurt you. When you have a great deal of domain expertise, it’s easy to get caught up in details that may be important, but not necessarily relevant for a short pitch.
  • Be prepared for unmitigated disaster.  At one hackathon, there were some technical problems with the HDMI cable to the room projector, and it flustered some folks so much that they didn’t do as well as they might have otherwise. Be ready to walk a device around to the judges if you have to.
  • Practice your presentation. I’ve seen at least a dozen teams plan how they will do their presentation and call that practicing. It’s not. Rehearsing in your head is not practicing either. Actually finding a place to speak the whole thing quietly to a teammate is practicing. Just 10 to 15 minutes will make a big difference.
  • Have Fun! Rebecca at Vittana.org says: “We know you're sleep deprived and hopped up on Red Bull, but make sure to sell it!  Show your passion!”

So, after all is said and done, you need a great hack to win a hackathon. And the great hack that clearly communicates business basics will beat a great hack that doesn’t.

Before Mike Hines was a Technical Evangelist for Amazon, he founded a financial services company and an education software company. Join Mike Hines and Amazon at the Silicon Valley AngelHack in San Jose, CA on June 15 and 16. You can follow Mike on Twitter @MikeFHines

 

June 03, 2013

Mike Hines

Starting today, customers can now buy apps and games directly from PCs and Macs for their Android phones, tablets, and Kindle Fire. You can now reach the millions of customers visiting Amazon.co.jp, either by automatically being included in recommendations on product detail pages or product search results, or featured on the Amazon Appstore for Android web storefront. Plus, you can now directly link to your app or game to promote its availability on Amazon.co.jp—learn more about linking to your apps and games on Amazon here.

This comes on the heels of our recent announcements of the opening of our store in nearly 200 countries worldwide, and Kindle Fire HD becoming available for pre-order in those countries as well. The shop is open today, and available at www.amazon.co.jp/apps.

 

May 28, 2013

Mike Hines

The Amazon A/B Testing service is an effective tool to increase user engagement and monetization. It allows you to set-up two in-app experiences (each of which is presented to a different group of users) and evaluate the success of each, based on criteria you establish. Another, less obvious, use of the A/B testing service is feature timing. It’s easy to turn on a new feature at a specific time, or release a series of features on a schedule. You can do it in four simple steps, which I walk through here:

  1. Creating a new A/B project and launch used for releasing a feature
  2. Integrating the SDK and API into your Android app
  3. Adding the Java code necessary to enable your feature based on the A/B launch
  4. Releasing your feature via Amazon’s A/B Testing portal

Step 1: Creating a new A/B project and launch used for releasing a feature

Using the Amazon A/B Testing service requires an Amazon developer account and an Android app associated with the account. If you don’t already have a developer account you can sign up here. The first step for using Amazon’s A/B Testing to release a feature is to create an A/B launch used to determine whether the feature in your app is hidden from users or accessible by them. Once signed into your developer account the following steps can be used to accomplish this:

  1. Navigate into your app. Click “My Apps” on the navigation bar of the Mobile App Distribution Portal to access your list of apps.
  2. On the detail page of your app, click the “A/B Testing” link as shown below.

    App Detail Page


  3. A screen displaying your list of A/B projects is displayed. Click “Add a New Project”.

    Amazon A/B Testing Page


  4. Enter a title and description that indicates this test is used for the launch of a specific feature and click “Save Project”.

    Add A/B Testing Create Project Page


  5. Click “Add a New Launch” on the detail page of the project you just created.

    A/B Testing Project Detail Page


  6. We are now looking at the page for creating an A/B launch. Enter a name and description that indicates this is used for a feature release. For the variable, we create a boolean that tracks whether the feature is enabled. The old variation is set to false and the new version is set to true. Make sure to keep the old variation set to 100% of the distribution. This means all users of your app will not have the feature enabled when you check this A/B launch’s variable. Click “Save” to add your A/B launch.

A/B Launch Creation Page

  1. Click the “Start” button on the newly created A/B launch to make it available for use.

List of A/B Items under the Project

Step 2: Integrating the SDK and API into your Android app

We now have an A/B launch containing a corresponding variable for determining whether our feature is made available. The next step is to integrate the A/B Testing SDK into our app using the following steps so we can write code to obtain whether the feature is made available.

  1. Download the Amazon A/B Testing SDK from here.
  2. Set the required permissions INTERNET and ACCESS_NETWORK_STATE in your AndroidManifest.xml file.

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

  1. Add the Amazon Insights Processing Service to your AndroidManifest.xml.

<application>
    ...
    <service android:name="com.amazon.insights.InsightsProcessingService" />
</application>

  1. Add the AmazonInsights Android SDK jar and all 3 AWS Android jars to your Android project.  These jars can be found in the libs folder of the SDK download.
     

Step 3: Adding the Java code necessary to enable your feature based on the A/B launch

With the SDK setup its time to add code to either make our feature hidden or available based on the variable we configured for our A/B launch. The steps below detail the code needed for accomplishing this.

  1. Import Amazon Insights in to your code.

    import com.amazon.insights.*;

  2. Initialize the Amazon Insights SDK in the onCreate method of your Activity. Note: Your application key and private key can be found on the Amazon A/B Testing page for your application where we created the A/B project in step 1.

AmazonInsights

    .withApplicationKey(YOUR_APPLICATION_KEY)
    .withPrivateKey(YOUR_PRIVATE_KEY)
    .withContext(getApplicationContext())
    .initialize();

  1. Add code to enable the feature based on the A/B launch variable.  We obtain our A/B launch variable and check whether we should enable access to the feature.

//Get our “Feature Launch - FeatureName” experiment and retrieve the variable
//for whether the feature is made available.
ABTest
   .getVariationsByProjectNames("Feature Launch - FeatureName")
   .withVariationListener("Feature Launch - FeatureName", new VariationListener() {
      public void onVariationAvailable(Variation variation) {
         boolean featureNameEnabled = variation. getVariableAsBoolean(
            "FeatureName_IsLive", false);
         if (featureNameEnabled) {
            enableFeatureName();
         }
    }
});

 Step 4: Releasing your feature via Amazon’s A/B Testing portal

With your app now supporting the release of the feature, the final step is to make your feature available at the appropriate time. This can be done completely via the Amazon A/B Testing portal and doesn’t require an APK update with the feature enabled. To launch the feature use the following steps:

  1. Navigate back to the A/B launch experiment you created for your app’s feature release. This is accessible by clicking the “A/B Testing” link on your app’s detail page. Next click on the current experiment for our feature launch A/B project as displayed by Image 8 below.

    App Detail Page

A/B Project List

  1. Click the “Edit” tab to change the distrubtion of the variable we use to determine if the feature should be made available.

    A/B Launch Detail Page

When the Launch was created the distribution was set to 100% to the “Old Version”. Change the distribution of the new variation to 100%. All users of your app are going to receive true for the variable used to enable your feature. Click “Save Launch” and your feature will now be live for all users. 

In some scenarios you might want to incrementally release a new feature over time. This can beneficial when releasing features for which scaling might be a concern. For example,  you can use Launch to safely increase the percentage of customers receiving the feature while you monitor the scalability of your service.   If a problem is detected you can stop incrementing the release or in an extreme case pull it back.

A/B Launch Edit Page

That is all it takes to support releasing a feature via Amazon A/B Testing in your Amazon app. You can find more information the Amazon A/B Testing service here.

 

May 24, 2013

Mike Hines

Today we announced Engagement Reports, a free zero-integration service that provides data on app usage. This has been a popular request from developers, who want to better understand how customers interact with their apps. Engagement Reports include daily and monthly active devices, installs, sessions, average revenue per device, and retention. Each report can be filtered by marketplace, viewed in chart form, or downloaded as a CSV.

You can find the Engagement Reports within the “Reporting” tab of the Mobile App Distribution Portal. The full list of Engagement Reports is:

  • Overview: A summary of key usage data for your app or game
  • Average Revenue: Daily and Monthly Average Revenue per Device (ARPD) and Average Revenue per Paid User (ARPPU) for In-App Items
  • Retention: Daily Retention for days 1-3-7 and Weekly Retention for weeks 1-2-3
  • Active Devices: Daily Active Devices (DAD), Monthly Active Devices (MAD), and Sticky Factor (DAD/MAD)
  • Sessions: Total Daily Sessions and Average Sessions Per Device
  • App Installs: Daily Installs and Uninstalls

Engagement Reports are available for apps submitted and published after October 25, 2012. If you haven’t updated your app since then, you’ll need to republish or submit an update before data can be collected. No other action is required. Engagement Reports include data from the Kindle Fire HD, the new Kindle Fire, and Android devices that use the latest version of our store.

 How to access and view your Engagement Reports

From within the Distribution Portal, you can access Engagement Reports by selecting “Reporting” (1) and then “Engagementbeta” (2). Or, click here to go directly to Engagement Reports.

Engagement Reports are separated into three sections. (3) Criteria Selection: Allows you to select the app, date range, and marketplace. Engagement Reports default to your first app in an alphabetically sorted list and display the most recent 14 days of data. (4) Report Selection: Allows you to select from five different reports: Overview, Active Devices, Sessions, ARPD (In-App Items), and Retention. (5) The Overview report highlights key performance metrics such as Daily Active Devices and 1-Day Retention across a selectable date range and lifetime totals for your app or game.

Criteria Selection, Report Selection, Overview report

The example image below shows the Active Devices report (6) with a graph of Daily Active Devices (DAD) and Monthly Active Devices (MAD) over a 14 day period.

Active Devices report, FAQ

Developers that want to learn more about each report, including how data is collected, can review the Engagement Reports FAQ (7).

We encourage you to explore Engagement Reports and provide feedback via the “Send Feedback” link on the Engagement Reports page.

May 23, 2013

Mike Hines

As of today, customers can buy your apps on Amazon in nearly 200 countries worldwide using online and mobile stores in the US, Canada, Germany, France, Spain, and Italy. It was also announced that Kindle Fire HD is available for pre-order starting today, shipping to over 170 countries on June 13. This is a great opportunity for you to reach millions of new customers who can now discover your apps and games online through the Amazon website and on Android and Kindle Fire HD devices. This launch expands developer reach and monetization potential to Amazon customers around the world. For more information see the press release here.

It’s easy to make your apps available in all of these countries. If you are creating a new app, it will be available in all countries by default. You can select country and territory availability for each of your apps if you want to limit their availability. First, go to the Availability and Pricing tab in the distribution portal then select “Only in the following countries…” at the top of the page. You’ll see a list of continents that you can expand to make your selection. The number of countries you have selected in this manner will show up in parenthesis at the continent level. You can set the list price for your apps for each marketplace where Amazon sells apps, or you can have Amazon calculate a list price for you automatically using your base list price. Finally, to help report on all of this international goodness, your sales reporting now reflects your sales by country.

Please be sure to check that your existing apps are for sale in the countries in which you wish them to be sold, and have fun in all the new countries!

(See the International Program Overview FAQ here for more details.)

May 21, 2013

Mike Hines

Amazon Device Messaging, a free service that allows you to send cloud-based push notifications to Kindle Fire customers, is now out of Beta and is in general availability.

You can use ADM to send encrypted real-time notification to update users on breaking news or let them know that a new game task is available for them to complete. You can also use ADM for instant messaging functionality or social networking notifications within your app.

Messaging Overview

  • Deployment. We have documentation, sample code, tools, and FAQs to help you integrate ADM. Adding ADM to your app is easy. You obtain your ADM credentials and key (remember, this is an encrypted message), include the ADM library as an external JAR file, update your manifest, store your key as an asset, and implement your broadcast receiver. (we have sample code that shows this). To send a message, your server needs the app registration ID and a security token. You can find more implementation details here.
  • Simple. ADM delivers message data to your app on the device, and your app can decide what to do on receipt of that data like download content or display a notice. Your message should be no greater than 6KB in size and sent in the form of JSONObject key:value pairs.
  • Delivery. Messages expiration is one week by default, but can be configured to persist for one month if required. ADM will wake up the device to deliver messages, so messages can be sent and received during off-peak hours when the device is likely to be asleep. We use Amazon Web Services as a backend for this service, so we can scale up quickly and reliably.
  • Compatibility. ADM is supported on Kindle Fire HD 8.9" 4G, Kindle Fire HD 8.9", Kindle Fire HD 7", and Kindle Fire (2nd Generation) devices.
  • Free. Enough said.

Getting Started

Get started with Amazon Device Messaging by downloading the SDK here and reviewing our documentation, sample code, and FAQs. Submit your ADM-enabled app through the Amazon Amazon Mobile App Distribution Portal today!

Feedback from the Beta

During the ADM beta, we had big and small companies try the service, and we got international developer feedback as well. Here is some of the feedback we received:

From Wooga, a social game developer based in Berlin:

“The decision to integrate Amazon Device Messaging into Diamond Dash was a cinch – it is a clear win”, said Soenke Bullerdiek, Senior Manager Strategic Platform Partnerships, from Wooga, “Even better, it was easy to enable and only took a few days of work to start sending push notifications to our users.”

From Gameloft, a world-wide game developer based in the U.S.:

“We decided to use Amazon Device Messaging as a new way to engage our Oregon Trail American Settlers customers on Kindle Fire.  The documentation and sample code was easy to understand for our studios.” Baudouin Corman, VP Americas Gameloft.

Want the latest?

appstore topics

Recent Posts

Archive