Adapty kullanıcıları, farklı kaynaklardan gelen benzer veri kümelerini karşılaştırırken tutarsızlıklarla karşılaşabilir. Bu durum özellikle şunları karşılaştırırken ortaya çıkabilir:

• Adapty grafikleri ile mağaza raporları
• Adapty grafikleri ile üçüncü taraf grafikleri
• Adapty içindeki farklı grafikler

Sorun giderme algoritması

Adapty ile diğer platformlar arasındaki veri farklılıklarının büyük çoğunluğu beklenen ve normal bir durumdur. Bunun nedeni, farklı kaynakların aynı veriyi farklı şekillerde işlemesidir.

Bazen ise bu farklılıklar Adapty yapılandırmanızdaki bir sorunun işareti olabilir.

Verilerinizin platformlar arasında farklılık gösterdiğinden şüpheleniyorsanız yapılacak en iyi şey, ham verileri dışa aktarmak ve dosyaları karşılaştırmaktır.

• Mağazalar bile veri işleme ve sunumla ilgili sorunlar yaşayabilir. En doğru karşılaştırma için mağazaların ham işlem verilerine erişin.
• Adapty’yi başka bir analitik platformla karşılaştırırken, mağaza işlem raporlarını doğruluk kaynağı ve karşılaştırma noktası olarak kullanın.
• Tutarsızlıkları sınırlı bir veri setiyle tespit etmek daha kolaydır. Az miktarda veriyi karşılaştırın; belirli bir ürüne ve tek bir güne odaklanın.
• Tutarsızlığınızın fiyatlandırmadan mı yoksa etkinlik sayısından mı kaynaklandığını belirleyin. Fiyatlandırma sorunları ürün güncellemesiyle düzeltilebilir. Etkinlik sorunları sunucu tarafı sorunlarına işaret edebilir.
• Gelen etkinlikleri izlemek için etkinlik akışını inceleyin; beklenmedik davranışlar fark edebilirsiniz.

Verinin nerede ayrıştığını belirledikten sonra aşağıdaki yaygın nedenlere bakabilirsiniz:

Sunucu bildirimleri ve RTDN ile ilgili sorunlar

Mağaza bağlantılarını doğru yapılandırmadıysanız Adapty gerekli olay verilerini alamaz. Bu durum özellikle doğrudan kullanıcı etkileşimi olmadan gerçekleşen olayları etkiler; abonelik yenilemeleri, ödeme sorunları vb.

Sunucudan sunucuya yapılandırmayı mümkün olan en kısa sürede tamamlayın (App Store | Play Store) ve mağazaların bağlantıyı kurması için bekleyin.

Eksik App Store Connect verilerini Adapty’ye manuel olarak yükleyebilirsiniz.

Eksik veri

Güncel olmayan uygulama sürümü kullanan kullanıcılar

Bazı kullanıcılarınız Adapty SDK’sı içermeyen eski bir uygulama sürümü kullanıyorsa, Adapty bu kullanıcıların verilerini alamaz. Bu nedenle Adapty ile diğer kaynakların rakamları farklılık gösterir.

Entegrasyon sorunları

Bazı Adapty entegrasyonları (örneğin Adjust veya AppsFlyer), çalışabilmek için uygulamaya ek kod eklenmesini gerektirir. Adapty Kontrol Paneli’ni yapılandırıp uygulamanızı güncellemezseniz, gerekli veriler Adapty’de görünmez.

Eksik geçmiş veriler

Adapty’nin uygulamanızın geçmiş verilerine erişimi yoktur; bu verileri manuel olarak içe aktarmanız gerekir. Bir grafiğin zaman aralığı Adapty’yi entegre etmeden önceki bir tarihe uzanıyorsa ve geçmiş verilerinizi içe aktarmadıysanız, grafik değerleri diğer kaynaklardan farklı çıkacaktır.

Veri gecikmeleri

Adapty, uygulamanızın ekonomisini neredeyse gerçek zamanlı olarak analiz etmeyi hedefler. Aşağıdaki kısıtlamalar ve istisnalar geçerlidir:

• Adapty’yi ilk entegre ettiğinizde veriler hemen görünmeyebilir.
• Üçüncü taraf bir platformla entegrasyonu etkinleştirdiğinizde, verilerin tamamen senkronize edilmesi biraz zaman alabilir.
• Adapty mağaza verilerini aldıktan sonra, bunların işlenip Analytics sayfasında görüntülenmesi 15-30 dakika daha sürer.
• Dahil olan değişken sayısı nedeniyle Adapty ile üçüncü taraflar arasındaki veri alışverişi her zaman anlık olmayabilir.
• Bazı gelişmiş metriklere ilişkin hesaplamalar (örneğin kohort tahminleri) belirli miktarda veri gerektirir. Adapty bu hesaplamaları ancak yeterli veriyi topladığında gerçekleştirir.

