Mengelola katalog produk Anda

Panduan ini menjelaskan cara menggunakan Google Play Developer API untuk membuat dan mengelola katalog produk untuk aplikasi Play Anda.

Untuk menjual produk di aplikasi Anda melalui sistem penagihan Google Play, Anda perlu menyiapkan katalog dengan semua produk yang ingin Anda sediakan untuk dibeli oleh pengguna. Hal ini dapat dilakukan melalui Konsol Play, atau Anda dapat mengotomatiskan pengelolaan katalog menggunakan Google Play Developer API. Otomatisasi dapat membantu memastikan katalog Anda selalu terbaru, dan menskalakan ke katalog besar yang koordinasi manualnya tidak praktis. Dalam panduan ini, Anda akan melihat cara menggunakan Play Developer API untuk membuat dan mengelola katalog produk untuk aplikasi Play Anda. Tinjau panduan Bersiap kami untuk mendapatkan petunjuk tentang cara menyiapkan Google Play Developer API untuk integrasi backend Anda.

Catalog Management API

Untuk membaca tentang berbagai jenis produk yang dapat Anda jual dengan sistem penagihan Google Play, baca artikel Memahami jenis produk dalam aplikasi dan pertimbangan katalog. Google menawarkan dua set API utama untuk pengelolaan katalog di Play, yang sesuai dengan dua kategori produk utama:

  • Produk sekali beli
  • Produk langganan

Produk sekali beli

Produk sekali beli (sebelumnya disebut produk dalam aplikasi) menggunakan model objek produk sekali beli yang memungkinkan Anda mengonfigurasi beberapa opsi pembelian dan penawaran untuk produk sekali beli. Model objek produk sekali beli memberi Anda fleksibilitas yang lebih besar dalam cara Anda menjual produk, dan mengurangi kompleksitas pengelolaannya. Produk dalam aplikasi yang ada akan dimigrasikan ke model objek produk sekali beli. Untuk mengetahui informasi selengkapnya, lihat Migrasi produk dalam aplikasi.

Endpoint monetization.onetimeproducts dan inappproducts memungkinkan Anda mengelola produk sekali beli dari backend. Hal ini mencakup pembuatan, pembaruan, dan penghapusan produk, serta pengelolaan harga dan ketersediaan. Bergantung pada cara Anda menangani pembelian produk sekali beli, Anda akan memodelkan produk habis pakai (dapat dibeli berkali-kali sesuai keinginan) atau hak permanen (tidak dapat dilakukan dua kali oleh pengguna yang sama). Anda dapat memutuskan produk sekali beli mana yang harus habis pakai atau tidak.

Produk langganan

Endpoint monetization.subscriptions membantu Anda mengelola produk langganan dari backend developer. Anda dapat melakukan hal-hal seperti membuat, memperbarui, dan menghapus langganan, atau mengontrol ketersediaan dan harga regionalnya. Selain endpoint monetization.subscriptions, kami juga menyediakan monetization.subscriptions.basePlans dan monetization.subscriptions.basePlans.offers untuk masing-masing mengelola paket dasar dan penawaran langganan.

Metode batch

Endpoint onetimeproducts, inappproducts, dan monetization.subscriptions menyediakan sejumlah metode batch yang memungkinkan pengambilan atau pengelolaan hingga 100 entitas dalam aplikasi yang sama secara bersamaan.

Metode batch, jika digunakan dengan toleransi latensi yang diaktifkan, mendukung throughput yang lebih tinggi dan sangat berguna bagi developer katalog besar untuk pembuatan katalog awal atau rekonsiliasi katalog.

Latensi propagasi pembaruan versus throughput

Setelah permintaan pembuatan atau modifikasi produk selesai, perubahan mungkin tidak langsung terlihat oleh pengguna akhir di perangkat mereka karena penundaan pemrosesan backend atau jaringan. Secara default, semua permintaan modifikasi produk sensitif terhadap latensi. Artinya, iklan dioptimalkan untuk propagasi cepat melalui sistem backend, biasanya tercermin di perangkat pengguna akhir dalam beberapa menit. Namun, ada batasan per jam untuk jumlah permintaan modifikasi tersebut. Untuk kasus saat Anda perlu membuat atau memperbarui banyak produk (misalnya, selama pembuatan katalog besar awal), Anda dapat menggunakan metode batch dengan kolom latencyTolerance yang ditetapkan ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Hal ini akan meningkatkan throughput update secara signifikan. Update yang toleran terhadap latensi akan memerlukan waktu hingga 24 jam untuk diterapkan ke perangkat pengguna akhir.

