--- title: "Etkinlik akışları" description: "Adapty'deki abonelik etkinlik akışlarının ayrıntılı şemalarını keşfedin. Abonelik etkinliklerinin nasıl oluşturulduğunu ve integrasyonlara nasıl gönderildiğini öğrenerek müşterilerinizin yolculuklarındaki önemli anları takip edin." --- 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ü \{#subscription-lifecycle\} ### İlk Satın Alma Akışı \{#initial-purchase-flow\} 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](event-flows#billing-issue-outcome-flow) ve [Subscription Cancellation Flow](event-flows#subscription-cancellation-flow) bölümlerinde açıklanmaktadır. ### Abonelik İptal Akışı \{#subscription-cancellation-flow\} 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ışı \{#subscription-reactivation-flow\} 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) \{#subscription-pause-flow-android-only\} 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ı \{#trial-flows\} 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ışı \{#trial-with-successful-conversion-flow\} 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ışı \{#trial-without-successful-conversion-flow\} 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ışı \{#subscription-reactivation-after-expired-trial-flow\} 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 \{#product-changes\} 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ışı \{#immediate-product-change-flow\} 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ışı \{#delayed-product-change-flow\} 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ışı \{#billing-issue-outcome-flow\} 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ı \{#sharing-purchases-across-user-accounts-flows\} Bir [iOS](identifying-users#set-customer-user-id-on-configuration), [Android](android-identifying-users#setting-customer-user-id-on-configuration), [React Native](react-native-identifying-users#setting-customer-user-id-on-configuration), [Flutter](flutter-identifying-users#setting-customer-user-id-on-configuration) ve [Unity](unity-identifying-users#setting-customer-user-id-on-configuration), zaten farklı bir [iOS](identifying-users#set-customer-user-id-on-configuration), [Android](android-identifying-users#setting-customer-user-id-on-configuration), [React Native](react-native-identifying-users#setting-customer-user-id-on-configuration), [Flutter](flutter-identifying-users#setting-customer-user-id-on-configuration) ve [Unity](unity-identifying-users#setting-customer-user-id-on-configuration)'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. :::note Apple Family Sharing işlemleri (`in_app_ownership_type=FAMILY_SHARED`) için yalnızca **Access level updated** eventi tetiklenir — aşağıdaki ürün bazlı abonelik eventleri tetiklenmez. Tam event matriksi için [Apple Family Sharing](apple-family-sharing) sayfasına bakın. ::: :::note Bir kullanıcı **Restore Purchases** butonuna dokunduğunda zaten aynı profilde erişimi varsa, geri yükleme işlemi hiçbir şey yapmaz ve hiçbir webhook eventi tetiklenmez. Bu bölümdeki eventler yalnızca erişim gerçekten profiller arasında aktarıldığında tetiklenir. ::: İ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](sharing-paid-access-between-user-accounts#practical-reference) bölümüne göz atın. ### Yeni Kullanıcıya Erişim Transferi \{#transfer-access-to-new-user-flow\} Ö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)** ```json showLineNumbers { "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)** ```json showLineNumbers { "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)** ```json showLineNumbers { "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ışı \{#shared-access-between-users-flow\} 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 [iOS](identifying-users#set-customer-user-id-on-configuration), [Android](android-identifying-users#setting-customer-user-id-on-configuration), [React Native](react-native-identifying-users#setting-customer-user-id-on-configuration), [Flutter](flutter-identifying-users#setting-customer-user-id-on-configuration) ve [Unity](unity-identifying-users#setting-customer-user-id-on-configuration) 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)** ```json showLineNumbers { "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ış \{#access-not-shared-between-users-flow\} Bu seçenekte, access level'ı ilk alan kullanıcı profili bunu kalıcı olarak korur. Satın almaların tek bir [iOS](identifying-users#set-customer-user-id-on-configuration), [Android](android-identifying-users#setting-customer-user-id-on-configuration), [React Native](react-native-identifying-users#setting-customer-user-id-on-configuration), [Flutter](flutter-identifying-users#setting-customer-user-id-on-configuration) ve [Unity](unity-identifying-users#setting-customer-user-id-on-configuration)'a bağlı olması gerektiğinde bu seçenek idealdir.