Ürün kataloğunuzu yönetme

Bu kılavuzda, Play uygulamanız için bir ürün kataloğu oluşturmak ve bu kataloğu yönetmek amacıyla Google Play Developer API'yi nasıl kullanacağınız açıklanmaktadır.

Uygulamanızda Google Play'in faturalandırma sistemini kullanarak ürün satmak için, kullanıcılarınızın satın almasına sunduğunuz tüm ürünleri içeren bir katalog oluşturmanız gerekir. Bu işlemi Play Console'dan yapabilir veya Google Play Developer API'yi kullanarak katalog yönetimini otomatikleştirebilirsiniz. Otomasyon, kataloğunuzun her zaman güncel olmasını sağlamaya ve manuel koordinasyonun pratik olmadığı büyük kataloglara ölçeklenmesine yardımcı olabilir. Bu kılavuzda, Play uygulamanız için ürün kataloğu oluşturmak ve bu kataloğu yönetmek üzere Play Developer API'yi nasıl kullanacağınızı öğreneceksiniz. Arka uç entegrasyonunuz için Google Play Developer API'nin nasıl kurulacağına ilişkin talimatlar için Hazırlanma kılavuzumuzu inceleyin.

Katalog Yönetimi API'leri

Google Play'in faturalandırma sistemiyle satabileceğiniz farklı ürün türleri hakkında bilgi edinmek için Uygulama içi ürün türlerini ve katalogla ilgili dikkat edilmesi gereken noktaları anlama bölümünü okuyun. Google, Play'de katalog yönetimi için iki ana ürün kategorisine karşılık gelen iki ana API seti sunar:

• Tek seferlik ürünler
• Abonelik ürünleri

Tek seferlik ürünler

inappproducts uç noktası, tek seferlik ürünleri arka ucunuzdan yönetmenizi sağlar. Ürün oluşturmak, güncellemek, silmek ve fiyatlar ile stok durumunu yönetmek bu kapsamda yer alır. Tek seferlik ürün satın alma işlemlerini nasıl yaptığınıza bağlı olarak, tüketilebilir ürünleri (istediğiniz sayıda satın alınabilir) veya kalıcı yararlanma haklarını (aynı kullanıcı tarafından iki kez yapılamaz) modellersiniz. Tek seferlik hangi ürünlerin tüketilebilir olup olmadığına karar verebilirsiniz.

Abonelik ürünleri

monetization.subscriptions uç noktası, abonelik ürünlerini geliştirici arka ucunuzdan yönetmenize yardımcı olur. Abonelik oluşturma, güncelleme ve silme gibi işlemler yapabilir veya aboneliklerin bölgesel stok durumunu ve fiyatlarını kontrol edebilirsiniz. monetization.subscriptions uç noktasına ek olarak, aboneliklerin temel planlarını ve tekliflerini yönetmek için monetization.subscriptions.basePlans ve monetization.subscriptions.basePlans.offers seçeneklerini de sunuyoruz.

Toplu yöntemler

inappproducts ve monetization.subscriptions uç noktaları, aynı uygulama altındaki 100 adede kadar varlığın aynı anda alınmasını veya yönetilmesini sağlayan çeşitli toplu yöntemler sunar.

Gecikme toleransı etkinleştirildiğinde toplu yöntemler daha yüksek işleme hızını destekler ve özellikle ilk katalog oluşturma veya katalog mutabakatı için büyük katalog geliştiriciler için kullanışlıdır.

Yayılım gecikmesi ile işleme hızını güncelleme

Ürün oluşturma veya değiştirme isteği tamamlandıktan sonra, ağ veya arka uç işleme gecikmeleri nedeniyle son kullanıcılar cihazlarındaki değişiklikleri hemen göremeyebilirler. Varsayılan olarak tüm ürün değiştirme istekleri gecikmeye duyarlıdır. Diğer bir deyişle, arka uç sistemleri aracılığıyla hızlı yayılma için optimize edilirler ve genellikle birkaç dakika içinde son kullanıcı cihazlarına yansıtılırlar. Ancak bu tür değişiklik isteklerinin sayısıyla ilgili saatlik bir sınır vardır. Çok sayıda ürün oluşturmanız veya güncellemeniz gereken durumlarda (örneğin, ilk büyük katalog oluşturma sırasında) latencyTolerance alanı PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT olarak ayarlanmış şekilde toplu yöntemler kullanabilirsiniz. Bu işlem, güncelleme işleme hızını önemli ölçüde artırır. Gecikmeden etkilenmeyen güncellemelerin son kullanıcı cihazlarına uygulanması 24 saati bulabilir.

