In house testing with side-loaded apps is great for isolating and fixing bugs, but it’s not enough. To be certain that your customers are getting the experience you want them to have, you have to test your app against a production environment. 

We’re excited to announce a new tool for mobile developers called Live App Testing. Live App Testing allows you to quickly distribute your apps in the Amazon Appstore to a pre-defined set of testers before you go live.  The testers will be able to sample the full suite of Amazon services - including in-app purchasing - against our production environment, so you can ensure your app is working as expected.  This allows you to gather feedback, improve quality, increase stability and optimize the experience before you push your app live for all customers to download.

What is it?

Live App Testing allows you to create a version of your app that is only distributed to select testers of your choice. You invite testers by adding their email address to Live App Testing.  Once testers are invited to test, they will receive an email with instructions to download the test app and begin testing against Amazon’s production environment.  Only invited testers will be allowed to download and test your app.  As a part of Live App Testing, you can test your apps on any Android or Amazon Fire device.

What does Live App Testing Include?

• Test your app against Amazon production environment before distributing to everyone:  You no longer need to wait until after your app is launched to get real world testing.  You can now distribute your app to a set of testers you define, which gives your more control over the test.  And, you can quickly test against a production environment (yours and Amazon’s), ensuring a higher quality app when you release to the general public.
• Tester Management: Easily define the list of testers you want to be able to test your app.  You don’t need to keep track of who you have invited to test your app.  Amazon takes care of the complexity of ensuring that only the set of testers you defined are the ones that are testing the app.
• Test on all Android and Amazon devices, including Fire TV and Fire phone:  You can choose to test your app against all Android and Amazon devices, including the Fire TV and Fire phone. 

Step by Step guide

1.  Go to the Amazon Developer Portal and select “My apps”. You’ll need to sign into your developer account. If you don’t have one yet, the sign up is easy and it’s completely free.

2.  Select an existing app or click on “Add a New App”.  If “Add a New App” is selected, go to step 3, otherwise, skip to step 4.

3.  After selecting “Add a New App”, select “Android”.  Click next and fill out the New App Submission information.

4.  Select Live App Testing to begin to setup a test for this app.  Once on this page, click on “start your first test run” to begin the process of setting up your first test.

5.  Fill out all of the required tabs

In this step, you will be adding the metadata and the APK that you want to test.

6.  Once you have filled out each tab, you can either submit your app (without assigning testers) or go to the dashboard and add testers.

If you are not ready to add testers at this time, you can select “Submit” and submit the app for publishing.  This process can take up to a few hours.

If you would like to add testers before submitting your app, select “Go to Dashboard” to add testers following the steps below.

7.  On the dashboard, click on “Add Testers” to add testers to the test.

8.  On the testers page, click on “Add Testers”.

9.  Either upload a list of tester email addresses or add the testers individually.  I recommend you add yourself as a tester so you can get the invitation email which will signify that the binary is available to download and test.

10.  Once you add the testers, select save.

11.  You will notice on the dashboard that you have 1 tester assigned to the test.  At this time, select actions (the sprocket icon) and select submit.

You’re all done.  Testers will receive an email to join your test once the app is live.

Managing Your Test

Once your app is running, you can either end your test, or promote your test to an upcoming version.  By promoting your app to an upcoming version, you can make some finishing touches such as upload final screenshots or metadata before going live.

Tests that you have ended will appear on the Live App Testing Dashboard under the “Past Tests” section.

You can also easily see the crashes that have occurred during this test in the Live App testing Dashboard.

Try Live App Testing Yourself

The new Amazon Live App Testing helps you manage testing to help you publish higher quality apps in the Appstore with fewer errors. Creating a new test is easy through the Amazon Developer Portal, at no cost to you. Click here to get started.

Click here to get a free Amazon developer account.

Do you want your app or game to be on the new Fire phone?  Most Android apps already work on Fire phone. Take 90 seconds to find out if your app is ready by using the Amazon App Testing Service. If any incompatibilities are found while testing, you’ll get a detailed report with guidance on how to remedy the situation.

To help you get started, here’s a step-by-step guide and a video that walks you through the process.

