Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The State of In-app Purchases on Android

The State of In-app Purchases on Android

At the end of the day, what pays the bills is not the amount of RxJava operators you've used, or how cool your Kotlin code looks compared to what you had with Java. What pays the bills is the money you (or the company you work for) earn. As such, join me on a journey that will assess and assert what it means to sell in-app products on Android today, and what it means for the business. We will understand several aspects of their implementation, testing, A/B testing and monitoring, as well as highlighting what we can look forward to in the future.

This talk was presented at Droidcon IT 2018:
http://it.droidcon.com/2018/talks/266/
https://www.youtube.com/watch?v=weDi0HaY9XM

Keynote format: https://drive.google.com/open?id=1o8ubvBz07pNmvTwFcR59qJ0HfuyA_UDC

Sebastiano Gottardo

April 20, 2018
Tweet

More Decks by Sebastiano Gottardo

Other Decks in Technology

Transcript

  1. 29 March 2011 In-app Billing Launched on Android Market 10

    December 2012 In-App Billing Version 3 12 June 2017 New Google Play Billing Library (DP) 19 September 2017 Google Play Billing Library 1.0 released
  2. In-app billing — High level Basic requirement an Android device

    that has billing capabilities In-app Billing Service IInAppBillingService.aidl Libraries
  3. In-App Billing Version 3 isBillingSupported() isBillingSupportedExtra…() 
 getSkuDetails() getBuyIntent() consumePurchase()

    getBuyIntentToReplaceSkus() getBuyIntentExtraParams() getPurchases() getPurchaseHistory()
  4. ✔ Simple to understand ✘ Synchronous! ✘ No type-safety ✘

    Service connection In-App Billing Version 3
  5. PBL — The good and the meh ✔ Less chances

    of errors ✔ Comes with updated samples ✔ Proper support for multiple platforms ✔ Better (and updated) documentation ✘ Not open-source ✘ Not really streamlined
  6. anjlab/ android-inapp-billing-v3 Open-source and actively developed Good wrapper over bare

    service calls Handling of some edge cases A lightweight implementation of Android In-app Billing Version 3
  7. Real purchases 1. Your app is published (i.e., not in

    draft). 2. The APK must be published (either production, alpha or beta channels). 3. The APK you uploaded matches the one you’re testing with when it comes to version code, version name, and keystore signature. 4. When testing on the device, you’re using a different account than the one tied to the Play Console (i.e., not your developer account). 5. The instructions to wait 15 minutes are a bit too optimistic, as it can take up to 2 hours for changes to propagate from the Play Console. 6. Double check that the SKU you’re using in the app matches the one for the product that was configured in the Play Console. 7. Double check that you’re not trying to purchase an already owned product or an already active subscription. 8. Double check that you have activated your products in the Play Console: by default, products in the console are deactivated and you need to manually activate them. 9. If you’re using the alpha/beta channels, make sure that the account you’re testing with is part of the testing group (i.e., has clicked on “Become a tester” after following the opt-in URL). 10.If you use ABI flavors, like arm-v7, arm-v8, etc., make sure the APK you’re using for testing contains all the ABI libraries. 11.Make sure that, when retrieving the Intent using getBuyIntent, you’re passing the correct product type, i.e., inapp if you’re purchasing managed in-app products or subs if you’re purchasing subscriptions. 12.If you’re using the public key for enhanced security, make sure it matches the one on the Play Console because it might change over time (see here). 13.Check that Google Play Services are updated on the test device by going to the Google Play Services page on the Play Store.
  8. “Fake” purchases Production subscription period Test subscription renewal 1 week

    5 minutes 1 month 5 minutes 3 months 10 minutes 6 months 15 minutes 1 year 30 minutes Max renewals per sub: 6 times
  9. NYT’s Register Fake implementation of the billing service Configuration via

    JSON (+ companion app) Removes existing limitations Allows integration tests to be easily ran
  10. No platform support Android does not offer support for price

    chances If done wrong, it’s disastrous for the user Complicated to handle … and yet
  11. A/B testing infrastructure Create multiple products in the console Have

    meaningful product IDs Serve products via a custom configuration
  12. A/B $$$ - The good and the meh ✔ Test

    different price points ✔ Shared configuration across platforms ✔ Shared logic (with tests) ✔ Flexible ✘ (Very) Complicated to achieve ✘ Can be abused (country lock, tests within tests)
  13. Monitoring subscriptions How are your subscriptions performing over time? What

    are your top subscriptions? How do you acquire these subscriptions? How well do you retain these subscriptions? Why did users cancel these subscriptions?
  14. Subscriptions ! Promo codes not available No easy way of

    testing Discounts only with Web API
  15. #