Kota yapılandırma

Ürün kataloğunuzu yönetmek için Play Developer API'yi kullanırken bilmeniz gereken birkaç kota sınırı vardır:

1. Google Play Developer API'lerinin varsayılan günlük sınırı 200.000 sorgudur. Bu kota sınırı, katalog yönetimi API'leri dahil olmak üzere tüm uç noktalardaki kullanımın toplanması için geçerlidir.
2. Ürün değişiklik uç noktaları da saatte 7.200 sorgu sınırı uygular. Bu, hem tek seferlik ürünler hem de abonelikler için ve oluşturma, güncelleme, etkinleştirme ve silme dahil tüm değişiklik istekleri genelinde tek bir sınırdır. Dahil edilen bağımsız isteklerin sayısına veya gecikme hassasiyetine bakılmaksızın, toplu değişiklik yöntemi çağrıları bu kota için tek bir sorgu olarak sayılır.
3. Gecikmeye duyarlı değişiklikler de saatte 7.200 değişiklik sınırına sahiptir. Toplu yöntemlerde, iç içe yerleştirilmiş her değiştirme isteği bu kotanın amacı doğrultusunda ayrı olarak sayılır. Bu kotanın, yalnızca gecikmeye duyarlı güncellemeler yapan toplu API kullanıcıları için pratik etkileri vardır. Diğer durumlarda, kota 2 bu kotadan önce veya bu kotayla aynı anda tükenir.

Aşağıda, farklı isteklerin kota kullanımını anlamanızı sağlayacak birkaç açıklayıcı örnek verilmiştir:

• Bir öğeyi getirmek için yapılan tek bir get isteği, kota 1'in 1 jetonunu kullanmaz, kota 2 ve 3'ün jetonlarını kullanmaz (bu jetonlar yalnızca değişiklik uç noktalarıyla ilgilidir).
• 100 adede kadar öğe getirmek için toplu get isteği de 1 kota 1 jetonu kullanır ve kota 2 ile 3'ü kullanmaz.
• Bir öğe için tek bir modification isteği, kota 1 için 1, kota 2 için 1 jeton kullanır. İstek gecikmeye duyarlıysa 1 kota 3 jetonunu da kullanır. C kotası, kota 2 ile aynı sınıra sahip olduğundan yalnızca tekli değiştirme yöntemleri kullanan kullanıcılar açısından pratik bir etkisi yoktur.
• Gecikmeye toleranslı 100 öğe için toplu modification isteği, 1 kota 1, kota 2 için 1 jeton kullanır. Bu kota kurulumu, kataloğunuzu güncel tutmak için yeterli miktarda marjı mümkün kılacaktır. Ancak algoritmanız bu kotanın farkında değilse ve bu kotayı aşarsa her ek çağrı başına hata mesajı alabilirsiniz.
• 100 gecikmeye duyarlı öğe için toplu modification isteği, kota 1 için 1, kota 2 için 1 ve kota 3'te 100 jeton kullanır.

Catalog Management API kullanım önerileri

Bu yönergelere uyarak API ile etkileşimlerinizi optimize ederek sorunsuz ve verimli bir katalog yönetimi deneyimi sağlarsınız.

Kullanımınızı izleyin

Yoğun kullanım süreçlerine dikkat etmeniz gerekir. Örneğin, entegrasyonunuzun başında katalog yönetimi uç noktalarınızın tam ilk kataloğunuzu oluşturmak için daha fazla kota tüketmesi daha olasıdır. Bu durum, genel kullanım sınırına yakınsanız purchase status API gibi diğer uç noktaların üretim kullanımını etkileyebilir. API kotalarını aşmadığınızdan emin olmak için kota tüketiminizi izlemeniz gerekir. Kullanımı izlemenin birkaç yolu vardır. Örneğin, Google Cloud API'leri kota kontrol panelini veya istediğiniz başka bir şirket içi ya da üçüncü taraf API izleme aracını kullanabilirsiniz.