Zamanla değişen metrikler

Kohort tabanlı metrikler, kullanıcıları gerçekleştirdikleri bir eyleme göre gruplar — bir kurulum, bir paywall görüntülemesi, bir deneme başlangıcı veya ilk ödeme — ardından bu kullanıcıların sonrasında ne yaptığını ölçmeye devam eder. Dönüşüm oranları, kohortlar, elde tutma ve LTV hepsi bu şekilde çalışır; metrik karşılaştırma tablosu hangi metriklerin bu şekilde çalışıp hangilerinin çalışmadığını belirtir. Mart ayında uygulamayı kuran ve Temmuz ayında abone olan bir kullanıcı, Mart ayının “Kurulumdan ödemeye” oranını Temmuz ayında artırır.

İki yıllık bir ayı geçen ayla karşılaştırmak, kesinleşmiş bir sayıyı geçici bir sayıyla karşılaştırmak anlamına gelir. Bunun yerine her dönemi aynı miktarda zaman geçtikten sonra karşılaştırın.

Install to trial birkaç gün içinde kesinleşirken, Install to paid ve Trial to paid aylarca artmaya devam eder. Compare months in your reports karşılaştırma yapmadan önce ne kadar beklemeniz gerektiğini açıklar.

Zaman ve takvim

Tarihler ve saat dilimleri

Algılanan veri tutarsızlıklarının en yaygın nedenlerinden biri, saat dilimi ayarlarındaki farklılıktır.

Adapty günleri UTC saat dilimine göre sayar. Başka bir platform farklı bir saat dilimi kullanıyorsa hesaplamalar farklı olacaktır. Ölçeği büyüttükçe fark azalır.

Her uygulama için saat dilimi ayarını değiştirebilirsiniz.

Apple mali takvimi

Apple, satış dönemlerini ve ödeme tarihlerini belirlemek için kendi muhasebe takvimini kullanır.

Takvimteki her “ay” 4 veya 5 haftadan oluşur ve komşu takvim aylarından günler içerebilir. Ödemeler genellikle satış dönemi bittikten 30–45 gün sonra yapılır.

Örneğin “Ocak 2026” satış dönemi, takvim ayının başından 4 gün önce, 28 Aralık 2025’te başlar. Bu dönem için tahmini ödeme tarihi 5 Mart’tır.

Apple ödeme raporlarındaki verileri takvim aylarıyla karşılaştırmayın. Bunun yerine, gerekli satış dönemine karşılık gelen özel bir tarih aralığı seçin.

İşlem tarihleri

Bazı hizmetler (örneğin AppsFlyer), işlemleri görüntülerken kohort kuralları uygulayabilir ve işlemleri gerçekleştikleri tarihe değil, uygulamanın yüklenme tarihine atfedebilir.

Gelir hesaplama

Ücretler ve vergiler

Ayara bağlı olarak Adapty grafikleri brüt geliri, mağaza komisyonu düşüldükten sonraki geliri veya mağaza komisyonu ve vergi düşüldükten sonraki geliri gösterebilir.

Bazı mağazalar ve üçüncü taraf platformlar, brüt geliri gösterme ya da vergileri otomatik olarak düşme özelliğine sahip olmayabilir. İki farklı gelir grafiği arasında bir tutarsızlık görürseniz, karşılaştırmanın geçerli olup olmadığını kontrol edin.

İptaller ve iadeler

Farklı platformlar iade verilerini farklı şekillerde gösterir. Adapty iadeleri negatif gelir olarak kabul eder. Bir kullanıcı abone olup ertesi gün iade talep ederse, her iki etkinlik de Adapty grafiklerinde ayrı günlerde yansıtılır. Diğer platformlar iade tutarını orijinal işlemden düşebilir.

Sandbox satın alımları

Etkinlik akışı, sandbox hesapları tarafından yapılan satın alımları gösterir; analitik grafikleri göstermez. Ancak geçmiş içe aktarma verileriniz sandbox satın alımları içeriyorsa, Adapty bunları ayırt edemez ve grafikleri geçmiş sandbox satın alımlarını yansıtır.

Kurulumlar ve indirmeler

Mağazalar (özellikle Apple App Store) kullanıcı indirmelerini doğrudan takip edebilir. İstatistikleri, uygulamanın yüklendiği ancak hiç başlatılmadığı durumları da içerebilir.

Adapty, kurulum tanımınızdan bağımsız olarak yalnızca kullanıcı uygulamayı başlattığında kurulumu kaydedebilir.

Ülke ve mağaza

Doğru raporlama sağlamak için Adapty, kullanıcının ülkesini IP adresinden çıkarabilir. Mağazalar ise indirmeleri ve satın almaları her zaman belirli bir uygulama mağazasına atfeder.