1) Go to the developer portal

To start, head over to the developer portal at (https://developer.amazon.com/welcome). All you need is your app’s .APK.

2) Drag your App’s .APK onto the tester

3) Get compatibility test results in 90 seconds

Most Android apps work on Fire mobile devices without change. If the tests do find anything that could prevent publication, you’ll receive specific suggestions and be directed to documentation that will help you make the necessary changes.

4) We’ll also test it on the device

The top section of the results page includes a list of screenshots. Click through them to see what your app looks like on the right.

Below that are sections that show you memory and CPU usage and your log during the test.

5) Now Is the Time to Submit Your Apps for Fire

Once you’re ready to submit your app, begin the submission process by clicking the orange button in the middle of the screen or by going to: https://developer.amazon.com/public/support/submitting-your-app

To submit, you’ll need to sign in. Developer accounts are free so go ahead and make one if you haven’t already.

Create immersive apps that respond to the way a customer holds, views and moves the phone. We have updated Appstore Developer Select and Amazon Mobile Ads API with more incentives:

• Amazon Developer Select: Optimize your apps for Fire phone and get enhanced merchandising and 500,000 Amazon Coins incentives for your customers. Get the details here.

• Amazon Mobile Ads API: Developers earn $6 for every thousand interstitial ads displayed across any supported device in August and September (up to one million impressions per app per month) when they distribute their apps on Fire phones and send the first ad request from a qualified app. Get the details here.

• Amazon App Testing Service: Most Android apps just work on Amazon devices. Test your app's compatibility in 90 seconds by dragging and dropping your Android APK into our testing tool. Sign up for a free developer account to test your app's look and feel on devices and get the results within 6 hours. Test your app now.

Now is the time to submit your apps and games! Apps that are submitted by July 18 and approved will be in the Amazon Appstore when Fire ships on July 25.

Fire Developer Resources:

Get a free Amazon Appstore developer account

Fire Getting Started Guide

SDK downloads

@PaulCutsinger

Our A/B Testing service just added support for A/B/n tests, allowing more than two variations in a single experiment. This feature makes it even easier to quickly optimize your app in the field—without having to republish your APK. A/B/n testing saves you time since one experiment can now test up to five variations at once.

For example, suppose you have four ideas for how to label a Buy button – Buy, Purchase, Add to Cart, and Get it Now! – and want to know which label leads to the most purchases. You start by setting up an A/B test as you normally would (if you’re new to A/B testing on mobile, learn more about getting started) and click Add Variation for each new variation:

A/B/n testing saves time, since standard A/B testing of four variations would require completing multiple A/B tests one after the other. The experiment above, for example, would require three separate tests, with the winning test becoming the new control each time.

A/B/n testing lets you compare all four variations at once, so only one test is necessary:

When planning an A/B test it is important to consider the size of the daily active user base you want to affect and how long you can wait for the test to complete. If a variation’s slice of the data is small, the A/B test may take a long time to achieve statistical significance. Apps with a large audience can likely distribute most customers to Variation A (Control) without sacrificing test time or significance. Apps with a smaller audience will want to distribute tests evenly across all variations as shown below:

After you identify the winning variation, the A/B Testing service allows you to launch it to customers with a simple button click on the Mobile App Distribution Portal. There’s no need to republish your app. You can simply indicate which variation the service should distribute to customers from now on.

If you’re an Android developer, explore this update to the free Amazon A/B Testing service. We’re interested in hearing your feedback on A/B Testing. Please take this short survey to help us improve the service.

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.

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.

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)

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.

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

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.

It’s no secret that customer satisfaction is key to Amazon’s success. It’s something we obsess about, and we constantly tweak everything from product selection to payment options to website design. We experiment, we measure, and we decide whether or not a change improves the user experience. One of the most powerful tools at our disposal is something we call a Web Lab, which allows us to test two (or more) different versions of a webpage, or roll out a new feature to a limited audience.

Perhaps this concept is less familiar to mobile application and game developers than to those who write web code, but it shouldn’t be. In fact, it’s so useful and important that Amazon’s A/B Testing service was one of the first we made available to mobile developers (If you haven’t tried the service yet, check out Getting Started with A/B Testing for a quick introduction).

