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

Transcript

1. The State of In-app Purchases on Android Sebastiano Gottardo
2. IS HIRING
3. “Sometimes all you need is a billion dollars”
4. How can we make money on Android?
5. In-app products Subscriptions Managed Products
6. Managed Products One-off payments Each app can offer different products Consumable and non-consumable
7. Subscriptions Recurring billing Multiple subscriptions (w/ upgrade/downgrade) Auto-renewed
8. Subscriptions Multiple billing periods Recurring payment Managed Products One-off payment Consumable Non-consumable Non-consumable In-app products
9. In-app products Product ID (SKU) Unique
10. Implementing in-app billing
11. 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
12. In-app billing — High level Basic requirement an Android device that has billing capabilities In-app Billing Service IInAppBillingService.aidl Libraries
13. In-App Billing Version 3 isBillingSupported() isBillingSupportedExtra…() 
 getSkuDetails() getBuyIntent() consumePurchase() getBuyIntentToReplaceSkus() getBuyIntentExtraParams() getPurchases() getPurchaseHistory()
14. ✔ Simple to understand ✘ Synchronous! ✘ No type-safety ✘ Service connection In-App Billing Version 3
15. The Play Billing Library (PBL) Replaces… nothing Maintained by Google Offers convenient access to IAB APIs
16. PBL components PBL BillingClient BillingClientStateListener PurchasesUpdateListener
17. PBL components PBL BillingClient newBuilder() setListener(PurchasesUpdateListener) startConnection(ClientStateListener) querySkuDetailsAsync(…,listener) queryPurchases() queryPurchaseHistoryAsync(listener) consumeAsync(listener) launchBillingFlow()
18. 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
19. “I wish this library came out 4 months ago” Me, June 2017
20. 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
21. in-app billing Testing
22. Why testing?
23. OH PLEASE
24. Testing in-app products Static responses Real purchases Fake (money, for real) purchases
25. Static responses Use reserved product IDs Response is automatic No need for the app to be on the store
26. Static responses android.test.purchased android.test.canceled android.test.refunded android.test.item_unavailable
27. Static responses … cannot be used with subscriptions
28. Real purchases Require a published app (alpha/beta/prod) The real deal, with real money Hideous setup
29. 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.
30. Real purchases http://bit.ly/2EJqoXt
31. Testing setup
32. “Fake” purchases License testers No money circulates Constraints in duration and renewal
33. “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
34. NYT’s Register Fake implementation of the billing service Configuration via JSON (+ companion app) Removes existing limitations Allows integration tests to be easily ran
35. NYT’s Register
36. NYT’s Register … not yet compatible with PBL ! PRs welcome "
37. A/B testing price points
39. 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
40. “There is something we can do”
41. “There is something we can do” Me, a few months ago
42. A/B testing infrastructure Create multiple products in the console Have meaningful product IDs Serve products via a custom configuration
43. 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)
44. Monitoring
45. Google Play Console
46. Order management
47. Order management
48. Revenues
49. 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?
50. Limitations
51.  still has the upper hand All-around control Reliable sandbox environment Better promotion tools
52. Subscriptions ! Promo codes not available No easy way of testing Discounts only with Web API
53. #
54. @rotxed