API kota kullanımını optimize edin

API hatalarının görülme olasılığını en aza indirmek için hız tüketimini optimize etmeniz önemle tavsiye edilir. Bunu etkili bir şekilde uygulamak için şunları yapmanızı öneririz:

• Doğru katalog yönetimi stratejisini seçin. API kotasını anladıktan sonra katalog yönetimi hedeflerinizi verimli bir şekilde gerçekleştirmek amacıyla uygulamanız için doğru stratejiyi seçmeniz gerekir.
• Yalnızca değişikliklerinizi yansıtmak için ihtiyacınız olan minimum sayıda telefon araması yapın.
• API'lere gereksiz veya gereksiz değişiklik çağrıları göndermeyin. Bu durumda arka uç kataloğunuzda bir değişiklik günlüğü tutmanız gerekebilir.
• Ürün değiştirme sınırı olan 7.200 sorguluk saatlik sınırın altında kalın. Kısa süre içinde çok sayıda ürün değişikliği yapmanızı gerektiren senkronizasyon süreçleri (örneğin, ilk katalog oluşturma işlemi) oluşturmak isteyebilirsiniz. Bu süreçlerin saatlik sınırı aşmasını bekliyorsanız kullanımı güvenli bir düzeye indirmek için gereken bekleme süresini uygulayın. Daha yüksek işleme hızı elde etmek için gecikmeye toleranslı güncellemelere sahip toplu yöntemler kullanmayı düşünün.
• Ölçeklendirme için proaktif şekilde hazırlanın. Uygulamanız büyüdükçe API ve çeşitli uç nokta kullanımınızı ölçeklendirmeniz gerekebilir. Maksimum kullanıma yaklaştığınızda kotanızı nasıl artıracağınızla ilgili ayrıntılar için Google Play Developer API kotaları belgelerini okuyun.
• Ağır süreçleri stratejik olarak planlayın. Yoğun katalog işlemlerinizi, kritik kullanım zirvelerine göre planlamaya çalışın. Örneğin, haftanın en yoğun satış dönemlerinde tüm katalog senkronizasyonunu yapmaktan kaçınabilirsiniz.

Kota hatası işleme mantığı ekleme

Katalog yönetim mantığınızı ne kadar verimli derlerseniz oluşturun, günlük kotanın entegrasyonunuzun bağımsız modüllerinde kullanılan uç noktalar tarafından paylaşıldığı göz önünde bulundurulduğunda, kataloğunuzu beklenmedik kota sınırlarına karşı dayanıklı hale getirmeniz gerekir. Hata işlemenize kota kısıtlama hatalarını dahil ettiğinizden ve uygun beklemeleri uyguladığınızdan emin olun. Google Play Developer API'lerine yapılan her çağrı bir yanıt oluşturur. Arama hatası durumunda, HTTP yanıt durum kodu ve errors nesnesi içeren ve hata alanı ve hata ayıklama mesajı hakkında daha ayrıntılı bilgi sağlayan bir hata yanıtı alırsınız. Örneğin, günlük sınırınızı aşarsanız aşağıdakine benzer bir hatayla karşılaşabilirsiniz:

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

Katalog yönetimi uygulaması

Geliştiriciler, kataloglarının arka uçları ile Google Play arasında senkronize olmasını sağlamak için Google Play Developer API ürün yayınlama uç noktalarını kullanır. Google Play kataloğunuzun arka ucunuzun kataloğundaki en son bilgilerle her zaman güncel olmasını sağlamak, daha iyi bir kullanıcı deneyimi sunmak açısından avantajlar sağlar. Örnek:

• Mevcut tekliflerin tam listesini inceleyebilir, kendi uygunluk durumunuzu ve teklif sunma mantığınızı etkilemek için teklif ve temel plan etiketlerini yönetebilirsiniz.
• Kullanıcıların platformlarda gördüğü farklı fiyat noktalarını ve ürün ayrıntılarını kontrol edebilir, bunların tutarlı olduğundan emin olabilirsiniz.
• Kullanıcı kritik akışları sırasında Google Play Developer API'ye ek çağrılar yaparak gecikmeyi ve başarısızlık riskini artırmanız gerekmeden, yeni satın alma işlemlerini işlerken arka ucunuzda ürün ayrıntılarına sahip olursunuz.