İkisi arasında net bir ayrım yapmanız gerekiyorsa Country by store account özelliğiyle yeni bir kullanıcı segmenti oluşturabilir ve analitikleri segmente göre filtreleyebilirsiniz.

Ürün fiyatlandırması

Yanlış ürün fiyatlandırması gelir tutarsızlığına yol açıyorsa, fiyatı değiştirmek geçmiş işlemleri geriye dönük olarak düzeltmez. Mevcut işlemlerin fiyatlarını değiştirmek için doğru verileri içe aktararak bunları zorla geçersiz kılmanız gerekir.

Bir kullanıcı fiyat değişikliğinin ardından eski bir satın alımı geri yüklediğinde, Apple satın alımın değerini yanlış raporlayabilir. Adapty’nin doğru değeri yansıtması için geçmiş veriyi içe aktarmanız gerekir.

Attribution çakışmaları

Adapty her işlem için yalnızca tek bir attribution kaynağı kullanabilir. Bu veriyi sonradan geçersiz kılamazsınız.

Kurulumunuz birbiriyle çelişen birden fazla attribution sağlayıcısı içeriyorsa, iki farklı platformdaki aynı işlem iki farklı trafik kaynağına sahipmiş gibi görünebilir.

Terminoloji farklılıkları

Farklı platformlar aynı kavram için farklı isimler kullanabilir. Gelirle ilgili metrikler platformdan platforma farklı adlar taşır:

Adapty	App Store Connect	Google Play Console
Brüt gelir (Gross revenue)	Sales	Gross Revenue
Mağaza komisyonu sonrası gelir (Proceeds after store commission)	N/A	N/A
Mağaza komisyonu ve vergi sonrası gelir (Proceeds after store commission and taxes)	Proceeds	Earnings
ARPPU	Proceeds per paying user	ARPPU

Diğer metrikler de tanım bakımından farklılık gösterebilir:

• Abonelikler:
  • Adapty, yeni denemeleri abonelik olarak saymaz. Yeni bir abonelik her zaman finansal bir işlemle başlar.
  • Google Play Console gibi diğer platformlar, ilk ödeme yapılmadan önce bile her denemeyi yeni bir abonelik olarak sayabilir.
• Retention:
  • Adapty, retention’ı abonelik yenilemelerinin sayısına göre ölçer.
  • App Store Connect, bir kullanıcının belirtilen gün uygulamayı açması durumunda kullanıcıyı elde tutulmuş sayar. Aboneliği olmayan bir kullanıcı bu metriğe dahil edilirken, o gün uygulamayı açmayan aboneli kullanıcı dahil edilmez.
  • Google Play Console’un “Retained Installers” metriği, uygulamanın kullanıcının cihazında yüklü kaldığı gün sayısına göre retention’ı ölçer. Uygulamayı açmayan kullanıcılar da bu metriğe dahil edilir.

Metrik ve etkinlik uyumsuzlukları

Bir grafik toplamı ile entegrasyonunuzun aldığı etkinlik sayısı arasındaki uyumsuzluk, bir teslimat hatası değil, beklenen bir durumdur. İsimler örtüşse de tanımlar örtüşmez.

Yeni abonelikler metriği ile subscription_started olayı arasındaki fark

Yeni abonelikler metriği ile subscription_started entegrasyon olayı farklı şeyleri sayar. “Yeni abonelikler” metriğinin subscription_started olay sayısını aşması beklenir.

Fark ne	Yeni abonelikler metriği	subscription_started eventi
Ne raporlar	Bir dönemde kaç aboneliğin başladığını	Ücretli bir aboneliğin başladığını, gerçek zamanlı olarak
Ne için kullanılır	Kaç yeni ödeme yapan kullanıcı kazandığınızı takip etmek	Satın almayı analizlerinize, MMP’nize veya kendi backend’inize kaydetmek
Zamanlama	İşlemleri raporlama saat dilimizdeki satın alma tarihine göre sayar	Satın alma gerçekleştiğinde gönderilir
Deneme dönemi dönüşümleri	Sayılır	Gönderilmez — Adapty bunun yerine trial_converted gönderir
Geri alınan işlemler	Adapty bunları geri aldıktan sonra hariç tutulur	Zaten gönderilmiştir ve geri çağrılmaz
SDK’nın hiç tanımlamadığı profiller	Satın almaları sayılır	Event Feed’de yer almaz

Aktif abonelikler metriği ile subscription_active eventi

Aktif abonelikler metriği ile subscription_active entegrasyon eventi, yalnızca saydıkları şey bakımından değil, amaçları bakımından da birbirinden farklıdır.