Konfigurasi kuota

Ada beberapa batas kuota yang harus Anda ketahui saat menggunakan Play Developer API untuk mengelola katalog produk:

  1. Google Play Developer API diatur ke dalam kategori yang disebut bucket, dengan setiap bucket memiliki batas kuota per menitnya sendiri. Untuk mengetahui informasi selengkapnya, lihat kuota.
  2. Endpoint modifikasi produk juga menerapkan batas 7.200 kueri per jam. Ini adalah batas tunggal untuk produk sekali beli dan langganan serta untuk semua permintaan modifikasi, termasuk pembuatan, update, aktivasi, penghapusan. Panggilan metode modifikasi batch dihitung sebagai satu kueri untuk kuota ini, terlepas dari jumlah permintaan individual yang disertakan atau sensitivitas latensinya.
  3. Modifikasi yang sensitif terhadap latensi juga memiliki batas 7.200 modifikasi per jam. Untuk metode batch, setiap permintaan modifikasi bertingkat dihitung secara terpisah untuk tujuan kuota ini. Kuota ini hanya memiliki implikasi praktis bagi pengguna batch API yang melakukan update sensitif latensi, karena dalam kasus lain, kuota 2 akan habis sebelum atau pada saat yang sama dengan kuota ini.

Berikut beberapa contoh ilustrasi untuk memahami penggunaan kuota berbagai permintaan:

  • Satu permintaan get untuk mengambil satu item akan menggunakan 1 token kuota 1 dan tidak ada token kuota 2 dan 3 (karena hanya terkait endpoint modifikasi).
  • Permintaan batch get untuk mengambil hingga 100 item juga akan menggunakan 1 token kuota 1 dan tidak menggunakan token kuota 2 dan 3.
  • Satu permintaan modification untuk satu item akan menggunakan 1 token kuota 1 , 1 token kuota 2. Jika permintaan sensitif terhadap latensi, permintaan tersebut juga akan menggunakan 1 token kuota 3. Karena kuota C memiliki batas yang sama dengan kuota 2, hal ini tidak memiliki implikasi praktis bagi pengguna yang hanya menggunakan metode modifikasi tunggal.
  • Permintaan batch modification untuk 100 item yang toleran terhadap latensi akan menggunakan 1 token kuota 1, 1 token kuota 2. Penyiapan kuota ini akan memberikan margin yang cukup untuk menjaga katalog Anda tetap diperbarui, tetapi jika algoritma Anda tidak memperhatikan kuota ini dan melampaui batas ini, Anda mungkin akan mendapatkan error per panggilan tambahan.
  • Permintaan batch modification untuk 100 item yang sensitif terhadap latensi akan menggunakan 1 token kuota 1, 1 token kuota 2, dan 100 token kuota 3.

Rekomendasi penggunaan Catalog Management API

Dengan mematuhi panduan ini, Anda dapat mengoptimalkan interaksi dengan API, sehingga memastikan pengalaman pengelolaan katalog yang lancar dan efisien.

Memantau penggunaan

Anda harus mengetahui proses penggunaan berat. Misalnya, di awal integrasi, endpoint pengelolaan katalog Anda cenderung menggunakan lebih banyak kuota untuk membuat katalog awal lengkap dan hal ini berpotensi memengaruhi penggunaan endpoint lain dalam produksi seperti API status pembelian jika Anda hampir mencapai batas penggunaan keseluruhan. Anda perlu memantau penggunaan kuota untuk memastikan Anda tidak melebihi kuota API. Ada beberapa cara untuk memantau penggunaan. Misalnya, Anda dapat menggunakan dasbor kuota Google Cloud API, atau alat pemantauan API pihak ketiga atau internal lainnya pilihan Anda.

Mengoptimalkan penggunaan kuota API

