Mengelola katalog produk Anda

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

Untuk menjual produk di aplikasi melalui sistem penagihan Google Play, Anda memerlukan untuk menyiapkan katalog yang berisi semua produk yang ingin Anda sediakan oleh pengguna untuk dibeli. 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 dapat diskalakan ke katalog besar di mana koordinasi manual tidak praktis. Dalam panduan ini, Anda akan melihat cara menggunakan Play Developer API untuk membuat dan mengelola katalog produk untuk aplikasi Play. Tinjau panduan Persiapan kami untuk mendapatkan petunjuk tentang cara menyiapkan Google Play Developer API untuk integrasi backend Anda.

Katalog Management API

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

• Produk sekali beli
• Produk langganan

Produk sekali beli

Endpoint inappproducts memungkinkan Anda mengelola satu kali dari backend Anda. Termasuk membuat, memperbarui, dan menghapus produk, dan mengelola harga dan ketersediaan. Bergantung pada cara Anda menangani pembelian produk sekali beli, Anda akan membuat model produk habis pakai (dapat dibeli sebanyak yang diinginkan) atau produk hak (tidak dapat dilakukan dua kali oleh pengguna yang sama). Anda dapat memutuskan produk sekali beli harus dapat dikonsumsi atau tidak.

Produk langganan

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

Metode batch

inappproducts dan monetization.subscriptions endpoint menyediakan sejumlah metode batch yang memungkinkan pengambilan atau pengelolaan ke 100 entity di aplikasi yang sama secara bersamaan.

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

Memperbarui latensi propagasi versus throughput

Setelah permintaan pembuatan atau modifikasi produk selesai, perubahan mungkin tidak terlihat langsung oleh pengguna akhir di perangkat mereka karena jaringan atau backend pemrosesan yang tertunda. Secara default, semua permintaan modifikasi produk bersifat sensitif terhadap latensi. Artinya dan dioptimalkan untuk propagasi cepat melalui sistem backend, biasanya diterapkan di perangkat pengguna akhir dalam hitungan menit. Namun, ada batas per jam terkait jumlah permintaan modifikasi tersebut. Jika Anda perlu membuat atau memperbarui banyak produk (misalnya, selama pembuatan katalog besar awal), Anda dapat menggunakan metode batch dengan latencyTolerancekolom ditetapkan ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Tindakan 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 perlu Anda ketahui saat menggunakan Developer Play API untuk mengelola katalog produk Anda:

1. Google Play Developer API memiliki batas default 200.000 kueri per mereka. Batas kuota ini berlaku untuk agregasi penggunaan di semua endpoint, termasuk API pengelolaan katalog.
2. Endpoint perubahan produk juga menerapkan batas 7.200 kueri per dalam jam kerja lokal mereka. Ini adalah batasan tunggal untuk produk sekali beli dan langganan dan di semua permintaan modifikasi, termasuk pembuatan, update, pengaktifan, hapus. Panggilan metode modifikasi batch dihitung sebagai satu kueri untuk kuota ini, terlepas dari jumlah permintaan individual yang disertakan atau latensinya sensitivitas.
3. Modifikasi yang sensitif terhadap latensi juga memiliki batas 7.200 modifikasi per jam. Untuk metode batch, setiap permintaan modifikasi bertingkat akan dihitung secara terpisah untuk tujuan kuota ini. Kuota ini berisi praktik implikasi hanya untuk pengguna batch API yang melakukan latensi yang sensitif pembaruan, seperti dalam kasus lainnya, kuota 2 akan habis sebelum atau pada saat yang sama sebanyak kuota ini.

Berikut adalah beberapa contoh ilustratif untuk memahami penggunaan kuota permintaan yang berbeda:

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

Rekomendasi penggunaan Catalog Management API

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

Memantau penggunaan Anda