Google Play'de ürün kataloğunuzu oluştururken unutmamanız gereken belirli sınırlar ve dikkat edilmesi gereken noktalar vardır. Bu sınırları anladıktan ve kataloğunuzu nasıl yapılandırmak istediğinizi öğrendikten sonra senkronizasyon stratejinize karar verebilirsiniz.

Katalog senkronizasyon stratejileri

Google Play Developer API yayınlama uç noktaları, değişiklikler oluştukça kataloğunuzda güncelleme yapmanıza olanak tanır. Bazen düzenli olarak güncelleme yaklaşımını uygulamanız gerekebilir. Bu yaklaşımda aynı işlemdeki birtakım değişiklikler gönderilir. Her yaklaşım farklı tasarım seçimleri gerektirir. Her senkronizasyon stratejisi bazı kullanım alanlarına diğerlerinden daha uygundur ve duruma bağlı olarak her iki durum için de gerekli olan bir dizi ihtiyacınız olabilir. Bazen yeni bir değişikliği fark ettiğiniz anda bir üründe güncelleme yapmak isteyebilirsiniz. Örneğin, acil bir ürün güncellemesini işlemek için (yani yanlış bir fiyatın mümkün olan en kısa sürede düzeltilmesi gerekir). Bazen de arka uç ve Play kataloglarınızın her zaman tutarlı olmasını sağlamak için düzenli olarak arka plan senkronizasyonu kullanabilirsiniz. Bu farklı katalog yönetim stratejilerini uygulayabileceğiniz bazı yaygın kullanım alanlarını inceleyin.

Yerel kataloğunuz değiştikçe güncellemeleri ne zaman göndermelisiniz?

İdeal olarak, tutarsızlıkları en aza indirmek için güncellemelerin arka ucunuzun ürün kataloğunda herhangi bir değişiklik olur olmaz yapılması gerekir.

Bu tür güncellemeler aşağıdaki durumlarda iyi bir seçenektir:

• Ürünlerinizin her zaman güncel olduğundan emin olmanız gerekir.
• Ürünlerinizde her gün birkaç değişiklik yapmanız gerekir.
• Halihazırda üretimde olan ve satılmakta olan ürünleri güncellemeniz gerekir.

Uygulaması daha kolay olan bu yaklaşım, en az miktarda tutarsızlık aralığıyla kataloğunuzu senkronize etmenize olanak tanır.

Düzenli güncellemeler ne zaman kullanılır?

Periyodik güncellemeler, arka ucunuzdaki ürün sürümüyle eşzamansız olarak çalıştırılır. Bu güncellemeler şu durumlarda iyi bir seçenektir:

• Ürünlerinizin kısa süre içinde güncellendiğinden emin olmanız gerekmez.
• Toplu güncellemeleri veya mutabakat süreçlerini planlamanız gerekir.
• Dijital ürünlerinizi yönetmek için bir İçerik veya Katalog Yönetim Sisteminiz vardır ve kataloğunuz sürekli olarak güncellenir

Büyük kataloglar söz konusu olduğunda maksimum işleme hızına ulaşmak için gecikmeye dayanıklı güncellemelere sahip toplu yöntemler kullanmayı düşünün.

Ürün kataloğunuzu oluşturma

Google Play'e yükleyeceğiniz büyük bir kataloğunuz varsa ilk yüklemeyi otomatikleştirmeyi düşünebilirsiniz. Bu tür ağır işlemler, gecikmeye toleranslı toplu yöntemler ile birlikte periyodik bir strateji takip edildiğinde en iyi sonucu verir.

Tek seferlik ürünler oluşturma

İlk tek seferlik ürün büyük kataloğu oluşturma işlemi için allowMissing alanı true ve latencyTolerance alanı PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT olarak ayarlanmış inappproducts.batchUpdate yöntemini kullanmanızı öneririz. Bu, kota sınırları dahilinde kataloğu oluşturmak için gereken süreyi en aza indirir.

Daha küçük kataloglar için inapp_products.insert yöntemini kullanabilirsiniz. Alternatif olarak, Ürün güncellemeleri bölümünde açıklandığı gibi allowMissing parametresiyle inappproducts.update yöntemini kullanabilirsiniz. Bu yaklaşım, komut dosyanızın durum bilgili olması ihtiyacını ortadan kaldırma ve herhangi bir sorun durumunda sıfırdan yeniden başlatılma avantajı sağlar.