Sangat disarankan untuk mengoptimalkan konsumsi tarif guna meminimalkan kemungkinan error API. Untuk menerapkan hal ini secara efektif, sebaiknya:

  • Pilih strategi pengelolaan katalog yang tepat. Setelah memahami kuota API, Anda harus memilih strategi yang tepat untuk aplikasi Anda guna mencapai sasaran pengelolaan katalog secara efisien.
  • Lakukan panggilan dalam jumlah minimum yang diperlukan untuk mencerminkan perubahan Anda.
  • Jangan mengirim panggilan modifikasi yang berlebihan atau tidak perlu ke API. Hal ini mungkin mengharuskan Anda menyimpan log perubahan di katalog backend.
  • Tetap berada di bawah batas per jam modifikasi produk,yaitu 7.200 kueri. Anda mungkin ingin membuat proses sinkronisasi yang mengharuskan Anda melakukan sejumlah besar modifikasi produk dalam waktu singkat (misalnya, pembuatan katalog awal). Jika Anda memperkirakan proses ini akan melebihi batas per jam, terapkan penundaan sesuai kebutuhan untuk memperlambat penggunaan ke tingkat yang aman. Pertimbangkan penggunaan metode batch dengan update yang toleran terhadap latensi untuk mencapai throughput yang lebih tinggi.
  • Bersiaplah secara proaktif untuk melakukan penskalaan. Seiring berkembangnya aplikasi, Anda mungkin perlu menskalakan penggunaan API dan berbagai endpoint. Baca dokumentasi kuota Google Play Developer API untuk mengetahui detail cara meningkatkan kuota saat Anda hampir mencapai penggunaan maksimum.
  • Jadwalkan proses berat secara strategis. Coba jadwalkan proses katalog berat Anda di sekitar puncak penggunaan penting, misalnya, Anda dapat menghindari menjalankan sinkronisasi katalog penuh selama waktu penjualan puncak dalam seminggu.

Menambahkan logika penanganan error kuota

Terlepas dari seberapa efisien Anda membangun logika pengelolaan katalog, Anda harus membuatnya tangguh terhadap batas kuota yang tidak terduga, mengingat kuota harian dibagikan oleh endpoint yang digunakan dalam modul independen integrasi Anda. Pastikan Anda menyertakan error pembatasan kuota dalam penanganan error, dan menerapkan penantian yang sesuai. Setiap panggilan yang dilakukan ke Google Play Developer API akan menghasilkan respons. Jika panggilan gagal, Anda akan menerima respons kegagalan yang mencakup kode status respons HTTP dan objek errors, yang memberikan detail lebih lanjut tentang domain error dan pesan debug. Misalnya, jika Anda melebihi batas harian, Anda mungkin mengalami error seperti berikut:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "usageLimits",
    "message" : "Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API
  Console: https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxxx",
  "reason" : "dailyLimitExceeded",
  "extendedHelp" : "https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxx"
  } ],
}

Implementasi pengelolaan katalog

Developer menggunakan endpoint publikasi produk Google Play Developer API untuk menjaga katalog mereka tetap disinkronkan antara backend dan Google Play. Memastikan katalog Google Play Anda selalu diupdate dengan informasi terbaru katalog backend Anda memiliki keuntungan untuk menciptakan pengalaman pengguna yang lebih baik. Contoh:

  • Anda dapat melihat seluruh daftar penawaran yang tersedia, dan mengelola tag penawaran dan paket dasar untuk memengaruhi kelayakan dan logika penayangan penawaran Anda sendiri.
  • Anda dapat memeriksa berbagai titik harga dan detail produk yang dilihat pengguna di berbagai platform, dan memastikan semuanya konsisten.
  • Anda akan memiliki detail produk di backend saat memproses pembelian baru, tanpa perlu meningkatkan latensi dan risiko kegagalan dengan melakukan panggilan tambahan ke Google Play Developer API selama alur penting pengguna.

Ada batasan dan pertimbangan tertentu yang harus Anda perhatikan saat membuat katalog produk di Google Play. Setelah Anda memahami batas ini dan mengetahui cara menyusun katalog, saatnya memutuskan strategi sinkronisasi.

Strategi sinkronisasi katalog

Endpoint publikasi Google Play Developer API memungkinkan Anda melakukan update pada katalog saat terjadi perubahan. Terkadang, Anda mungkin perlu mengambil pendekatan update berkala, dengan mengirimkan serangkaian perubahan dalam proses yang sama. Setiap pendekatan memerlukan pilihan desain yang berbeda. Setiap strategi sinkronisasi akan lebih sesuai untuk beberapa kasus penggunaan dibandingkan yang lain, dan Anda mungkin memiliki serangkaian kebutuhan yang memerlukan keduanya, bergantung pada situasinya. Terkadang Anda mungkin ingin memperbarui produk saat Anda mengetahui adanya perubahan baru, misalnya untuk memproses pembaruan produk mendesak (yaitu harga yang salah perlu dikoreksi sesegera mungkin). Di lain waktu, Anda dapat menggunakan sinkronisasi latar belakang berkala untuk memastikan backend dan katalog Play Anda selalu konsisten. Baca beberapa kasus penggunaan umum saat Anda mungkin ingin menerapkan berbagai strategi pengelolaan katalog ini.