Now a significant enhancement has just been released: Segmentation offers greater flexibility and control over who sees your experiments, allowing you to limit your tests to a set of users based on any dimensions you care to associate with them.

User dimensions

A “dimension” in this sense is simply a named characteristic whose value is a number or a bit of text. The UserProfile singleton object manages the dimensions you define, keeping track of their values for the current user. It’s these values that determine whether the current user is a member of a particular segment, and it’s entirely up to you how they are chosen, named, and initialized.

For example, say I want to test a new wine feature in my restaurant review app. I don’t want everyone to see it—just my beta testers—so I define a dimension called “isBetaTester” and initialize it based on some information I know about the current user:

        // Determine if the current user is actually participating in the beta,

        // based on my own definition of “participating.”

        boolean isBetaTester = validateUserAsBetaTester();

        // Set the dimension for the current user.

        UserProfile.addDimensionAsString("isBetaTester", String.valueOf(isBetaTester));

        // Initialize the Insights SDK to enable A/B Testing.

        AmazonInsights.withApplicationKey(MY_APPLICATION_KEY)

                      .withPrivateKey(MY_PRIVATE_KEY)

                      .withContext(getApplicationContext())

                      .initialize();

                 . . .

In this case, validateUserAsBetaTester() is a helper method I define to assist me in deciding whether the current user is a beta tester or not. This could be a preferences setting, or perhaps a check against an email whitelist.  Regardless, I’m responsible for setting the value, which I do before initializing the A/B Testing system.

Create a segment

Now that I’ve established a dimension to differentiate users, I need to define a segment that actually refers to it. The segment may be associated with any A/B test, limiting access to users who match (or don’t match) along the relevant dimension. From the Amazon Mobile App Distribution Portal, I navigate to the A/B Testing tab of my app, then click Add a New Segment.

Next, I fill in the segment information, paying special attention to the dimension information, since that must correspond to the name (“isBetaTester”) and type (String) I use in my application. In this case, I define a segment called “Beta Testers” that will include anyone whose isBetaTester dimension is a string equal to “true”:

Limit a test

With a segment defined, I can now use it to limit the scope of an A/B test. Let’s say I want to experiment with the length of user-submitted wine reviews. (I’d like to give people more space, but have to balance the storage required against the benefit of more detailed content.) When I create the test, the last setting allows me to specify the user segment I want to target. In this case, I choose my beta testers, whom I just identified:

When the test is started, beta users will begin to see variations of wineReviewLen, subject to the distribution I specify.  In my app, I can initialize a variable with the maximum allowable review length for the current user:

        ABTest.getVariationsByProjectNames("Wine Reviews")

            .withVariationListener("Wine Reviews", new VariationListener() {

                public void onVariationAvailable(Variation variation) {

                    maxReviewLen = variation.getVariableAsInt("wineReviewLen", 256);

                }

            });

For users outside the Beta Testers segment, the control variation will always be allocated. However, these users will never be included when the results of the experiment are calculated.

Complex segment criteria

In this simple example, a single boolean value was enough to distinguish segment members, but segmentation supports much more complicated criteria. You can easily attach more than one variable or change how variables are evaluated. String equality works as demonstrated (numeric equality is identical), but it’s also possible to create a segment based on a numeric range or set membership.

For example, perhaps I want to further segment my beta testers by those who have made a past purchase. I can create a numeric value called purchasesToDate and define the valid range as any non-zero value—note that I just have to start at 0 (exclusive) and omit the upper bound:

If I wanted to create a segment of customers in the Pacific Northwest, but only those who have used the app in 2012 or 2013, I could combine two tests for set membership:

Important note: users retain the variation they are initially allocated, even if their dimensions change later on.  This means that once a user has been identified as a member of one segment, they never move to another for the duration of the test, even if their dimensions change. This ensures a consistent experience; significant changes to features or interface could be jarring. (If a new test is started, the dimensions will be re-evaluated.)

That’s it!

