Tek bir işlem çoğunlukla birden fazla olay üretir. Örneğin, ilk satın alma hem Subscription started hem de Access level updated olaylarını gönderir. Aşağıdaki diyagramlar, bir kullanıcı abone olduğunda, iptal ettiğinde veya yeniden aktifleştirdiğinde Adapty’nin ne gönderdiğini ve hangi sırayla gönderdiğini göstermektedir.

Diyagramlar nasıl okunur

• Zamanlama. Apple, bir abonelik için başlamadan veya yenilenmeden birkaç saat önce ücret tahsil eder. Bu boşluğu göstermek, hangi olayları aldığınızı değiştirmeksizin her diyagrama bir adım eklerdi; bu nedenle diyagramlar ödeme ve başlangıcı bir arada gösterir.
• Sıra. Tek bir işlemden gelen olaylar aynı anda ulaşır. Bir diyagramın bunları belirli bir sıraya koyması gerekir; ancak Event Feed sayfanız bunları farklı bir sırayla listeleyebilir ve her ikisi de eşit ölçüde doğrudur.
• Kapsam. Bir mağaza bildirimi, gösterilen her olayı tetikler. Sentetik olaylar görünmez: Adapty bunları zamanlayıcıyla gönderir ve gecikme süresi entegrasyona göre değiştiğinden bir dizide sabit bir yerleri yoktur.

Abonelik Yaşam Döngüsü

İlk Satın Alma Akışı

Bu akış, bir müşteri deneme süresi olmadan ilk kez abonelik satın aldığında gerçekleşir. Bu durumda aşağıdaki olaylar oluşturulur:

• Subscription started
• Access level updated: kullanıcıya erişim izni vermek için

Abonelik yenileme tarihi geldiğinde abonelik yenilenir. Bu durumda aşağıdaki olaylar oluşturulur:

• Subscription renewal: aboneliğin yeni bir dönemini başlatmak için
• Access level updated: aboneliğin son kullanma tarihini güncelleyerek erişimi bir dönem daha uzatmak için

Ödemenin başarısız olduğu veya kullanıcının yenilemeyi iptal ettiği durumlar sırasıyla Ödeme Sorunu Sonuç Akışı ve Abonelik İptal Akışı bölümlerinde açıklanmaktadır.

Abonelik İptal Flow’u

Bir kullanıcı aboneliğini iptal ettiğinde, aşağıdaki olaylar oluşturulur:

• Subscription renewal canceled: Aboneliğin mevcut dönemin sonuna kadar aktif kalacağını, ardından kullanıcının erişimini kaybedeceğini belirtir
• Access level updated olayı, erişim için otomatik yenilemeyi devre dışı bırakmak amacıyla oluşturulur

Abonelik sona erdiğinde, aboneliğin bitişini işaretlemek için Subscription expired (churned) olayı tetiklenir.

Bir iade onaylanırsa, aşağıdaki olay Subscription expired (churned) yerine geçer:

• Subscription refunded: aboneliği sonlandırır ve iade ayrıntılarını sağlar

Stripe’ta bir abonelik kalan süre atlanarak anında iptal edilebilir. Bu durumda tüm olaylar eş zamanlı olarak oluşturulur:

• Subscription renewal cancelled
• Subscription expired (churned)
• Access Level updated: kullanıcının erişimini kaldırır

Eğer bir iade onaylanırsa, onaylandığında Subscription refunded eventi de tetiklenir.

Abonelik Yeniden Etkinleştirme Akışı

Bir kullanıcı aboneliğini iptal ederse, abonelik sona erer ve kullanıcı daha sonra aynı aboneliği yeniden satın alırsa, bir Subscription renewed olayı oluşturulur. Erişimde bir kesinti olsa bile Adapty, bunu vendor_original_transaction_id ile bağlantılı tek bir işlem zinciri olarak değerlendirir. Dolayısıyla yeniden satın alma, bir yenileme olarak kabul edilir.

Access level updated olayları iki kez oluşturulur:

• abonelik sona erdiğinde kullanıcının erişimini iptal etmek için
• abonelik yeniden satın alındığında erişim vermek için

Abonelik Duraklatma Akışı (Yalnızca Android)

Bu akış, bir kullanıcının Android’de aboneliğini duraklatıp daha sonra devam ettirmesi durumunda geçerlidir.