Abonelik ürünleri oluşturma

İlk büyük abonelik kataloğu oluşturma işlemi için allowMissing alanı true ve latencyTolerancealanı PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT olarak ayarlanmış monetization.subscriptions.batchUpdate yöntemini kullanmanızı öneririz. Bu, kota sınırları dahilinde kataloğu oluşturmak için gereken süreyi en aza indirir.

Play Developer API, daha küçük abonelik katalogları için monetization.subscriptions.create yöntemini sağlar. Alternatif olarak, Ürün güncellemeleri bölümünde açıklandığı gibi allowMissing parametresiyle monetization.subscriptions.update yöntemini kullanarak abonelik oluşturabilirsiniz.

Önceki tüm yöntemler, temel planlarıyla birlikte abonelikler oluşturur (Subscription nesnesinde sağlanır). Bu temel planlar başlangıçta etkin değildir. Temel planların durumunu yönetmek için monetization.subscriptions.basePlans uç noktasını kullanabilirsiniz. Buna, bir temel planı satışa sunmak üzere etkinleştirme ve etkinleştirme dahildir. monetization.subscriptions.basePlans.offers uç noktası da teklif oluşturmanıza ve yönetmenize olanak tanır.

Ürün güncellemeleri

Aşağıdaki yöntemler, mevcut ürünlerinizi verimli bir şekilde değiştirmenize ve tekliflerinizin en son düzenlemelerinize uygun olmasını sağlamanıza olanak tanır.

Tek seferlik ürünleri güncelleme

Mevcut tek seferlik ürünleri güncellemenize yardımcı olmak için kullanabileceğiniz üç yöntem vardır.

• inappproducts.patch: Yama uç noktası, bir kaynağı kısmen güncellemek için kullanılır. Bu, istek gövdesinde belirttiğiniz belirli alanları güncelleyebileceğiniz anlamına gelir. Yama uç noktası, genellikle bir kaynağın yalnızca birkaç alanını güncellemeniz gerektiğinde kullanılır.
• inappproducts.update : Güncelleme uç noktası, bir kaynağı tamamen güncellemek için kullanılır. Bu, kaynak nesnesinin tamamını istek gövdesinde göndermeniz gerektiği anlamına gelir. Güncelleme uç noktası genellikle bir kaynaktaki tüm alanları güncellemeniz gerektiğinde kullanılır. allowMissing parametresi true olarak ayarlandığında ve sağlanan ürün kimliği mevcut değilse uç nokta, ürünü başarısız olmak yerine ekler.
• inappproducts.batchUpdate: Bu, güncelleme uç noktasının tek bir sorguyla birden fazla ürünü değiştirmenize olanak tanıyan toplu bir sürümüdür. Daha yüksek işleme hızı elde etmek için latencyTolerance alanını PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT olarak ayarlanmış şekilde kullanın.

Abonelik ürünlerini güncelle

Mevcut abonelikleri güncellemek için monetization.subscriptions.patch yöntemini kullanabilirsiniz. Bu yöntem aşağıdaki gerekli parametreleri alır:

• packageName: Aboneliğin ait olduğu uygulamanın paket adı.
• productId: Aboneliğin benzersiz ürün kimliği.
• regionsVersion: Bölge yapılandırma sürümü.

allowMissing parametresini kullanarak yeni bir abonelik oluşturmuyorsanız updateMask parametresini sağlamanız gerekir. Bu parametre, güncellemek istediğiniz alanların virgülle ayrılmış bir listesidir.

Örneğin, yalnızca bir abonelik ürününün girişini güncellemek istiyorsanız listings alanını updateMask parametresine belirtirsiniz.

Aynı anda birden çok aboneliği güncellemek için monetization.subscriptions.batchUpdate uygulamasını kullanabilirsiniz. Daha yüksek işleme hızı elde etmek için latencyTolerance alanını PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT olarak ayarlayarak birlikte kullanın.

Temel planları etkinleştirmek, devre dışı bırakmak, silmek veya aboneleri en son temel plan fiyat sürümlerine taşımak için monetization.subscriptions.basePlans uç noktasını kullanın.

