Bu kılavuzda, Google Play Developer API'yi kullanarak Play uygulamanız için nasıl ürün kataloğu oluşturup yöneteceğiniz açıklanmaktadır.
Uygulamanızda Google Play'in faturalandırma sistemi üzerinden ürün satmak için kullanıcılarınızın satın alabileceği 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ğlamanıza ve manuel koordinasyonun pratik olmadığı büyük katalogları ölçeklendirmenize yardımcı olabilir. Bu kılavuzda, Play uygulamanız için ürün kataloğu oluşturmak ve yönetmek üzere Play Developer API'nin nasıl kullanılacağını göreceksiniz. Arka uç entegrasyonunuz için Google Play Developer API'yi ayarlama talimatları için Hazırlık 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 başlıklı makaleyi inceleyin. Google, Play'de katalog yönetimi için iki ana API grubu sunar. Bu API'ler, iki ana ürün kategorisine karşılık gelir:
- Tek seferlik ürünler
- Abonelik ürünleri
Tek seferlik ürünler
Tek seferlik ürünler (daha önce uygulama içi ürünler olarak adlandırılıyordu), tek seferlik ürünleriniz için birden fazla satın alma seçeneği ve fırsat yapılandırmanıza olanak tanıyan tek seferlik ürün nesnesi modelini kullanır. Tek seferlik ürün nesne modeli, ürün satma yöntemleriniz açısından daha fazla esneklik sağlamakla birlikte ürün yönetimini de sadeleştirir. Mevcut uygulama içi ürünleriniz, tek seferlik ürün nesne modeline taşınır. Daha fazla bilgi için Uygulama içi ürünlerin taşınması başlıklı makaleyi inceleyin.
monetization.onetimeproducts
ve inappproducts
uç noktaları, tek seferlik ürünleri arka uçtan yönetmenize olanak tanır. Ürün oluşturma, güncelleme ve silme, fiyatları ve stok durumunu yönetme bu kapsamdadır. Tek seferlik ürün satın alma işlemlerini nasıl ele aldığınıza bağlı olarak, tüketilebilir ürünleri (istenildiği kadar satın alınabilir) veya kalıcı hakları (aynı kullanıcı tarafından iki kez satın alınamaz) modellersiniz. Hangi tek seferlik ürünlerin tüketilebilir olup olmayacağına karar verebilirsiniz.
Abonelik ürünleri
monetization.subscriptions
uç noktası, abonelik ürünlerini geliştirici arka uç sisteminizden yönetmenize yardımcı olur. Abonelik oluşturma, güncelleme ve silme ya da bölgesel stok durumunu ve fiyatlandırmayı kontrol etme gibi işlemler yapabilirsiniz. monetization.subscriptions
uç noktasına ek olarak, aboneliklerin temel planlarını ve fırsatlarını yönetmek için sırasıyla monetization.subscriptions.basePlans
ve monetization.subscriptions.basePlans.offers
uç noktalarını da sunuyoruz.
Toplu yöntemler
onetimeproducts
, inappproducts
ve monetization.subscriptions
uç noktaları, aynı uygulamadaki 100'e kadar öğenin aynı anda alınmasına veya yönetilmesine olanak tanıyan bir dizi toplu işlem yöntemi sunar.
Toplu yöntemler, gecikme toleransı etkinleştirilmiş olarak kullanıldığında daha yüksek işleme hızı sağlar ve özellikle büyük kataloglu geliştiriciler için ilk katalog oluşturma veya katalog mutabakatı konusunda yararlıdır.
Güncelleme yayma gecikmesi ve işleme hızı
Ürün oluşturma veya değiştirme isteği tamamlandıktan sonra, ağ ya da arka uç işleme gecikmeleri nedeniyle değişiklikler son kullanıcılara cihazlarında hemen görünmeyebilir. Varsayılan olarak, tüm ürün değişikliği istekleri gecikmeye duyarlıdır. Bu nedenle, arka uç sistemlerinde hızlı yayılma için optimize edilmişlerdir ve genellikle birkaç dakika içinde son kullanıcı cihazlarına yansırlar.
Ancak bu tür değişiklik isteklerinin sayısı saatlik olarak sınırlıdır.
Çok sayıda ürün oluşturmanız veya güncellemeniz gereken durumlarda (ör. ilk büyük katalog oluşturma sırasında) latencyTolerance
alanı PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT
olarak ayarlanmış toplu yöntemleri kullanabilirsiniz. Bu işlem, güncelleme işleme hızını önemli ölçüde artırır. Gecikmeye toleranslı güncellemelerin son kullanıcı cihazlarına uygulanması 24 saati bulabilir.
Kota yapılandırması
Play Developer API'yi kullanarak ürün kataloğunuzu yönetirken dikkat etmeniz gereken birkaç kota sınırı vardır:
- Google Play Developer API'leri, gruplar adı verilen kategoriler halinde düzenlenir. Her grubun kendi dakika başına kota sınırı vardır. Daha fazla bilgi için kotalar başlıklı makaleyi inceleyin.
- Ürün değişikliği uç noktaları da saatte 7.200 sorgu sınırı uygular. Bu sınır, hem tek seferlik ürünler hem de abonelikler ve oluşturma, güncelleme, etkinleştirme, silme gibi tüm değişiklik istekleri için geçerlidir. Toplu değişiklik yöntemi çağrıları, içerilen tek tek isteklerin sayısından veya gecikme hassasiyetlerinden bağımsız olarak bu kota için tek bir sorgu olarak sayılır.
- Gecikmeye duyarlı değişiklikler için de saatte 7.200 değişiklik sınırı vardır. Toplu yöntemlerde, bu kota kapsamında her bir iç içe yerleştirilmiş değişiklik isteği ayrı ayrı sayılır. Bu kota, yalnızca toplu API'nin gecikmeye duyarlı güncellemeler yapan kullanıcıları için pratik sonuçlar doğurur. Diğer durumlarda, bu kotayla aynı anda veya bu kotadan önce 2. kota tükenir.
Farklı isteklerin kota kullanımını anlamanıza yardımcı olacak birkaç örnek aşağıda verilmiştir:
- Bir öğeyi getirmek için yapılan tek bir
get
isteği, kota 1'in 1 jetonunu tüketir ve kota 2 ile 3'ün jetonlarını tüketmez (çünkü bu kotalar yalnızca değişiklik uç noktalarıyla ilgilidir). - 100 öğeye kadar getirmek için toplu
get
isteği de kota 1'den 1 jeton kullanır ve kota 2 ile 3'ten jeton kullanmaz. - Tek bir öğe için tek bir
modification
isteği, 1. kotadan 1 jeton ve 2. kotadan 1 jeton tüketir. İstek gecikmeye duyarlıysa 3. kota için de 1 jeton tüketir. C kotası, 2 kotasıyla aynı sınıra sahip olduğundan yalnızca tek bir değişiklik yöntemi kullanan kullanıcılar için pratik bir sonucu yoktur. - Gecikmeye toleranslı 100 öğe için toplu
modification
istek, 1. kotadan 1 jeton, 2. kotadan 1 jeton tüketir. Bu kota ayarı, kataloğunuzun güncel kalması için yeterli paya sahip olmalıdır. Ancak algoritmanız bu kotanın farkında değilse ve bu oranı aşarsa her ek çağrı için bir hata alabilirsiniz. - Gecikmeye duyarlı 100 öğe için toplu
modification
isteği, 1. kotadan 1 jeton, 2. kotadan 1 jeton ve 3. kotadan 100 jeton tüketir.
Catalog Management API kullanım önerileri
Bu yönergelere uyarak API ile etkileşimlerinizi optimize edebilir, sorunsuz ve verimli bir katalog yönetimi deneyimi sağlayabilirsiniz.
Kullanımınızı izleme
Yoğun kullanım süreçlerinin farkında olmalısınız. Örneğin, entegrasyonunuzun başında, tam ilk kataloğunuzu oluşturmak için katalog yönetimi uç noktalarınızın daha fazla kota kullanması olasıdır. Bu durum, genel kullanım sınırına yakınsanız satın alma durumu API'si 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 çeşitli yolları vardır. Örneğin, Google Cloud API'leri kota kontrol panelini veya kendi tercih ettiğiniz başka bir şirket içi ya da üçüncü taraf API izleme aracını kullanabilirsiniz.
API kotası kullanımını optimize etme
API hataları 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 hedeflerinize verimli bir şekilde ulaşmak için uygulamanıza uygun stratejiyi seçmeniz gerekir.
- Yalnızca değişikliklerinizi yansıtmak için gereken minimum sayıda arama yapın.
- API'lere gereksiz veya gerekmeyen değişiklik çağrıları göndermeyin. Bu, arka uç kataloğunuzda bir değişiklik günlüğü tutmanızı gerektirebilir.
- Ürün değişikliği için saatlik 7.200 sorgu sınırının altında kalın. Kısa bir süre içinde çok sayıda ürün değişikliği yapmanızı gerektiren senkronizasyon işlemleri oluşturmak isteyebilirsiniz (örneğin, ilk katalog oluşturma). Bu işlemlerin saatlik sınırı aşacağını düşünüyorsanız kullanımı güvenli bir seviyeye düşürmek için gerektiği kadar bekleme süresi uygulayın. Daha yüksek işleme hızı elde etmek için gecikmeye toleranslı güncellemelerle toplu yöntemleri kullanabilirsiniz.
- Ölçeklendirmeye proaktif olarak hazırlanın. Uygulamanız büyüdükçe API ve çeşitli uç noktaları kullanımınızı ölçeklendirmeniz gerekebilir. Maksimum kullanıma yaklaştığınızda kotanızı nasıl artıracağınıza dair ayrıntılar için Google Play Developer API kota belgelerini inceleyin.
- Yoğun işlemleri 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ış zamanlarında tam katalog senkronizasyonu yapmaktan kaçınabilirsiniz.
Kota hatası işleme mantığı ekleme
Katalog yönetimi mantığınızı ne kadar verimli oluşturursanız oluşturun, günlük kota entegrasyonunuzun bağımsız modüllerinde kullanılan uç noktalar tarafından paylaşıldığından, beklenmedik kota sınırlarına karşı dayanıklı hale getirmeniz gerekir. Hata işleme sürecinize kota sınırlama hatalarını eklediğinizden ve uygun bekleme sürelerini uyguladığınızdan emin olun. Google Play Developer API'lerine yapılan her çağrı bir yanıt oluşturur. Çağrı hatası durumunda, HTTP yanıt durum kodu ve errors
nesnesi içeren bir hata yanıtı alırsınız. Bu yanıt, hata alanı ve hata ayıklama mesajı hakkında daha fazla ayrıntı sağlar. Örneğin, günlük sınırınızı aşarsanız aşağıdakine benzer bir hata mesajı alabilirsiniz:
{
"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 kalmasını sağlamak için Google Play Developer API ürün yayınlama uç noktalarını kullanır. Google Play kataloğunuzun, arka uç kataloğunuzdaki en son bilgilerle her zaman güncel olmasını sağlamak, daha iyi bir kullanıcı deneyimi oluşturma konusunda avantajlar sunar. Örneğin:
- Mevcut tekliflerin tam listesine göz atabilir ve kendi uygunluğunuzu ve tekliflerin gösterilme mantığını 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 ve bunların tutarlı olduğundan emin olabilirsiniz.
- Kullanıcıların kritik akışları sırasında Google Play Developer API'ye ek çağrılar yaparak gecikmeyi ve hata riskini artırmanıza gerek kalmadan, yeni satın alma işlemleri işlenirken ürün ayrıntılarına arka uçtan erişebilirsiniz.
Google Play'de ürün kataloğunuzu oluştururken dikkate almanız gereken belirli sınırlar ve hususlar vardır. Bu sınırları anladıktan ve kataloğunuzu nasıl yapılandırmak istediğinize karar verdikten sonra senkronizasyon stratejinizi belirleyebilirsiniz.
Katalog senkronizasyonu stratejileri
Google Play Developer API yayınlama uç noktaları, değişiklikler meydana geldikçe kataloğunuzda güncellemeler yapmanıza olanak tanır. Zaman zaman, aynı işlemde bir dizi değişiklik gönderdiğiniz periyodik güncelleme yaklaşımını kullanmanız gerekebilir. Her yaklaşım farklı tasarım seçimleri gerektirir. Her senkronizasyon stratejisi, bazı kullanım alanlarına diğerlerinden daha iyi uyar. Duruma bağlı olarak, her ikisini de gerektiren bir dizi ihtiyacınız olabilir. Bazen yeni bir değişiklikten haberdar olduğunuz anda bir üründe güncelleme yapmak isteyebilirsiniz. Örneğin, acil bir ürün güncellemesini işlemek (yani yanlış bir fiyatın mümkün olan en kısa sürede düzeltilmesi gerekir) için. Diğer durumlarda ise arka planda düzenli senkronizasyon kullanarak arka uç ve Play kataloglarınızın her zaman tutarlı olmasını sağlayabilirsiniz. Bu farklı katalog yönetimi stratejilerini uygulamak isteyebileceğiniz bazı yaygın kullanım alanlarını inceleyin.
Yerel kataloğunuzda değişiklikler olduğunda güncellemeleri ne zaman göndermelisiniz?
Tutarsızlıkları en aza indirmek için güncellemeler, arka uçtaki ürün kataloğunuzda herhangi bir değişiklik olduğu anda yapılmalıdır.
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.
- Her gün ürünlerinizde birkaç değişiklik yapmanız gerekir.
- Üretimde olan ve satılan ürünleri güncellemeniz gerekir.
Bu yaklaşımın uygulanması daha kolaydır ve kataloğunuzu en az miktarda tutarsızlık penceresiyle senkronize tutmanıza olanak tanır.
Periyodik güncellemeler ne zaman kullanılır?
Periyodik güncellemeler, arka uçtaki ürün sürümüyle eşzamanlı olarak çalıştırılmaz. Bu güncellemeler şu durumlarda iyi bir seçenektir:
- Ürünlerinizin kısa sürede güncellenmesini sağlamanız gerekmez.
- Toplu güncellemeleri veya mutabakat süreçlerini planlamanız gerekir.
- Dijital ürünlerinizi yönetmek için zaten bir içerik veya katalog yönetim sisteminiz var ve bu sistem kataloğunuzu sürekli olarak güncelliyor.
Büyük kataloglarda, maksimum işleme hızı elde etmek için gecikmeye toleranslı güncellemelerle toplu yöntemleri kullanabilirsiniz.
Ürün kataloğunuzu oluşturma
Google Play'e yükleyeceğiniz büyük bir kataloğunuz varsa ilk yüklemeyi otomatikleştirmek isteyebilirsiniz. Bu tür ağır işlemler, gecikmeye toleranslı toplu yöntemlerle birlikte periyodik bir strateji izlenirse en iyi sonucu verir.
Tek seferlik ürünler oluşturma
İlk ve tek seferlik ürün kataloğu oluşturma işlemi için monetization.onetimeproducts.batchUpdate veya inapp_products.insert
yöntemini kullanmanızı öneririz. Bu yöntemde allowMissing
alanı true
, latencyTolerance
alanı ise PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT
olarak ayarlanmalıdır. Bu, kota sınırları içinde kataloğun oluşturulması için gereken süreyi en aza indirir.
Abonelik ürünleri oluşturma
İlk abonelik için büyük katalog oluştururken allowMissing
alanı true
, latencyTolerance
alanı ise PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT
olarak ayarlanmış monetization.subscriptions.batchUpdate
yöntemini kullanmanızı öneririz. Bu, kota sınırları içinde kataloğun oluşturulması için gereken süreyi en aza indirir.
Play Developer API, daha küçük abonelik katalogları için monetization.subscriptions.create
yöntemini sunar.
Alternatif olarak, Ürün güncellemeleri bölümünde açıklandığı gibi monetization.subscriptions.patch
yöntemini kullanarak allowMissing
parametresiyle abonelik oluşturabilirsiniz.
Önceki yöntemlerin tümünde, abonelik nesnesi içinde sağlanan temel planlarla birlikte abonelikler oluşturulur. Bu temel planlar başlangıçta
etkin değildir. Temel planların durumunu yönetmek için monetization.subscriptions.basePlans
uç noktasını kullanabilirsiniz. Örneğin, satın alınabilir hale getirmek için temel planı etkinleştirebilirsiniz. Ayrıca, monetization.subscriptions.basePlans.offers
uç noktası, 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ştirmenizi sağlayarak tekliflerinizin en son düzenlemelerinizle uyumlu olmasını sağlar.
Tek seferlik ürünleri güncelleme
Mevcut tek seferlik ürünleri güncellemenize yardımcı olacak aşağıdaki yöntemlerden yararlanabilirsiniz.
- monetization.onetimeproducts.batchUpdate
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
: Uç nokta güncelleme, bir kaynağı tamamen güncellemek için kullanılır. Bu nedenle, isteğin gövdesinde kaynak nesnenin tamamını göndermeniz gerekir. Güncelleme uç noktası genellikle bir kaynaktaki tüm alanları güncellemeniz gerektiğinde kullanılır.allowMissing
parametresitrue
olarak ayarlandığında ve sağlanan ürün kimliği henüz mevcut olmadığında uç nokta, hata vermek yerine ürünü ekler.inappproducts.batchUpdate
: Bu, güncelleme uç noktasının toplu sürümüdür. Tek bir sorguyla birden fazla ürünü değiştirmenize olanak tanır. Daha yüksek verim elde etmek içinlatencyTolerance
alanıPRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT
olarak ayarlanmış şekilde kullanın.
Abonelik ürünlerini güncelleme
Mevcut abonelikleri güncellemek için monetization.subscriptions.patch
yöntemini kullanabilirsiniz. Bu yöntem aşağıdaki zorunlu 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şturmadığınız sürece updateMask
parametresini sağlamanız gerekir. Bu parametre, güncellemek istediğiniz alanların virgülle ayrılmış listesidir.
Örneğin, yalnızca bir abonelik ürünü listelemesini güncellemek istiyorsanız listings
alanını updateMask
parametresine göre belirtirsiniz.
Aynı anda birden fazla aboneliği güncellemek için monetization.subscriptions.batchUpdate
simgesini kullanabilirsiniz.
Daha yüksek verim elde etmek için latencyTolerance
alanını PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT
olarak ayarlayıp bu alanla 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ı
Arka uç kataloğunuz her değiştiğinde veya düzenli olarak Google Play kataloğunuzu güncellemeyi seçerseniz, Google Play kataloğunun dışında bir katalog yönetim sisteminiz ya da veritabanınız varsa Play'deki uygulama yapılandırmanızda kataloğun senkronizasyonu bozulabilir. Bunun nedeni Console'da acil durum için manuel olarak yapılan katalog değişiklikleri, katalog yönetim sisteminizdeki kesinti veya en son verilerinizi kaybetmiş olmanız olabilir.
Uzun süreli bir uyuşmazlık penceresiyle karşılaşmamak için katalog mutabakatı süreci oluşturabilirsiniz.
Fark sistemiyle ilgili dikkat edilmesi gereken noktalar
Tutarsızlıkları tespit etmek ve iki sistemi uzlaştırmak için bir farklılık sistemi oluşturmanızı öneririz. Kataloglarınızın senkronize kalmasına yardımcı olacak bir farklılık sistemi oluştururken göz önünde bulundurmanız gereken bazı noktalar şunlardır:
- Veri modellerini anlama: İlk adım, geliştirici içerik yönetim sisteminin ve Google Play Developer API'nin veri modellerini anlamaktır. Bu kapsamda, her sistemde depolanan farklı veri türlerinin bilinmesi ve farklı veri öğelerinin birbirleriyle nasıl eşlendiği yer alır.
- Fark kurallarını tanımlayın: Veri modellerini anladıktan sonra fark 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 planları ile teklifleriyle ilişkili temel özelliklerini karşılaştırmak isteyebilirsiniz.
- Fark algoritması uygulayın: 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
monetization.onetimeproducts.list
,monetization.onetimeproducts.batchGet
,inappproducts.list
,inappproducts.batchGet
,monetization.subscriptions.list
vemonetization.subscriptions.batchGet
yöntemlerini kullanabilirsiniz. - Fark raporları oluşturma: Fark algoritması, bir fark raporu oluşturur. Bu raporda, iki sistem arasındaki farklar gösterilir.
- Farklılıkları uzlaştırma: Fark raporunu oluşturduktan sonra farklılıkları gidermeniz gerekir. Bu işlem, kataloğunuzu normalde nasıl güncellediğinize bağlı olarak CMS'nizdeki verilerin güncellenmesini veya Google Play tarafındaki verilerin Developer API katalog yönetimi uç noktaları kullanılarak güncellenmesini gerektirebilir. Senkronize olmayan ürünleri uzlaştırmak için ürün güncellemeleri bölümünde açıklandığı şekilde güncelleme uç noktalarını kullanın.
Ürün desteğinin sonlandırılması
Google Play Developer API, ürünlerinizin desteğini sonlandırmanıza yardımcı olmak için aşağıdaki yöntemleri sunar:
Tek seferlik ürünler için:
monetization.onetimeproducts.delete
monetization.onetimeproducts.batchDelete
inappproducts.delete
inappproducts.batchDelete
Abonelik ürünleri için:
monetization.subscriptions.delete
abonelikler için geçerlidir. En az bir temel plan etkinleştirildikten sonra abonelik kaldırılamaz.
Bir ürünün desteğinin sonlandırılması çeşitli senaryolarda gerekli olabilir. Örneğin:
- Yanlışlıkla oluşturulmuş.
- Bir özellik veya hizmetin kullanımdan kaldırılması
Ürün desteğinin sonlandırılmasını katalog yönetimi stratejinize dahil etmenizi öneririz.