Adapty’de, bir müşterinin uygulamanızdaki 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 ürettiği olayları anlamanıza yardımcı olmak için yaygın senaryoları özetler.

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ı sade tutmak amacıyla abonelik başlangıcı/yenilemesi ile ödemenin aynı anda gerçekleştiğini gösteriyoruz. Ayrıca, aynı işleme ilişkin olaylar eş zamanlı gerçekleşir ve Event Feed bölümünüzde diyagramlarımızda gösterilen sıradan farklı bir sırayla görünebilir.

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 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 aşağıdaki olaylar oluşturulur:

• Subscription renewal canceled: Aboneliğin mevcut dönemin sonuna kadar aktif kaldığı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, aboneliğin bitişini işaretlemek için Subscription expired (churned) olayı tetiklenir.

Bir iade onaylanırsa, Subscription expired (churned) yerine şu olay gelir:

• Subscription refunded: aboneliği sona erdirir 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 iade 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, 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üşümlü Deneme Akışı

En yaygın akış, kullanıcının bir deneme 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 başlangıcı anında şu olaylar oluşturulur:

• Trial started — denemenin başladığını işaretler
• Access level updated — erişimi etkinleştirir

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

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

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

• Trial renewal cancelled: Deneme süresinin otomatik olarak aboneliğe dönüşmesi devre dışı bırakılır
• Access level updated: Access level yenileme devre dışı bırakılır

Kullanıcı, deneme süresinin sonuna kadar erişimine devam eder; bu sürenin bitişinde ise denemenin sona erdiğini işaretleyen 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ğini düşürürse, ilk abonelik ödenen süre sonuna kadar geçerliliğini korur ve sona erdiğinde yeni, daha düşük kademeli abonelikle değiştirilir. Bu durumda, yalnızca otomatik yenilemeyi devre dışı bırakmak için Access level updated eventi hemen 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 yeni bir Access level updated eventi oluşturulur.
• İlk ürünün aboneliğini sonlandırmak için Subscription expired (churned) eventi oluşturulur.
• Yeni ürün için yeni bir abonelik başlatmak amacıyla Subscription started eventi 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.
• Birinci ürünün aboneliğini sona erdirmek 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.

Ö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, Fatura Yeniden Deneme Süresi (uygulama mağazasının kullanıcıdan ücret almayı denemeye devam ettiği süre) hemen başlar. Ek süre sonuna kadar ödeme 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 updated

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.

Yeni Kullanıcıya Erişim Transferi

Önerilen seçenek, access level’ı yeni kullanıcıya aktarmaktır. Bu yaklaşım, tutarlı analitik için orijinal kullanıcının işlem geçmişini korur. Yalnızca 2 adet 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 dökümü şöyledir:

• 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
  }

• User A: Access level güncellendi (uygulama yeniden yüklenip User B giriş yaptığında ve User 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 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. Dolayısıyla 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 ayrıntılı açıklaması:

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.