Setting up segments is simple and adds a lot of flexibility to your experiments.  Give it a try the next time you’re considering A/B testing.  For information, be sure to check out the Insights documentation.

Login with Amazon is now available to developers to integrate in their mobile apps and websites. The new service lets you take advantage of the same user authentication system used by Amazon.com.  Login with Amazon allows you to securely recognize millions of Amazon customers and provide them with a personalized user experience.  For example, you can greet visitors by their name or display customized offers based on their zip code.

Login with Amazon uses the OAuth 2.0 protocol making it easy for you to integrate it in your app or website. Developers who have previously worked with the OAuth 2.0 protocol will find the terms and concepts straightforward and consistent with other implementations. 

How does Login with Amazon work?

1. The user visits your website or app and clicks the Login with Amazon button.
2. The user is presented with a login screen hosted on Amazon.com.
3. The user enters their Amazon credentials.  First-time users will see a consent screen hosted on Amazon.com to grant your site permission to specific pieces of information.
4. After the user consents, your app will be able to securely access customer profile data (name, email, zip code) to create a new user account and provide a personalized user experience for them.

Login with Amazon SDKs are available in public beta for Android, Kindle Fire, and iOS. To integrate the service in your app or website, go to login.amazon.com to register a developer account, download the SDKs, and view the Getting Started Guides.

Login with Amazon adds yet another capability for mobile app developers.  Now, developers can use Amazon Web Services (AWS) for its infrastructure (e.g., compute, storage, and database). For those interested in building cloud-backed apps, you can read more about it here.

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.
   
   



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



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



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



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.

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

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" />

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

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

4. 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();

3. 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.
   
   

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

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.

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.

You may have seen the news that our store is expanding to nearly 200 countries. As we grow, we continue to focus on developer success around the world. We’ll be spotlighting developers from countries in which we operate here on our blog over the next few months.  First, we take you to the UK, where just six months after the launch of the store on Kindle Fire in October 2012, British developers and publishers are already seeing some impressive results.

Kent-based P2 Games publishes titles based on popular children’s character licenses, including Peppa Pig (the UK’s leading pre-school franchise), Fireman Sam, and Bob the Builder.  P2 Games was already successful before Kindle Fire launched in the UK, but saw sales quickly grow once the store launched in their home market. 

Peter Sleeman, Director of P2 Games, spoke with us about the success they are experiencing on Amazon.  As he notes, ‘’The popular children’s brands we build apps for were already well-represented on Amazon. For example, they sell Peppa Pig products across multiple product categories, such as Toys, Books, Video Games, and DVDs. It made sense to try to reach these same customers with our apps, particularly given the Kindle Fire is such a family-friendly device. Through our conversations with Amazon, we were aware of the demand for our apps, information gleaned from customers’ actively searching for Peppa Pig titles.’’

Although P2’s Peppa Pig Apps have already been downloaded more than one million times since launching in September 2010, they achieved some terrific results just months after the launch of our store in the UK. 

Peter Sleeman continues, ‘’We launched our first Kindle Fire version in January 2013 and within a few weeks we saw sales on Amazon overtake Google Play by a factor of four or five times. Kindle Fire is now a legitimate contender, and although our apps have been out much longer on iOS formats, our current rate of sale is close to parity with iOS most days in the UK. The launch of our newest paid Android app, Peppa Pig Party Time, in March 2013 has followed in the footsteps of previous titles and is proving very successful. ’’

For P2 Games, these results have changed the way they develop for Android.  Peter told us that, ‘’Our success on the Kindle Fire has been game-changing; our Android development efforts now lead with the Kindle Fire version. We’re really excited to have a number of our other key titles in development for release on Kindle Fire later this year.’’

Publishers like P2 Games tell us that one of the reasons they are turning to Amazon is because it monetizes so well. P2 Games is just one of thousands of UK-based developers and publishers that have already experienced the value of connecting with Amazon customers on mobile devices, and are reaping the rewards of distributing apps on Kindle Fire.  Developers benefit when customers find the apps that interest them through behavioral recommendations and buy ‘friction free’ through 1-Click purchase.