Bazen, o da yalnızca coarse value (low, medium veya high) olarak, fine value olarak asla. Free trial sonrasındaki tahsilat Apple tarafında olur ve RevenueCat’e server to server ulaşır. SKAN ise yalnızca uygulamanın cihazda yazdığını kaydeder. Yani ödeme, ancak conversion value’yu yazan tek taraf olan uygulama, ödemenin düştüğü pencere kapanmadan çalışırsa sayılır. Cevabı trial süresi belirler. Trial yoksa ilk ödeme ilk pencereye fine value olarak düşebilir. Apple’ın sunduğu en kısa free trial (3 gün) bile onu ikinci pencereye iter, 1 haftalık trial genellikle üçüncüye, ikisinde de yalnızca coarse. Gün 35’ten sonra biten trial hiçbir pencereye yetişmez.
Kapsam: RevenueCat ile bir MMP (aktarım kurallarını kontrol ettiğim ikisi AppsFlyer ve Singular) ya da Firebase kullanan, SKAdNetwork 4 ve AdAttributionKit üzerinde çalışan, Meta ve Google’da reklam alan iOS subscription uygulamaları. Tüm bölgeler. Her platform bilgisi 1 Ekim 2026’da sağlayıcının kendi sayfasından kontrol edildi.
“RevenueCat ödemeyi kaydetti” ile “cihaz value’yu güncelledi” arasında ne oluyor?
Altı adım var, boşluk üçüncü ile beşinci arasında.
- İlk açılış. Apple’ın saati burada başlar. SKAdNetwork sayfası Receiving postbacks in multiple conversion windows, ilk açılıştan itibaren üç pencere belirliyor: gün 0 ila 2, 3 ila 7 ve 8 ila 35. Yalnızca ilk postback fine value taşıyabilir, Apple’ın güncelleme metodu bunu 0 ile 63 arasında bir sayı olarak tanımlıyor.
- Trial başlangıcı. Genellikle ilk session’da paywall’da, 1. pencerenin içinde, cihazdaki SDK’nın onu gördüğü yerde.
- Onaylanmış ödeme. Trial bittiğinde App Store ücreti tahsil eder. RevenueCat’in Event Types and Fields sayfası, başarılı bir ilk tahsilatı
is_trial_conversiondeğeri true olan birRENEWALolarak raporluyor. Kimsenin iptal etmediği bir trial ödeme sayılmaz, aktif bir entitlement da sayılmaz. Apple’ın Reducing involuntary subscriber churn sayfasına göre başarısız bir renewal 60 güne kadar billing retry’a girer. Billing Grace Period açıksa Apple tahsil etmeye çalışırken kullanıcı tam erişimini korur. - Server aktarımı. RevenueCat event’i MMP’ye server to server gönderir. AppsFlyer’ın SKAN Conversion Studio sayfasına göre AppsFlyer value’yu yeniden hesaplar. Uygulama açıksa SDK cihazı günceller, değilse server bir sonraki uygulama açılışını bekler. Bu açılış pencere dolmadan olmalı, yoksa event dikkate alınmaz. Singular’ın S2S Support for Conversion Models FAQ sayfası aynı beklemeyi, Singular’dan açmasını istediğiniz bir özellik için anlatıyor. Bu özellik yalnızca managed SKAN modunda çalışıyor. Pencere kapanırsa ya da kullanıcı uygulamayı bir daha hiç açmazsa Singular value’yu güncelleyemiyor.
- Cihazda yürütme. SDK, Apple’ın güncelleme metodunu çağırır. Value, tahsilatın yapıldığı pencereye değil, o anda açık olan pencereye düşer. Apple’ın updatePostbackConversionValue sayfasına göre fine value ilk pencereden sonra yok sayılır.
- Postback. Pencere kapandıktan sonra Apple postback’i rastgele bir gecikmeyle gönderir: birincisi için 24 ila 48 saat, ikincisi ve üçüncüsü için 24 ila 144 saat. Apple ayrıca, birden fazla postback alabilmek için uygulamanın her pencere içinde value’yu güncellemesi gerektiğini söylüyor. Yani gün 3 ile gün 7 arasında uygulamayı hiç açmayan bir kullanıcıda 2. pencerede raporlanacak bir şey kalmaz. Apple’ın en düşük tier’ı olan Tier 0’daki bir reklam ikinci ve üçüncü postback’i hiç almaz.
Conversion value’yu kim yazıyor?
Tek bir yazan taraf, cihazda. Apple’ın belgelediği her güncelleme metodu uygulamanın yaptığı bir çağrı. Bir server API’si bulamadım.
RevenueCat o yazan taraf değil. RevenueCat’in Meta Ads sayfası, SKAN conversion value’larını güncellemediğini (“doesn’t update SKAN conversion values”) söylüyor ve value’lar çakışmasın diye tek bir güncelleyen taraf öneriyor: uygulama, Meta SDK’sı ya da bir MMP. RevenueCat’in Singular sayfası, onları kendi server event’lerinden değiştiremeyeceğini söylüyor. RevenueCat’in AppsFlyer sayfası da çift saymamak için client side revenue takibini kaldırmanızı söylüyor. Bu kurulumda gün 0’daki bir satın alma bile AppsFlyer SDK’sına yalnızca server aktarımıyla ulaşabilir.
İkinci bir yazan taraf, sağlayıcıların uyardığı hatadır. Google’ın Set up your SKAdNetwork conversion value schema sayfasına göre şemayı tek bir yerde kurmanız kesinlikle önerilir. Set up your SKAdNetwork conversion value schema sayfasının Google Analytics sürümünde, Firebase SDK’sının her pencere için value’yu ayarlamasına izin veren bir seçenek var. Firebase’in Get started with Google Analytics for iOS+ sayfasına göre GOOGLE_ANALYTICS_REGISTRATION_WITH_AD_NETWORK_ENABLED değerini NO yapmadığınız sürece SDK uygulamayı SKAdNetwork’e otomatik olarak kaydeder. AppsFlyer’ın SKAN 4.0 anomalies explained yazısı, her güncellemenin bir öncekinin üzerine yazdığını söylüyor, başka bir SDK’dan gelen SKAN 3 tarzı güncellemeler ve install kayıtları dahil. Yazı ilk kez Ağustos 2023’te yayınlandı. Bir sağlayıcının anlatımı, Apple’ınki değil. Apple’ın metot sayfası, iki SDK onu çağırdığında ne olduğunu söylemiyor.
AdAttributionKit bir yazan taraf eklemiyor. Apple’ın Understanding AdAttributionKit and SKAdNetwork interoperability sayfası, SKAdNetwork conversion value çağrılarının AdAttributionKit’e yansıtıldığını ve iki framework arasında yalnızca tek bir impression’ın kazandığını söylüyor.
İlk ödeme hangi pencereye düşebilir?
Tablo, trial’ın ilk session’da başladığını varsayıyor. Gün 2’de başlayan bir trial her tarihi iki gün ileri kaydırır. Trial süreleri, Apple’ın Set up introductory offers for auto-renewable subscriptions sayfasında listelediği free trial süreleri. En kısası 3 gün. 2. pencere ve 3. pencere hücreleri yalnızca Tier 1 veya üzerindeki reklamlar için geçerli, çünkü Tier 0’daki bir reklam ilkinden sonra postback almaz.
| Trial | İlk tahsilat, ilk açılıştan sonraki gün | Pencere ve taşıyabileceği value | Cihazda MMP SDK’sı, ödeme RevenueCat’ten aktarılıyor | Yalnızca MMP server to server, MMP SDK’sı yok | İkinci yazan taraf olarak Firebase |
|---|---|---|---|---|---|
| Yok | Gün 0, session içinde | 1. pencere. Tier 2 veya 3’te fine, Tier 1’de yalnızca coarse, Tier 0’da value yok | Aktarılan event SDK’ya uygulama açıkken ulaşırsa ya da gün 2 bitmeden gelen ilk sonraki açılışta yazılır | Yazılmaz. Singular, aktarımının uygulamada kendi SDK’sını gerektirdiğini söylüyor, AppsFlyer’ın aktarımı da kendi SDK’sı üzerinden çalışıyor | Hangi SDK daha sonra yazarsa diğerinin fine value’sunun yerini alır |
| 3 gün | Yaklaşık gün 3 | 2. pencere, yalnızca coarse. Tahsilattan sonraki ilk açılış gün 7’den sonra gelirse 3. pencere | Tahsilattan sonraki ilk uygulama açılışında yazılır, gün 35’ten önce gelirse | Yazılmaz | Sonraki bir yazma coarse value’nun yerini alır |
| 1 hafta | Yaklaşık gün 7, 2. pencere kapanırken | Pratikte 3. pencere, yalnızca coarse | Tahsilattan sonraki ilk uygulama açılışında yazılır, gün 35’ten önce gelirse | Yazılmaz | Sonraki bir yazma coarse value’nun yerini alır |
| 2 hafta veya 1 ay | Yaklaşık gün 14, ya da gün 28 ila 31 | 3. pencere, yalnızca coarse. Gün 35’ten sonra biten bir trial hiçbir pencereye düşmez | Yalnızca kullanıcı uygulamayı tahsilat ile gün 35 arasında açarsa yazılır | Yazılmaz | Sonraki bir yazma coarse value’nun yerini alır |
Bunu takvim olarak okumak için postback gecikmesini ekleyin. 3. penceredeki bir ödeme MMP’nize ilk açılıştan sonraki gün 36 ile gün 41 arasında ulaşır, pencere erken kilitlenmediyse.
RevenueCat’in kendi rehberi neyi kapsıyor, neyi dışarıda bırakıyor?
RevenueCat’in 18 Şubat 2025’te yayınlanan How to use RevenueCat server-to-server events for SKAdNetwork attribution rehberi, bu konuda bildiğim en ayrıntılı sağlayıcı rehberi. Yedi günden kısa trial’ları ikinci pencereye, yedi günlük trial’ları üçüncü pencereye yerleştiriyor. Bu tabloyla örtüşüyor. İki çözüm sunuyor: uygulama her ön plana geldiğinde trial durumunu kontrol etmek ve trial bittiğinde silent push göndermek. Yaklaşımının tam doğruluğu garanti etmediğini de söylüyor. Benim ekleyeceklerim:
- Apple’ın silent push sınırları. Apple’ın Pushing background updates to your App sayfasına göre arka plan bildirimleri düşük önceliklidir, teslimi garanti edilmez, sistem onları kısıtlayabilir (Apple saatte iki ya da üçten fazla göndermemenizi söylüyor) ve uygulama zorla kapatılırsa bekletilen bildirim atılır. Rehberin bir çıkarımı Apple’ın dokümantasyonunun desteklediğinden daha ileri gidiyor: Rehbere göre Apple’ın server bildirimlerini RevenueCat üzerinden kullanmak, kullanıcı uygulamayı açmadan conversion’ları izlemek anlamına geliyor.
- Yazan taraf. Rehberin kodu SKAdNetwork’e uygulamadan yazıyor. MMP SDK’nız da yazıyorsa artık iki yazan tarafınız var. Bunun yerine event’i tek yazan tarafınız üzerinden geçirin.
- Ödeme ile entitlement. Rehberin kontrolü, artık trial döneminde olmayan aktif bir entitlement’ı okuyor. Bunun yerine value’yu tahsil edilen ücrete eşleyin, çünkü Billing Grace Period, Apple hâlâ tahsil etmeye çalışırken bir entitlement’ı aktif tutabilir.
- Platformların value ile ne yaptığı: bir sonraki bölümde.
- Rehberden sonraki framework değişiklikleri. Apple’ın AdAttributionKit Updates sayfası Haziran 2024 ve Haziran 2025’teki değişiklikleri listeliyor, bu kontrolde 2026 için hiçbir kayıt yok.
Google ve Meta coarse bir trial ödemesiyle ne yapıyor?
Google onu kullanmadığını söylüyor. Google Ads şema sayfası, Google’ın conversion modellemesinin yalnızca fine value’ları kullandığını ve SKAN 4’ün coarse conversion value’larını şu anda desteklemediğini (“we currently do not support SKAN version 4’s coarse conversion values”) söylüyor. Aynı sayfa, şemadaki her event için günde 10’dan fazla conversion event’i ve günde yaklaşık 50 install istiyor. Bunlar Google’ın şema yönergeleri, Apple’ın gizlilik eşiği değil. Apple de tier’lar için hiçbir install sayısı yayınlamıyor. Yani iOS App campaign’ler için Google’ın öğrendiği SKAN sinyali, ilk iki günde olanlardır. Google’ın modellenmiş conversion’ları ve Integrated Conversion Measurement’ı SKAN’dan ayrıdır. Üçünü Google Ads, MMP ve SKAN iOS conversion’larını neden farklı sayar yazısında yan yana koyuyorum.
Meta’nın kendi kurulumu var. Configure Apple’s SKAdNetwork in Meta Events Manager sayfası, SKAdNetwork 4 için event’leri fine ve coarse value’larla yapılandırmanıza izin veriyor: Meta’nın önerileriyle, MMP’nizin şemasını içe aktararak, ya da elle. Sayfa ayrıca Meta’nın SKAdNetwork 4 desteğini kademeli olarak sunduğunu ve bunun sizin için henüz mevcut olmayabileceğini söylüyor. Prepare your app integration for Apple’s SKAdNetwork sayfası, iOS için Facebook SDK’sını kullanan uygulamalardan 16.2.1 veya daha yeni bir sürüm istiyor ve conversion value’ları düşürmemenizi, lock window kullanmamanızı tavsiye ediyor. AppsFlyer ikisini de sunuyor: iade gibi negatif gelirin value’yu düşürmesine izin veren bir ayar ve postback’i erken gönderen bir kilit. iOS bütçenizin çoğu Meta’ya gidiyorsa bu iki ayarı Meta’nın tavsiyesine bakarak belirleyin. Yapılandırma sayfası, coarse value’lu event’lerin reklam performansına yardımcı olabileceğini söylüyor. Delivery’nin 3. pencereden gelen bir coarse value’yu nasıl ağırlıklandırdığını söylemiyor. AdAttributionKit postback’lerini doğrulayan bir Meta sayfası da bulamadım, o yüzden ikisini de iddia etmiyorum.
Bu, Meta optimizasyon event’i için ne anlama geliyor?
SKAN’da trial ödemesi geç, coarse olarak ve yalnızca ödedikten sonra uygulamayı açan kullanıcılar için gelir. İlk session’dan bir event ise 1. pencerede gelir ve fine olabilir. SKAN’ın Meta’ya hızlıca raporlayabildiği event erken bir event’tir: bir trial başlangıcı, ödemeyi öngören bir koşula bağlı bir trial başlangıcı, ya da gün 0’da satın alınan ücretli bir plan. Ödeme yine de 2. ve 3. pencereler için şemada coarse value olarak durabilir. Onu orada cohort hakkında geç gelen bir rapor olarak okurdum, delivery’yi yönlendirmesine güvenmezdim, çünkü Meta delivery’nin onu nasıl ağırlıklandırdığını söylemiyor. Meta’nın Aggregated Event Measurement’ı kendi kuralları olan ayrı bir yoldur. Events Manager trial’ı veya purchase’ı orada uygun değil diye işaretlerse kontroller trial ve purchase event’leri Meta AEM için neden uygun değil yazısında. Event seçiminin kendisi ise bir subscription uygulaması hangi event’i optimize etmeli yazısında.
Bir mobil oyun için ne değişiyor?
Aktarım sorununun çoğu ortadan kalkar, çünkü ödeme session içinde gerçekleşir. MMP SDK’sı bir uygulama içi satın almayı cihazın kendisinde logladığında, value’yu o session’da yazabilir ve 1. pencere onu fine value olarak taşıyabilir. AppsFlyer’ın Conversion Studio’su, reklam geliri dahil toplam geliri tek bir event olan af_skad_revenue üzerinden ölçebiliyor ve reklam geliri value’larının asla negatife düşmediğini not ediyor. Hibrit bir oyun, 1. penceredeki 64 fine value’yu satın almalar, reklam geliri ve ilerleme arasında bölebilir. 2. ve 3. pencerelerdeki coarse value’ları ise retention veya ilk satın alma için kullanabilir.
Daha zor kısım hacim. Apple tier’ı crowd büyüklüğüne göre belirliyor ve soft launch tasarım gereği küçüktür. Tier 0’daki bir reklam value’suz tek bir postback alır. Daha az sayıda ve daha büyük kampanyalar tier’ları daha erken aşar, bunu daha az kampanya, daha fazla sinyal yazısında anlatıyorum. Bir soft launch’ın neyi kanıtlaması gerektiği ve bunun için SKAN şeması, mobil oyunlar için kullanıcı kazanımı sayfasında.
Harcama artmadan önce bunu nasıl test edersiniz?
Bir trial şeması bütçe taşımadan önce yapacağım dört kontrol bunlar. Her biri yukarıdaki sağlayıcı sayfalarından çıkıyor:
- Yazan taraf. Apple’ın güncelleme metodunu tek bir SDK çağırıyor ve Google ile Meta’ya onun izlediği şemanın aynısı veriliyor. Firebase’in value ayarlama seçeneği ve diğer tüm SDK’ların SKAN güncellemeleri kapalı.
- Event. Ödeme, tahsil edilen ücrete, yani RevenueCat’in
is_trial_conversiontaşıyanRENEWALevent’ine eşleniyor. Trial başlangıcına ve iptal edilmemiş olmasına eşlenmiyor. - Aktarımın iki yolu da. AppsFlyer bir server event’i için iki yol belgeliyor: uygulama kullanımdaysa SDK value’yu hemen günceller, ya da server onu bir sonraki uygulama açılışı için bekletir. Aktarılan tek bir trial conversion’ı bir test cihazında her iki yoldan da izleyin ve güncelleme çağrısının ne zaman çalıştığını kaydedin.
- Cohort okuması. Olgunlaşmış bir cohort alın (ilk açılıştan sonra en az gün 41). MMP’nizin o network’e atfettiği kullanıcılar için RevenueCat’in kaydettiği trial conversion’ları, MMP’nizin 2. ve 3. pencereler için çözdüğü ödeme value’larıyla karşılaştırın. Fark, çok geç yazılan ödemeleri, sonraki postback’i almayan Tier 0 reklamlarını ve iki kaynak arasındaki attribution farklarını birbirine karıştırır. Onu fark olarak raporlayın, açığı kapatmak için rakamı büyütmeyin.
SKAN tarafında benim işim ne?
Bu, signal engineering işinin iOS kısmı: tek bir yazan taraf, trial’ınıza ve hacminize göre kurulmuş bir şema ve biri bir kampanyayı SKAN’dan değerlendirmeden önce SKAN’ın neyi gösterip neyi göstermeyeceğine dair yazılı bir beklenti. Sorunun ölçümde olup olmadığı belli değilse ilk bakacağım yer growth audit.
Kaynaklar
Hepsi 1 Ekim 2026’da kontrol edildi.
- Apple Developer: SKAdNetwork için Receiving postbacks in multiple conversion windows ve aynı adlı AdAttributionKit sayfası, sayfa tarihleri yok.
- Apple Developer: Set up introductory offers for auto-renewable subscriptions, sayfa tarihi yok.
- Apple Developer: Understanding AdAttributionKit and SKAdNetwork interoperability, sayfa tarihi yok.
- Apple Developer: updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:), sayfa tarihi yok.
- Apple Developer: AdAttributionKit Updates, Haziran 2024 ve Haziran 2025 kayıtları.
- Apple Developer: Pushing background updates to your App, sayfa tarihi yok.
- Apple Developer: Reducing involuntary subscriber churn, sayfa tarihi yok.
- Google Ads Help: Set up your SKAdNetwork conversion value schema, sayfa tarihi yok.
- Google Analytics Help: Set up your SKAdNetwork conversion value schema, sayfa tarihi yok.
- Firebase: Get started with Google Analytics for iOS+, son güncelleme 1 Ekim 2026.
- Meta Business Help Center: Configure Apple’s SKAdNetwork in Meta Events Manager, sayfa tarihi yok.
- Meta Business Help Center: Prepare your app integration for Apple’s SKAdNetwork, sayfa tarihi yok.
- AppsFlyer: SKAN Conversion Studio, 26 Nisan 2026’da düzenlendi.
- AppsFlyer blog: SKAN 4.0 anomalies explained, 8 Ağustos 2023’te yayınlandı, 13 Kasım 2025’te değiştirildi.
- Singular: S2S Support for Conversion Models FAQ, 17 Aralık 2024’te güncellendi.
- RevenueCat docs: Meta Ads, AppsFlyer, Singular ve Event Types and Fields, sayfa tarihleri yok.
- RevenueCat blog: How to use RevenueCat server-to-server events for SKAdNetwork attribution, 18 Şubat 2025’te yayınlandı, 19 Şubat 2025’te güncellendi.
Sık sorulan sorular
RevenueCat SKAN conversion value'larını güncelleyebilir mi?
Hayır. RevenueCat'in Meta Ads dokümantasyonu, SKAN veya AEM'i yapılandırmadığını ve SKAN conversion value'larını güncellemediğini söylüyor, Singular sayfası da RevenueCat'in onları kendi server event'lerinden değiştiremeyeceğini söylüyor. RevenueCat trial conversion'ı MMP'nize veya reklam platformunuza gönderir, value'yu yine cihazdaki uygulamanın yazması gerekir.
Silent push, trial ödemesinin SKAN'a ulaşmasını garanti eder mi?
Hayır. Apple arka plan bildirimlerini düşük öncelikli sayıyor, teslimini garanti etmiyor, kısıtlayabiliyor ve uygulama zorla kapatılırsa bekletilen bildirimi atıyor. Sistem teslim ettiğinde silent push uygulamayı arka planda uyandırır ve uygulama value'yu yazabilir. Ölçümü tam yapamaz.
Google Ads SKAN 4 coarse conversion value'larını kullanıyor mu?
1 Ekim 2026'da Google Ads Help'e göre hayır. Şema sayfası, Google'ın conversion modellemesinin yalnızca fine value'ları kullandığını ve SKAN 4 coarse value'larını desteklemediğini söylüyor. İkinci veya üçüncü pencerede yalnızca coarse value olarak gelebilen bir trial ödemesi bu modellemeye girmez.
Firebase ile MMP'm ikisi de conversion value ayarlamalı mı?
Hayır. Tek bir yazan taraf seçin. Google şemayı tek bir yerde kurmayı öneriyor, RevenueCat tek bir güncelleyen taraf öneriyor, AppsFlyer ise her güncellemenin bir öncekinin üzerine yazdığını söylüyor. Value'yu MMP'niz yazıyorsa, Firebase SDK'sının value ayarlamasına izin veren Google Analytics seçeneğini kapalı bırakın.
Zaten SKAdNetwork kullanıyorsam AdAttributionKit'e ihtiyacım var mı?
Birlikte çalışıyorlar. Apple, SKAdNetwork conversion value çağrılarını AdAttributionKit'e yansıtıyor ve iki framework arasında yalnızca tek bir impression kazanıyor. Üç pencere ile fine ve coarse kuralları aynı, bu yüzden yazıdaki trial zamanlaması ikisi için de geçerli. MMP'nize SDK'sının hangi framework'ü çağırdığını sorun.