Aboneliği duraklatmanın etkileri hemen gerçekleşmez. Kullanıcı bir aboneliği yenilenmeden önce duraklatırsa, abonelik aktif kalmaya devam eder ve kullanıcı mevcut fatura döneminin sonuna kadar ücretli erişimini korur.

1. Kullanıcı bir aboneliği duraklatığında Subscription paused (Android only) etkinliği tetiklenir.

2. Abonelik döneminin sonunda Adapty, kullanıcının erişimini iptal etmek için Access level updated etkinliğini tetikler.

3. Kullanıcı aboneliği yeniden başlattığında şu etkinlikler tetiklenir:

   • Subscription renewed
   • Kullanıcının erişimini geri yüklemek için Access level updated

Bu abonelikler, aynı vendor_original_transaction_id ile bağlantılı olarak aynı işlem zincirinde yer alır.

Trial Akışları

Uygulamanızda deneme süresi kullanıyorsanız, deneme süresine ilişkin ek etkinlikler alırsınız.

Başarılı Dönüşümle Biten Deneme Süresi Flow’u

En yaygın flow, kullanıcının deneme süresi başlatması, kredi kartı bilgilerini girmesi ve deneme süresi sonunda standart aboneliğe başarıyla geçmesiyle gerçekleşir. Bu durumda, deneme süresi başlangıcında aşağıdaki eventler oluşturulur:

• Trial started — deneme süresinin başladığını işaretler
• Access level updated — erişim izni verir

Trial converted eventi ise standart abonelik başladığında oluşturulur.

Başarılı Dönüşüm Olmadan Deneme Süresi Flow’u

Bir kullanıcı deneme süresi aboneliğe dönüşmeden önce iptal ederse, iptal anında aşağıdaki olaylar oluşturulur:

• Trial renewal cancelled: deneme süresinin aboneliğe otomatik dönüşümünü devre dışı bırakmak için
• Access level updated: erişim yenilemeyi devre dışı bırakmak için

Kullanıcı, deneme süresinin sonuna kadar erişime sahip olur; bu noktada deneme süresinin bitişini işaretlemek için Trial expired olayı oluşturulur.

Süresi Dolmuş Deneme Sonrası Abonelik Yeniden Etkinleştirme Akışı

Bir deneme süresi (faturalandırma sorunu veya iptal nedeniyle) sona ererse ve kullanıcı daha sonra bir abonelik satın alırsa, şu olaylar oluşturulur:

• Kullanıcıya erişim vermek için Access level updated
• Trial converted

Deneme ile abonelik arasında bir boşluk olsa bile Adapty, vendor_original_transaction_id kullanarak ikisini birbirine bağlar. Bu dönüşüm, sıfır fiyatlı bir denemeyle başlayan kesintisiz bir işlem zincirinin parçası olarak değerlendirilir. Bu nedenle Subscription started yerine Trial converted olayı oluşturulur.

Ürün Değişiklikleri

Bu bölüm, aktif aboneliklerde yapılan değişiklikleri kapsar; yükseltmeler, düşürmeler veya başka bir gruptan ürün satın alımları gibi.

Anlık Ürün Değişikliği Akışı

Bir kullanıcı ürün değiştirdiğinde, abonelik sona ermeden önce bu değişiklik sistemde anlık olarak uygulanabilir (çoğunlukla bir ürünün yükseltilmesi veya değiştirilmesi durumunda). Bu durumda, ürün değişikliği anında:

• Access level değişir ve iki Access level updated olayı oluşturulur:
  1. Birinci ürüne erişimi kaldırmak için.
  2. İkinci ürüne erişim vermek için.
• Eski abonelik sona erer ve iade yapılır (Subscription refunded olayı cancellation_reason = upgraded ile oluşturulur). Dikkat: Subscription expired (churned) olayı oluşturulmaz; bunun yerine Subscription refunded olayı kullanılır.
• Yeni abonelik başlar (yeni ürün için Subscription started olayı oluşturulur).

Kullanıcı aboneliği düşürürse, ilk abonelik ödenen dönemin sonuna kadar devam eder ve abonelik sona erdiğinde daha düşük kademeli yeni bir abonelikle değiştirilir. Bu durumda, yalnızca erişimin otomatik yenilenmesini devre dışı bırakmak için Access level updated eventi anında oluşturulur. Diğer tüm eventler, aboneliğin fiilen değiştirildiği anda oluşturulur:

• İkinci ürüne erişim vermek için başka bir Access level updated olayı oluşturulur.
• Birinci ürünün aboneliğini sonlandırmak için Subscription expired (churned) olayı oluşturulur.
• Yeni ürün için yeni bir abonelik başlatmak amacıyla Subscription started olayı oluşturulur.

Gecikmeli Ürün Değişim Akışı

Kullanıcının ürünü abonelik yenileme anında değiştirdiği bir varyant da mevcuttur. Bu varyant bir öncekine çok benzer: eski ürün için otomatik yenilemeyi devre dışı bırakmak amacıyla tek bir Access level updated eventi hemen oluşturulur. Diğer tüm eventler, kullanıcının aboneliği değiştirdiği ve bu değişikliğin sistemde yansıtıldığı anda oluşturulur:

• İkinci ürüne erişim vermek için yeni bir Access level updated olayı oluşturulur.
• İlk ürünün aboneliğini sonlandırmak için Subscription expired (churned) olayı oluşturulur.
• Yeni ürün için yeni bir abonelik başlatmak üzere Subscription started olayı oluşturulur.

Ödeme Sorunu Sonuç Akışı

Deneme süresini dönüştürme veya aboneliği yenileme girişimleri bir ödeme sorunu nedeniyle başarısız olursa, bundan sonra ne olacağı ek sürenin etkin olup olmadığına bağlıdır.

Ek süre etkinken ödeme başarılı olursa deneme süresi dönüşür ya da abonelik yenilenir. Başarısız olursa uygulama mağazası kullanıcıyı abonelik için ücretlendirmeye çalışmaya devam eder; yine başarısız olursa uygulama mağazası deneme süresini veya aboneliği kendisi sonlandırır.

Bu nedenle, ödeme sorununun yaşandığı anda Adapty’de aşağıdaki olaylar oluşturulur:

• Billing issue detected
• Entered grace period (ek süre etkinleştirilmişse)
• Access level updated (ek süre sonuna kadar erişim sağlamak için)

Ödeme daha sonra başarılı olursa, Adapty bir Trial converted veya Subscription renewed olayı kaydeder ve kullanıcı erişimini kaybetmez.

Ödeme sonunda başarısız olur ve uygulama mağazası aboneliği iptal ederse, Adapty şu olayları oluşturur:

• Trial expired veya Subscription expired (churned) — cancellation_reason: billing_error ile
• Access level updated (kullanıcının erişimini iptal etmek için)

Ek süre olmadan, Ödeme Yeniden Deneme Süresi (uygulama mağazasının kullanıcıdan ücret almaya devam ettiği süre) hemen başlar.

Ödeme, ek sürenin sonuna kadar hiçbir zaman başarılı olmazsa akış aynıdır: uygulama mağazası aboneliği otomatik olarak sonlandırdığında aynı olaylar oluşturulur:

• cancellation_reason değeri billing_error olan Trial expired veya Subscription expired (churned) olayı

• Kullanıcının erişimini iptal etmek için Access level güncellendi

Kullanıcı Hesapları Arasında Satın Almaları Paylaşma Akışları

Bir Customer User ID iOS, Android, React Native, Flutter ve Unity , zaten farklı bir Customer User ID iOS, Android, React Native, Flutter ve Unity ’ye bağlı bir aboneliği geri yüklemeye veya uzatmaya çalıştığında, Adapty’nin Sharing paid access between user accounts ayarı erişimin nasıl yönetileceğini belirler. Akış, seçilen seçeneğe göre değişir.

İkinci bir profilin mevcut bir aboneliği talep ettiğinde hangi olayların tetiklendiğini bir bakışta görmek için bu matrisi kullanın. Aşağıdaki bölümler her akış için tam JSON yükünü göstermektedir.

Olay	Etkin (varsayılan)	Erişimi yeni kullanıcıya aktar	Devre dışı
Yeni profil: Access level updated (is_active=true)	Tetiklenir	Tetiklenir	Tetiklenmez
Eski profil: Access level updated (is_active=false)	Tetiklenmez — her iki profil de erişimi korur	Yeni tanımlanan cihaz işlemi yaydığında tetiklenir	Tetiklenmez — orijinal profil erişimi korur
Yeni olayın profiles_sharing_access_level alanı	Access level’ı paylaşan diğer profilleri listeler	null	Uygulanamaz — olay tetiklenmez