Fark	Aktif abonelikler metriği	subscription_active olayı
Ne raporlar	Her dönemin sonunda kaç aboneliğin aktif olduğunu	Bir aboneliğin ilk günlerini atlatıp atlatmadığını
Ne için kullanılır	Abone tabanınızın büyüklüğünü ve büyümesini takip etmek	Kalan kullanıcılar için teklif vermek amacıyla bir MMP’ye iletmek
Zamanlama	Her dönemin sonunda yeniden hesaplanır	Abonelik başladıktan 1 ile 90 gün arasında yapılandırılan gün sayısı sonra gönderilir
Tekrarlar	Evet, her dönem	Hayır — Adapty bir kez kontrol eder ve bir daha bakmaz
Deneme dönemi dönüşümleri	Deneme dönemi ücretli aboneliğe dönüştüğünde sayılır	Hiçbir zaman gönderilmez — zamanlayıcı yalnızca subscription_started ile başlar ve dönüşüm trial_converted gönderir
İptal edilen yenilemeler	Hariç tutulur	Kullanıcının erişimi olduğu sürece yine de gönderilir
İadeler	Geçmiş tarihler dahil geriye dönük olarak kaldırılır	İade önce gelirse gönderilmez; sonra gelirse geri alınmaz
Kullanılabilirlik	Her zaman hesaplanır	Yalnızca açık olduğunuz entegrasyonlar tarafından gönderilir

Active trials metriği ile trial_active eventi

Active trials metriği ile trial_active entegrasyon eventi, yalnızca saydıkları şey bakımından değil, amaçları bakımından da birbirinden farklıdır.

Fark	Aktif denemeler metriği	trial_active olayı
Ne raporlar	Kaç ücretsiz denemenin süresi dolmadığı	Bir denemenin ilk günleri atlattığı
Ne için	Kaç denemenin devam ettiğini görmek	Kalan deneme kullanıcıları için MMP teklifini optimize etmek
Zamanlama	Her dönemin sonunda yeniden hesaplanır	Deneme başladıktan 1 ile 90 gün arasında yapılandırılan süre sonra gönderilir
Tekrar eder mi	Evet, her dönem	Hayır — Adapty bir kez kontrol eder ve tekrar bakmaz
Deneme dönüşümleri	Deneme dönüşene kadar sayılır, sonra bir sonraki dönemde düşer	Zaten dönüşmüş bir deneme için hiç gönderilmez
Kullanılabilirlik	Her zaman hesaplanır	Yalnızca açık olduğunuz entegrasyonlar tarafından gönderilir

İkisi de iptalde hemfikirdir: otomatik yenilemeyi kapatan bir kullanıcı, deneme süresi sona erene kadar metrikte kalmaya devam eder ve event yine de gönderilir.

Filtrelenmiş toplam, filtresiz toplamı aşıyor

Period filtresi uygulandığında, bir ürün filtresi eklemek veya ürüne göre gruplamak, bir dönemin ne anlama geldiğini değiştirir. Herhangi bir ürün dahil edilmediğinde, Activation bir abonelik zincirindeki ilk ödemeyi sayar. Bir ürün dahil edildiğinde ise zincirdeki her ürün için ilk ödemeyi sayar; bu nedenle ürün değiştiren bir kullanıcı her ürün için ayrı bir Activation’a katkıda bulunur. Her iki görünüm de bir işlemi çift saymaz; farklı kullanıcı gruplarını sayar.

Hangisinin kullanılacağı soruya bağlıdır: gruplama olmaksızın tüm ürünler “kaç yeni ödeyici kullanıcı edindik” sorusunu yanıtlar; ürüne göre filtrelenmiş görünüm ise “bu ürünü ilk kez kaç kullanıcı başlattı” sorusunu yanıtlar. Period filtresini kaldırmak, her ikisini de filtresiz toplam ile uyumlu hale getirir.

Paywall görüntüleme dönüşüm oranları düştü

Uygulamanız Flow Builder kullanıyorsa, Paywall görüntüleme -> Deneme ve Paywall görüntüleme -> Ücretli oranları, tüm geçmişiniz boyunca eskisinden daha düşük görünüyordur.

Bir kullanıcıya gösterilen flow ekranı artık paywall görüntüleme olarak sayılmaktadır. Flow ekranı görüntülemeleri daha önce yalnızca flow metrikleri üzerinden izleniyordu; bu nedenle söz konusu iki oran, satın almaları her flow ekranını dışarıda bırakan bir paywall görüntüleme sayısına bölüyordu. Artık gördüğünüz oranlar doğru olanlardır; yerini aldıkları değerler gereğinden yüksekti.

Her kullanıcı, bir flow’un kaç ekranından geçtiğinden ve Paywall Builder ile oluşturulmuş bir paywall görüp görmediğinden bağımsız olarak tarih başına yalnızca bir kez sayılır.