Anda harus memahami proses penggunaan yang berat. Misalnya, pada awal integrasi Anda, endpoint pengelolaan katalog Anda cenderung akan menggunakan lebih banyak kuota untuk membuat katalog awal lengkap Anda dan hal ini berpotensi memengaruhi penggunaan produksi endpoint lain seperti purchase status API jika Anda mendekati batas penggunaan keseluruhan. Anda perlu memantau pemakaian kuota untuk memastikan bahwa 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 pilihan Anda.

Mengoptimalkan penggunaan kuota API

Mengoptimalkan pemakaian rasio sangat direkomendasikan untuk meminimalkan kemungkinan Error API. Untuk menerapkannya secara efektif, sebaiknya Anda:

• Pilih strategi pengelolaan katalog yang tepat. Setelah Anda memahami API Anda perlu memilih strategi yang tepat bagi aplikasi Anda untuk mencapai tujuan pengelolaan katalog Anda secara efisien.
• Hanya lakukan panggilan telepon sesedikit mungkin untuk mencerminkan perubahan Anda.
• Jangan mengirim panggilan modifikasi yang berlebihan atau tidak perlu ke API. Ini mungkin mengharuskan Anda untuk menyimpan {i> changelog<i} di katalog backend.
• Mematuhi batas perubahan produk per jam sebanyak 7.200 kueri. Anda mungkin ingin membangun proses sinkronisasi yang mengharuskan Anda membuat produk dalam jumlah besar modifikasi dalam waktu singkat (misalnya, katalog awal pembuatan). Jika Anda memperkirakan proses ini melebihi batas per jam, implementasikan waktu tunggu yang diperlukan untuk memperlambat penggunaan ke tingkat yang aman. Pertimbangkan untuk menggunakan dengan update yang toleran terhadap latensi untuk mencapai throughput yang lebih tinggi.
• Mempersiapkan secara proaktif untuk menyesuaikan skala. Seiring dengan berkembangnya aplikasi, Anda mungkin perlu tingkatkan penggunaan API dan berbagai endpoint. Baca Laporan Google Dokumentasi kuota Play Developer API untuk mengetahui detail tentang cara menambah kuota saat Anda mendekati penggunaan maksimum.
• Jadwalkan proses-proses yang berat secara strategis. Coba jadwalkan jadwal yang panjang seputar puncak penggunaan kritis. Misalnya, Anda dapat menghindari sinkronisasi katalog lengkap selama puncak waktu penjualan dalam seminggu.

Menambahkan logika penanganan error kuota

Tidak peduli seberapa efisien Anda membangun logika pengelolaan katalog, Anda harus membuatnya tahan terhadap batas kuota yang tidak terduga, mengingat kuota harian dibagikan oleh endpoint yang digunakan dalam modul independen integrasi Anda. Pastikan Anda menyertakan kesalahan throttling kuota dalam penanganan error Anda, dan implementasikan waktu tunggu yang sesuai. Setiap panggilan yang dilakukan ke Google Play Developer API akan menghasilkan respons. Di kolom terjadinya kegagalan panggilan, Anda akan menerima respons kegagalan yang menyertakan Kode status respons HTTP dan objek errors, yang memberikan detail lebih lanjut mengenai domain error dan pesan debug. Misalnya, jika Anda melebihi batas harian, mungkin akan terjadi error mirip dengan contoh berikut ini:

{
  "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"
  } ],
}

Penerapan pengelolaan katalog

Developer menggunakan endpoint publikasi produk Google Play Developer API untuk menjaga katalog mereka tetap sinkron antara backend dan Google Play. Pembuatan memastikan katalog Google Play selalu diperbarui dengan katalog backend Anda informasi terbaru 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 penayangan penawaran dan kelayakan Anda sendiri logika.
• Anda dapat memeriksa berbagai titik harga dan detail produk pengguna dilihat di berbagai platform, dan memastikan konsistensi tersebut.
• Anda akan memiliki detail produk di backend saat memproses produk baru pembelian, 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-batas ini dan Anda tahu bagaimana Anda ingin menyusun katalog Anda, sekarang saatnya untuk menentukan strategi sinkronisasi Anda.

