Adapty’de, bir müşterinin uygulamadaki yolculuğu boyunca çeşitli abonelik olayları alırsınız. Bu abonelik akışları, kullanıcılar abone olurken, iptal ederken veya aboneliklerini yeniden etkinleştirirken Adapty’nin oluşturduğu olayları anlamanıza yardımcı olmak için yaygın senaryoları özetlemektedir.

Apple’ın abonelik ödemelerini gerçek başlangıç/yenileme zamanından birkaç saat önce işlediğini unutmayın. Aşağıdaki akışlarda, diyagramları anlaşılır tutmak için abonelik başlangıcı/yenilemesi ile ödemenin aynı anda gerçekleştiğini gösteriyoruz. Ayrıca, aynı eylemle ilgili olaylar aynı anda gerçekleşir ve Event Feed içinde herhangi bir sırayla görünebilir; bu sıra, diyagramlarımızda gösterilen sıradan farklı olabilir.

Abonelik Yaşam Döngüsü

İlk Satın Alma Akışı

Bu akış, bir müşteri deneme süresi olmaksızın 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: Abonelik bitiş 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 Billing Issue Outcome Flow ve Subscription Cancellation Flow bölümlerinde açıklanmaktadır.

Abonelik İptal Akışı

Bir kullanıcı aboneliğini iptal ettiğinde şu olaylar oluşturulur:

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

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

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

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

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

• Subscription renewal cancelled
• Subscription expired (churned)
• Access Level updated (kullanıcının erişimi kaldırılır) Bir para iadesi onaylanırsa, onaylandığında aynı zamanda bir Subscription refunded olayı da 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, Subscription renewed olayı oluşturulur. Erişimde bir boşluk olsa bile Adapty bunu, vendor_original_transaction_id ile bağlantılı tek bir işlem zinciri olarak değerlendirir. Bu nedenle yeniden satın alma, bir yenileme sayılır.

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 bir aboneliği duraklatıp daha sonra devam ettirmesi durumunda geçerlidir.

Aboneliği duraklatmanın etkileri gecikmeli olarak görülür. Kullanıcı, aboneliği yenilenmeden önce duraklatırsa abonelik aktif kalmaya devam eder ve kullanıcı mevcut fatura döneminin sonuna kadar ücretli erişimini sürdürür.

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

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

3. Kullanıcı aboneliği devam ettirdiğinde şu eventler tetiklenir:

   • Subscription renewed
   • Kullanıcının erişimini yeniden sağlamak için Access level updated

Bu abonelikler, aynı vendor_original_transaction_id ile bağlantılı olarak aynı işlem zincirine ait olacaktır.

Deneme Akışları

Uygulamanızda deneme süresi kullanıyorsanız ek deneme ile ilgili etkinlikler alırsınız.

Başarılı Dönüşümle Deneme Süreci

En yaygın senaryo, bir kullanıcının deneme süresi başlatıp kredi kartı bilgilerini girerek deneme süresi sonunda standart aboneliğe geçtiği durumdur. Bu senaryoda deneme başlangıcında şu olaylar oluşturulur:

• Trial started: Deneme süresinin başladığını işaret eder
• Access level updated: Erişim izni verilir

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

Başarılı Dönüşüm Olmadan Deneme Süresi Akışı

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

• Trial renewal cancelled: Deneme süresinin otomatik olarak aboneliğe dönüşmesini 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 olacak; bu noktada deneme süresinin bitişini işaretleyen Trial expired olayı oluşturulur.

Süresi Dolmuş Deneme Sonrası Abonelik Yeniden Aktivasyonu Akışı

Bir deneme süresi sona ererse (faturalama sorunu veya iptal nedeniyle) ve kullanıcı daha sonra bir abonelik satın alırsa, aşağıdaki 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, yükseltme, düşürme veya başka bir gruptan ürün satın alma gibi aktif aboneliklerde yapılan düzenlemeleri kapsar.

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

Kullanıcı bir ürünü değiştirdiğinde, abonelik sona ermeden önce sistem üzerinde hemen güncelleme yapılabilir (çoğunlukla ürün yükseltme veya değiştirme durumlarında). Bu durumda, ürün değişimi anında:

• Access level değiştirilir ve iki Access level updated olayı oluşturulur:
  1. birinci ürüne erişimi kaldırmak için.
  2. ikinci ürüne erişim vermek için.
• Eski abonelik sona erer ve bir geri ödeme yapılır (Subscription refunded olayı cancellation_reason = upgraded ile oluşturulur). Subscription expired (churned) olayının oluşturulmadığını unutmayın; Subscription refunded olayı onun yerine geçer.
• Yeni abonelik başlar (yeni ürün için Subscription started olayı oluşturulur).

Kullanıcı aboneliğini düşürürse, ilk abonelik ödeme süresinin sonuna kadar devam eder; süre dolduğunda yeni, daha düşük seviyeli abonelikle değiştirilir. Bu durumda, yalnızca erişim otomatik yenilemesini devre dışı bırakmak için Access level updated etkinliği hemen oluşturulur. Diğer tüm etkinlikler, aboneliğin gerçekten değiştirildiği anda oluşturulur:

• İkinci ürüne erişim vermek için başka 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 amacıyla Subscription started olayı oluşturulur.

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

Kullanıcının abonelik yenilemesi sırasında ürünü 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 anında tek bir Access level updated etkinliği oluşturulur. Diğer tüm etkinlikler, kullanıcının aboneliği değiştirdiği ve bu değişikliğin sistemde işlendiği anda oluşturulur:

• İkinci ürüne erişim sağlamak 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ışı

Bir deneme sürümünü dönüştürme veya aboneliği yenileme girişimleri ö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ürümü dönüşür veya abonelik yenilenir. Başarısız olursa, uygulama mağazası abonelik ücretini kullanıcıdan tahsil etmeye devam eder; bu girişimler de başarısız olursa uygulama mağazası deneme sürümünü veya aboneliği sonlandırır.

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

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

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

Ödeme sonuçta başarısız olur ve uygulama mağazası aboneliği iptal ederse, Adapty şu eventleri 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 olmadığında, Ödeme Yeniden Deneme Süresi (uygulama mağazasının kullanıcıdan ücret almaya devam ettiği süre) hemen başlar. Ek süre sonuna kadar ödeme hiç başarılı olmazsa akış aynıdır: App Store aboneliği otomatik olarak sonlandırdığında aynı event’ler oluşturulur:

• cancellation_reason değeri billing_error olan Trial expired veya Subscription expired (churned) event’i

• Kullanıcının erişimini iptal etmek için Access level updated

Kullanıcı Hesapları Arasında Satın Alma Paylaşım Akışları

Bir Customer User ID iOS, Android, React Native, Flutter ve Unity , 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 farklılık gösterir.

Yeni Kullanıcıya Erişim Aktarma Akışı

Önerilen seçenek, access level’ı yeni kullanıcıya aktarmaktır. Bu yöntem, 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. birinci kullanıcının erişimini kaldırmak için
2. ikinci kullanıcıya erişim vermek için

Bu senaryoda oluşturulan olaylardaki access level atama ve aktarımıyla ilgili alanların özeti:

• 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üklenip Kullanıcı B giriş yaptığında ve Kullanıcı A’nın erişimi iptal edildiğ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 ID ile oturum açılmış cihazlardaki birden fazla kullanıcının aynı access level’ı paylaşmasına olanak tanır. Bu, bir 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çenekle 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 analizleri korumak amacıyla orijinal Customer User ID iOS, Android, React Native, Flutter ve Unity altında kaydedilir. Bu nedenle yalnızca 1 olay oluşturulur: İkinci kullanıcıya erişim vermek 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
      }
    ]
  }

Kullanıcılar Arasında Erişimin Paylaşılmaması Akışı

Bu seçenekte, access level’ı ilk alan kullanıcı profili onu kalıcı olarak elinde tutar. Satın alımların tek bir Customer User ID iOS, Android, React Native, Flutter ve Unity ’e bağlı olması gerektiğinde idealdir.