Kapan harus mengirim pembaruan saat katalog lokal Anda berubah

Idealnya, pembaruan harus dilakukan segera setelah ada perubahan pada katalog produk backend Anda untuk meminimalkan perbedaan.

Jenis update ini adalah opsi yang baik jika:

  • Anda harus memastikan bahwa produk Anda selalu yang terbaru.
  • Anda perlu melakukan beberapa perubahan pada produk setiap hari.
  • Anda perlu memperbarui produk yang sudah dalam produksi dan sedang dijual.

Pendekatan ini lebih mudah diterapkan, dan memungkinkan Anda menyinkronkan katalog dengan jendela perbedaan terkecil.

Kapan harus menggunakan update berkala

Pembaruan berkala dijalankan secara asinkron ke edisi produk di backend Anda, dan merupakan opsi yang baik jika:

  • Anda tidak perlu memastikan produk diperbarui dalam waktu singkat.
  • Anda perlu merencanakan pembaruan massal atau proses rekonsiliasi.
  • Anda sudah memiliki Sistem Pengelolaan Konten atau Katalog untuk menangani produk digital, dan sistem tersebut terus memperbarui katalog Anda

Jika katalog besar, pertimbangkan untuk menggunakan metode batch dengan update yang toleran terhadap latensi untuk mencapai throughput maksimum.

Membuat katalog produk

Jika Anda memiliki katalog besar untuk diupload ke Google Play, Anda mungkin ingin mengotomatiskan pemuatan awal. Jenis proses berat ini berfungsi paling baik jika strategi berkala yang dikombinasikan dengan metode batch yang toleran terhadap latensi diikuti.

Membuat produk sekali beli

Untuk pembuatan katalog produk satu kali awal, sebaiknya gunakan monetization.onetimeproducts.batchUpdate atau metode inapp_products.insert dengan kolom allowMissing ditetapkan ke true dan kolom latencyTolerance ditetapkan ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Tindakan ini akan meminimalkan waktu yang diperlukan untuk membuat katalog dalam batas kuota.

Membuat produk langganan

Untuk pembuatan katalog besar langganan awal, sebaiknya gunakan metode monetization.subscriptions.batchUpdate dengan kolom allowMissing disetel ke true dan kolom latencyTolerance disetel ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Tindakan ini akan meminimalkan waktu yang diperlukan untuk membuat katalog dalam batas kuota.

Untuk katalog langganan yang lebih kecil, Play Developer API menyediakan metode monetization.subscriptions.create. Atau, Anda dapat membuat langganan menggunakan metode monetization.subscriptions.patch dengan parameter allowMissing seperti yang dijelaskan di bagian Pembaruan produk.

Semua metode sebelumnya membuat langganan beserta paket dasarnya (disediakan dalam objek Langganan). Paket dasar ini awalnya tidak aktif. Untuk mengelola status paket dasar, Anda dapat menggunakan endpoint monetization.subscriptions.basePlans, termasuk mengaktifkan paket dasar agar tersedia untuk dibeli. Selain itu, endpoint monetization.subscriptions.basePlans.offers memungkinkan Anda membuat dan mengelola penawaran.

Info terbaru produk

Metode berikut memungkinkan Anda mengubah produk yang ada secara efisien, sehingga penawaran Anda selaras dengan penyesuaian terbaru.

Memperbarui produk sekali beli

Metode berikut tersedia untuk membantu Anda memperbarui produk sekali beli yang ada.

  • monetization.onetimeproducts.batchUpdate
  • inappproducts.patch : Endpoint patch digunakan untuk memperbarui resource sebagian. Artinya, Anda dapat memperbarui kolom tertentu yang Anda tentukan dalam isi permintaan. Endpoint patch biasanya digunakan saat Anda hanya perlu memperbarui beberapa kolom resource.
  • inappproducts.update : Endpoint update digunakan untuk memperbarui resource secara keseluruhan. Artinya, Anda harus mengirim seluruh objek resource dalam isi permintaan. Endpoint update biasanya digunakan saat Anda perlu memperbarui semua kolom dalam resource. Jika parameter allowMissing disetel ke true dan ID produk yang diberikan belum ada, endpoint akan menyisipkan produk, bukan gagal.
  • inappproducts.batchUpdate : Ini adalah versi batch dari endpoint update, yang memungkinkan Anda mengubah beberapa produk dengan satu kueri. Gunakan bersama dengan kolom latencyTolerance yang ditetapkan ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT untuk mencapai throughput yang lebih tinggi.