Strategi sinkronisasi katalog

Endpoint publikasi Google Play Developer API memungkinkan Anda membuat perubahan pada katalog Anda sesuai dengan perubahan yang terjadi. Terkadang, Anda mungkin perlu melakukan {i>update<i}, di mana Anda mengirim baterai perubahan dalam proses yang sama. Masing-masing pendekatan membutuhkan pilihan desain yang berbeda. Setiap strategi sinkronisasi akan lebih cocok untuk beberapa kasus penggunaan daripada yang lain, dan Anda mungkin memiliki membutuhkan keduanya, tergantung pada situasinya. Terkadang Anda mungkin ingin membuat memperbarui produk begitu Anda mengetahui perubahan baru, misalnya memproses pembaruan produk yang mendesak (yaitu harga yang salah perlu diperbaiki sebagai sesegera mungkin). Pada lain waktu, Anda dapat menggunakan sinkronisasi latar belakang berkala untuk memastikan backend dan katalog Play Anda selalu konsisten. Baca beberapa penggunaan umum kasus di mana Anda mungkin ingin menerapkan pengelolaan katalog yang berbeda ini dan strategi.

Kapan harus mengirim pembaruan saat katalog lokal Anda berubah

Idealnya, pembaruan harus terjadi segera setelah ada perubahan pada server untuk meminimalkan perbedaan.

Jenis update ini adalah opsi yang baik saat:

• Anda harus memastikan bahwa produk Anda selalu diperbarui.
• Anda harus membuat beberapa perubahan pada produk setiap hari.
• Anda perlu memperbarui produk yang sudah diproduksi dan dijual.

Pendekatan ini lebih mudah diterapkan, dan memungkinkan Anda menjaga katalog tetap sinkron dengan periode perbedaan jumlah terkecil.

Kapan harus menggunakan update berkala

Update berkala dijalankan secara asinkron ke edisi produk di backend, dan ini adalah opsi yang baik saat:

• Anda tidak perlu memastikan produk Anda diperbarui dalam waktu singkat.
• Anda perlu merencanakan update massal atau proses konsiliasi.
• Anda sudah memiliki Sistem Pengelolaan Konten atau Katalog untuk menangani produk digital, dan yang memperbarui katalog Anda secara terus-menerus

Untuk katalog besar, sebaiknya gunakan metode batch dengan toleran latensi untuk mencapai throughput maksimum.

Membuat katalog produk

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

Membuat produk sekali beli

Untuk pembuatan katalog besar produk sekali beli awal, sebaiknya gunakan Metode inappproducts.batchUpdate dengan kolom allowMissing ditetapkan ke true dan kolom latencyTolerance disetel ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Tindakan ini akan meminimalkan waktu yang diperlukan untuk membuat katalog sesuai batas kuota.

Untuk katalog yang lebih kecil, Anda dapat menggunakan metode inapp_products.insert. Atau, Anda dapat menggunakan metode inappproducts.update dengan allowMissing seperti yang dijelaskan di bagian Update produk. Pendekatan ini memiliki manfaat menghilangkan keperluan skrip Anda untuk stateful dan dapat dimulai ulang dari awal jika terjadi kesalahan.

Membuat produk langganan

Untuk pembuatan katalog besar dalam langganan awal, sebaiknya gunakan Metode monetization.subscriptions.batchUpdate dengan kolom allowMissing disetel ke true dan kolom latencyToleranceditetapkan ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Tindakan ini akan meminimalkan waktu yang diperlukan untuk membuat katalog sesuai 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.update dengan allowMissing seperti yang dijelaskan di bagian Update produk.

Semua metode sebelumnya membuat langganan bersama dengan paket dasarnya (disediakan dalam objek Subscription). Paket dasar ini awalnya tidak aktif. Untuk mengelola 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.

Notifikasi produk terbaru

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

Memperbarui produk sekali beli

Ada tiga metode yang tersedia untuk membantu Anda memperbarui produk sekali beli yang sudah ada.

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