Ayrıca, temel planlarınızın tekliflerini monetization.subscriptions.basePlans.offers.patch yöntemiyle güncelleyebilirsiniz.

Katalog mutabakatı

Google Play kataloğunuzu arka ucunuzun kataloğu her değiştiğinde veya düzenli olarak güncellemeyi seçerseniz, Google Play kataloğunun dışında bir katalog yönetim sisteminiz veya veritabanınız varsa bunların Play'deki uygulama yapılandırmanızdaki katalogla senkronizasyonu bozulabilir. Bunun nedeni Console'daki acil durum manuel katalog değişiklikleri, katalog yönetim sisteminizdeki kesinti veya son verilerinizi kaybetmeniz olabilir.

Uzun süreli tutarsızlık aralığını önlemek için katalog mutabakat süreci oluşturabilirsiniz.

Sistem değerlendirmesi farkı

Tutarsızlıkları tespit etmek ve iki sistemi uzlaştırmak için bir fark sistemi oluşturmanızı öneririz. Kataloglarınızın birbiriyle uyumlu olmasını sağlayacak bir fark sistemi oluştururken göz önünde bulundurmanız gereken bazı noktalar şunlardır:

• Veri modellerini anlama: İlk adım, geliştirici CMS ve Google Play Developer API'nin veri modellerini anlamaktır. Buna, her bir sistemde depolanan farklı veri türlerini ve farklı veri öğelerinin birbiriyle nasıl eşlendiğini bilmek dahildir.
• Farklılık kurallarını tanımlama: Veri modellerini anladıktan sonra farklılık kurallarını tanımlamanız gerekir. Bu kurallar, iki sistemdeki verilerin nasıl karşılaştırılacağını belirler. Örneğin, ürün kimliklerini eşleştirmek ve aboneliğin temel özellikleri ile ilişkili temel planlar ve teklifleri karşılaştırmak isteyebilirsiniz.
• Farklılık algoritması uygulama: Fark kurallarını tanımladıktan sonra, fark algoritmasını uygulamanız gerekir. Bu algoritma, iki sistemdeki verileri alır ve tanımladığınız kurallara göre karşılaştırır. Google Play'den katalog verilerini almak için inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list ve monetization.subscriptions.batchGet yöntemlerini kullanabilirsiniz.
• Farklılık raporları oluşturma: Fark algoritması bir fark raporu oluşturur. Bu rapor, her iki sistem arasındaki farkları gösterir.
• Farklılıkları uzlaştırma: Fark raporunu oluşturduktan sonra farklılıkları çözmeniz gerekir. Bu işlem, CMS'nizdeki verileri güncellemeyi kapsayabilir veya normalde kataloğunuzu nasıl güncellediğinize bağlı olarak Developer API katalog yönetimi uç noktaları kullanılarak Google Play tarafında verilerin güncellenmesini içerebilir. Senkronize olmayan ürünleri uzlaştırmak için ürün güncellemeleri bölümünde açıklandığı gibi güncelleme uç noktalarını kullanın.

Ürünün kullanımdan kaldırılması

Google Play Developer API, geliştiricilere ürünlerini kullanımdan kaldırma konusunda yardımcı olmak için çeşitli yöntemler sunar: tek seferlik ürünler için inappproducts.delete ve inappproducts.batchDelete ve abonelikler için monetization.subscriptions.delete. Bir ürünün kullanımdan kaldırılması, aşağıdakiler gibi çeşitli senaryolarda gerekli olabilir:

• Yanlışlıkla oluşturulmuş.
• Bir özelliğin veya hizmetin kullanımdan kaldırılması.

Ürünleri kullanımdan kaldırma sürecini katalog yönetim stratejinize dahil etmenizi öneririz.

Tek seferlik ürünleri kullanımdan kaldırma

Tek seferlik ürünleri Google Play Developer API ile silmek için inappproducts.delete veya inappproducts.batchDelete yöntemini kullanmanız gerekir.

Abonelik ürünlerini kullanımdan kaldırma

Abonelikleri silmek için monetization.subscriptions.delete yöntemini kullanabilirsiniz. En az bir temel plan etkinleştirildikten sonra abonelikler kaldırılamaz.