Memperbarui produk langganan

Untuk memperbarui langganan yang ada, Anda dapat menggunakan metode monetization.subscriptions.patch. Metode ini menggunakan parameter wajib berikut:

  • packageName: Nama paket aplikasi yang memiliki langganan.
    • productId: ID produk unik langganan.
  • regionsVersion: Versi konfigurasi region.

Kecuali jika Anda membuat langganan baru menggunakan parameter allowMissing, Anda harus memberikan parameter updateMask. Parameter ini adalah daftar kolom yang dipisahkan koma yang ingin Anda perbarui.

Misalnya, jika Anda hanya ingin memperbarui listingan produk langganan, Anda dapat menentukan kolom listings ke parameter updateMask.

Anda dapat menggunakan monetization.subscriptions.batchUpdate untuk memperbarui beberapa langganan secara bersamaan. Gunakan bersama dengan kolom latencyTolerance yang ditetapkan ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT untuk mencapai throughput yang lebih tinggi.

Untuk mengaktifkan, menonaktifkan, menghapus paket dasar, atau memigrasikan pelanggan ke versi harga paket dasar terbaru, gunakan endpoint monetization.subscriptions.basePlans.

Selain itu, Anda dapat memperbarui penawaran paket dasar dengan metode monetization.subscriptions.basePlans.offers.patch.

Rekonsiliasi katalog

Baik Anda memilih untuk memperbarui katalog Google Play setiap kali katalog backend Anda berubah atau secara berkala, jika Anda memiliki sistem pengelolaan katalog atau database di luar katalog Google Play, ada kemungkinan katalog tersebut tidak sinkron dengan katalog di konfigurasi aplikasi Anda di Play. Hal ini dapat terjadi karena perubahan katalog manual darurat di Konsol, gangguan pada sistem pengelolaan katalog, atau mungkin karena Anda kehilangan data terbaru.

Anda dapat membuat proses rekonsiliasi katalog untuk menghindari jangka waktu perbedaan yang berkepanjangan.

Pertimbangan sistem Diff

Sebaiknya buat sistem perbedaan untuk mendeteksi inkonsistensi dan menyelaraskan kedua sistem. Berikut beberapa hal yang perlu dipertimbangkan saat membuat sistem perbedaan untuk membantu menyelaraskan katalog Anda:

  • Pahami model data: Langkah pertama adalah memahami model data CMS developer dan Google Play Developer API. Hal ini mencakup mengetahui berbagai jenis data yang disimpan di setiap sistem, dan cara berbagai elemen data dipetakan satu sama lain.
  • Tentukan aturan perbedaan: Setelah memahami model data, Anda perlu menentukan aturan perbedaan. Aturan ini akan menentukan cara data di kedua sistem dibandingkan. Misalnya, Anda dapat mencocokkan ID produk dan membandingkan atribut utama langganan dan paket dasar serta penawarannya yang terkait.
  • Terapkan algoritma diff: Setelah menentukan aturan diff, Anda perlu menerapkan algoritma diff. Algoritma ini akan mengambil data dari kedua sistem dan membandingkannya sesuai dengan aturan yang telah Anda tetapkan. Untuk mendapatkan data katalog dari Google Play, Anda dapat menggunakan metode monetization.onetimeproducts.list, monetization.onetimeproducts.batchGet, inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list, dan monetization.subscriptions.batchGet.
  • Buat laporan perbedaan: Algoritma perbedaan akan membuat laporan perbedaan. Laporan ini akan menunjukkan perbedaan antara kedua sistem tersebut.
  • Menyelesaikan perbedaan: Setelah membuat laporan perbedaan, Anda harus menyelesaikan perbedaan tersebut. Hal ini dapat melibatkan pembaruan data di CMS Anda, atau dapat melibatkan pembaruan data di sisi Google Play menggunakan endpoint pengelolaan katalog Developer API, bergantung pada cara Anda biasanya memperbarui katalog. Untuk menyelaraskan produk yang tidak sinkron, gunakan endpoint update seperti yang dijelaskan di bagian Pembaruan produk.

Penghentian produk

Google Play Developer API menyediakan metode berikut untuk membantu Anda menghentikan penggunaan produk:

Untuk produk sekali beli:

Untuk produk langganan:

Penghentian produk mungkin diperlukan dalam berbagai skenario, seperti:

  • Pembuatan secara tidak sengaja.
  • Menghentikan fitur atau layanan.

Sebaiknya sertakan penghentian produk dalam strategi pengelolaan katalog Anda.