Memperbarui produk langganan

Untuk memperbarui langganan yang sudah ada, Anda dapat menggunakan Metode monetization.subscriptions.patch. Metode ini mengambil parameter yang diperlukan berikut:

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

Kecuali 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 akan menentukan kolom listings ke parameter updateMask.

Anda dapat menggunakan monetization.subscriptions.batchUpdate untuk memperbarui beberapa langganan sekaligus. Gunakan bersama dengan kolom latencyTolerance yang disetel ke PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT untuk mencapai target yang lebih tinggi yang konsisten.

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

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

Rekonsiliasi katalog

Apakah Anda memilih untuk memperbarui katalog Google Play setiap kali backend perubahan katalog atau secara berkala, jika Anda memiliki sistem pengelolaan katalog atau di luar katalog Google Play, mungkin ada situasi di mana tidak sinkron dengan katalog pada konfigurasi aplikasi Anda di Play. Hal ini dapat disebabkan oleh perubahan katalog manual darurat di Konsol, pemadaman layanan pada sistem pengelolaan katalog Anda atau mungkin jika Anda kehilangan data terbaru.

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

Pertimbangan sistem perbedaan

Sebaiknya Anda membangun sistem perbedaan untuk mendeteksi inkonsistensi dan merekonsiliasi dua sistem. Berikut adalah beberapa hal yang perlu dipertimbangkan saat membangun sistem {i>diff <i}untuk membantu menjaga katalog yang sinkron:

• Memahami model data: Langkah pertama adalah memahami data CMS developer dan Google Play Developer API. Hal ini mencakup mengetahui berbagai jenis data yang disimpan di setiap sistem, dan bagaimana elemen data yang berbeda dipetakan satu sama lain.
• Tentukan aturan perbedaan: Setelah memahami model data, Anda harus menentukan aturan perbedaan. Aturan-aturan ini akan menentukan bagaimana data dalam kedua sistem dibandingkan. Misalnya, Anda mungkin ingin mencocokkan ID produk dan membandingkan atribut utama langganan dan paket dasar yang terkait, serta di seluruh platform Google.
• Implementasikan algoritma perbedaan: Setelah menentukan aturan perbedaan, Anda perlu menerapkan algoritma {i>diff<i}. 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 inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list dan monetization.subscriptions.batchGet metode.
• Buat laporan perbedaan: Algoritme perbedaan akan menghasilkan laporan perbedaan. Laporan ini akan menunjukkan perbedaan antara kedua sistem.
• Rekonsiliasi perbedaan: Setelah membuat laporan perbedaan, Anda harus untuk mengatasi perbedaannya. Langkah ini mungkin termasuk memperbarui data di CMS Anda, atau mungkin termasuk memperbarui data di sisi Google Play menggunakan Developer API endpoint pengelolaan katalog, bergantung pada cara Anda biasanya memperbarui katalog. Untuk merekonsiliasi produk yang tidak sinkron, gunakan endpoint update seperti yang dijelaskan di bagian Pembaruan produk.

Penghentian produk

Google Play Developer API menawarkan beberapa metode untuk membantu developer menghentikan penggunaan produknya: inappproducts.delete dan inappproducts.batchDelete untuk produk sekali beli dan monetization.subscriptions.delete untuk langganan. Penghentian penggunaan suatu produk mungkin diperlukan dalam berbagai skenario , seperti:

• Tidak sengaja dibuat.
• Menghentikan fitur atau layanan.

Sebaiknya terapkan penghentian penggunaan produk ke pengelolaan katalog Anda strategi.

Menghentikan penggunaan produk sekali beli

Untuk menghapus produk sekali beli dengan Google Play Developer API, Anda harus menggunakan tindakan inappproducts.delete atau inappproducts.batchDelete .

Menghentikan penggunaan produk langganan

Anda dapat menghapus langganan menggunakan monetization.subscriptions.delete . Langganan tidak dapat dihapus setelah minimal satu paket dasar diaktifkan.