Aktarılan bir abonelikte yenilemeler, iadeler ve süresi dolmalar; access level’ı o an elinde bulunduran profil üzerinde subscription_renewed, subscription_refunded ve subscription_expired olaylarını tetiklemeye devam eder. Aktarım olayının kendisi subscription_started olayı göndermez; çünkü yeni bir işlem kaydedilmez — yalnızca attribution değişir.

Her mod için sözleşme ayrıntılarına bakmak isterseniz Pratik referans bölümüne göz atın.

Erişimi Yeni Kullanıcıya Aktarma Flow’u

Önerilen seçenek, access level’ı yeni kullanıcıya aktarmaktır. Bu, tutarlı analitik için orijinal kullanıcının işlem geçmişini korur. Yalnızca 2 Access level updated olayı oluşturulur:

1. ilk kullanıcının erişimini kaldırmak için
2. ikinci kullanıcıya erişim vermek için

Bu senaryoda oluşturulan olaylarda access level atama ve aktarmayla ilgili alanların ayrıntılı açıklaması aşağıda verilmiştir:

• Kullanıcı A: Access level güncellendi (Kullanıcı A uygulamada bir abonelik satın aldığında gönderilir)

  {
    "profile_id": "00000000-0000-0000-0000-000000000000",
    "customer_user_id": UserA,
    "event_properties": {
      "profile_has_access_level": true,
    },
    "profiles_sharing_access_level": null
  }

• Kullanıcı A: Access level güncellendi (uygulama yeniden yüklendiğinde ve Kullanıcı B giriş yaparak Kullanıcı A’nın erişimini iptal ettiğinde gönderilir)

  {
    "profile_id": "00000000-0000-0000-0000-000000000000",
    "customer_user_id": UserA,
    "event_properties": {
      "profile_has_access_level": false,
    },
    "profiles_sharing_access_level": null
  }

• Kullanıcı B: Access level güncellendi (Kullanıcı B giriş yaptığında ve erişim verildiğinde gönderilir)

  {
    "profile_id": "00000000-0000-0000-0000-000000000001",
    "customer_user_id": UserB,
    "event_properties": {
      "profile_has_access_level": true,
    },
    "profiles_sharing_access_level": null
  }

Kullanıcılar Arasında Paylaşılan Erişim Akışı

Bu seçenek, aynı Apple/Google kimliğiyle oturum açılmış cihazlardaki birden fazla kullanıcının aynı access level’ı paylaşmasına olanak tanır. Bu özellik, kullanıcının uygulamayı yeniden yükleyip farklı bir e-posta ile giriş yaptığında önceki satın alımına erişimini kaybetmemesi için kullanışlıdır. Bu seçenek sayesinde, birden fazla tanımlı kullanıcı aynı access level’ı paylaşabilir. Access level paylaşılırken tüm işlemler, eksiksiz işlem geçmişi ve analitik verilerinin korunması amacıyla orijinal Müşteri Kullanıcı Kimliği iOS, Android, React Native, Flutter ve Unity altında kaydedilir.

Bu nedenle yalnızca 1 olay oluşturulacaktır: İkinci kullanıcıya erişim sağlamak için Access level updated.

Bu senaryoda oluşturulan olaylarda access level atama ve paylaşımıyla ilgili alanların dökümü aşağıda verilmiştir:

Kullanıcı B: Access level updated (Kullanıcı B giriş yaptığında ve erişim verildiğinde gönderilir)

{
  "profile_id": "00000000-0000-0000-0000-000000000000",
  "customer_user_id": UserA,
  "event_properties": {
    "profile_has_access_level": true,
  },
  "profiles_sharing_access_level": [
    {
      "profile_id": "00000000-0000-0000-0000-000000000001,
      "customer_user_id": UserB
    }
  ]
}

Erişimin Kullanıcılar Arasında Paylaşılmadığı Akış

Bu seçenekte, access level’ı ilk alan kullanıcı profili bunu kalıcı olarak korur. Satın almaların tek bir Customer User ID iOS, Android, React Native, Flutter ve Unity ’a bağlı olması gerektiğinde bu seçenek idealdir.