---
title: "Veri tutarsızlıklarını giderme"
description: "Farklı kaynaklardaki veri sapmalarının nedenini bulun"
---

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ı \{#troubleshooting-algorithm\}

Adapty ile diğer platformlar arasındaki tutarsızlıkların büyük çoğunluğu beklenen ve normal durumlardır. Bunlar, **farklı kaynakların aynı veriyi farklı şekillerde işlemesinden** kaynaklanır.

Bazen ise bu tutarsızlıklar **Adapty yapılandırmanızdaki bir soruna** işaret eder.

Verinizin platformdan platforma farklılık gösterdiğinden şüpheleniyorsanız, en iyi yol [ham veriyi dışa aktarmak](export-analytics-api-requests) 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](#product-pricing) düzeltilebilir. Etkinlik sorunları [sunucu tarafı sorunlarına](#issues-with-server-notifications-and-rtdn) işaret edebilir.
* Gelen etkinlikleri izlemek için [etkinlik akışını](event-feed) inceleyin; beklenmedik davranışlar fark edebilirsiniz.

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

## Sunucu bildirimleri ve RTDN sorunları \{#issues-with-server-notifications-and-rtdn\}

Mağaza bağlantılarını doğru yapılandırmadıysanız Adapty gerekli etkinlik verilerini alamaz. Bu durum özellikle kullanıcının doğrudan müdahalesi olmadan gerçekleşen etkinlikleri etkiler — abonelik yenilemeleri, ödeme sorunları vb.

Sunucudan sunucuya yapılandırmayı en kısa sürede tamamlayın ([App Store](enable-app-store-server-notifications) | [Play Store](enable-real-time-developer-notifications-rtdn)) ve mağazaların bağlantıyı kurması için [bekleyin](#data-delays).

Eksik App Store Connect verilerini Adapty'ye [manuel olarak yükleyebilirsiniz](importing-historical-data-to-adapty).

## Eksik veri \{#missing-data\}

### Güncel olmayan uygulama sürümü kullanan kullanıcılar \{#users-with-out-of-date-app-versions\}

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ı \{#integration-issues\}

Bazı Adapty entegrasyonları (örneğin Adjust veya AppsFlyer) çalışmak için ek uygulama kodu gerektirir. Adapty kontrol panelini yapılandırıp uygulamanızı güncellemezseniz, gerekli veriler Adapty'de görünmez.

### Eksik geçmiş veri \{#missing-historical-data\}

Adapty, [manuel olarak içe aktarmadığınız](importing-historical-data-to-adapty) sürece uygulamanızın geçmiş verilerine erişemez. Bir grafiğin [zaman aralığı](controls-filters-grouping-compare-proceeds#time-ranges) Adapty'yi entegre ettiğiniz tarihten önce başlıyorsa ve geçmiş veriyi içe aktarmadıysanız, değerler diğer kaynaklardan farklı olacaktır.

## Veri gecikmeleri \{#data-delays\}

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](predicted-ltv-and-revenue)) belirli miktarda veri gerektirir. Adapty bu hesaplamaları ancak yeterli veriyi topladığında gerçekleştirir.

## Zaman ve takvim \{#time-and-calendar\}

#### Tarihler ve saat dilimleri \{#dates-and-timezones\}

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](general#3-reporting-timezone).

#### Apple mali takvimi \{#the-apple-fiscal-calendar\}

Apple, satış dönemlerini ve ödeme tarihlerini belirlemek için kendi [muhasebe takvimini](https://adapty.io/apple-fiscal-calendar/) 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 ilgili satış dönemine karşılık gelen bir [özel tarih aralığı](controls-filters-grouping-compare-proceeds#time-ranges) seçin.

#### İşlem tarihleri \{#transaction-dates\}

Bazı hizmetler (örneğin AppsFlyer), işlemleri görüntülerken [kohort](analytics-cohorts) kuralları uygulayabilir ve işlemleri gerçekleştiği tarihe değil, uygulamanın yüklendiği tarihe atfedebilir.

## Gelir hesaplama \{#revenue-calculation\}

### Ücretler ve vergiler \{#fees-and-taxes\}

[Ayara](controls-filters-grouping-compare-proceeds#store-commission-and-taxes) bağlı olarak Adapty grafikleri **brüt gelirinizi**, **mağaza komisyonu sonrası gelirinizi** veya **mağaza komisyonu ve vergi sonrası gelirinizi** gösterebilir.

Bazı mağazalar ve üçüncü taraf platformlar brüt geliri gösterme kapasitesine sahip olmayabilir ya da vergileri otomatik olarak düşebilir. İki farklı gelir grafiği arasında tutarsızlık görürseniz, karşılaştırmanın geçerli olduğundan emin olun.

### İptaller ve iadeler \{#cancellations-and-refunds\}

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ı \{#sandbox-purchases\}

[Etkinlik akışı](event-feed), 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 \{#installs-and-downloads\}

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](general#4-installs-definition-for-analytics) bağımsız olarak yalnızca kullanıcı uygulamayı başlattığında kurulumu kaydedebilir.

## Ülke ve mağaza \{#country-and-store\}

Doğru raporlama sağlamak için Adapty, kullanıcının ülkesini IP adresinden [tahmin edebilir](controls-filters-grouping-compare-proceeds#filtering-and-grouping). Mağazalar ise indirme ve satın alımları her zaman belirli bir uygulama mağazasına atfeder.

İkisi arasında net bir ayrım yapmanız gerekiyorsa, `Country by store account` özniteliğiyle [yeni bir kullanıcı segmenti oluşturabilir](segments) ve [segmente göre analitik filtreleyebilirsiniz](controls-filters-grouping-compare-proceeds#filtering-and-grouping).

## Ürün fiyatlandırması \{#product-pricing\}

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ı \{#attribution-conflicts\}

Adapty her işlem için [yalnızca tek bir attribution kaynağı](attribution-integration#prevent-data-issues) 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ı \{#differences-in-terminology\}

Farklı platformlar aynı kavram için farklı isimler kullanabilir. [Gelirle](#fees-and-taxes) 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](reactivated-subscriptions) 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**.
- **Elde tutma (Retention)**:
        - Adapty elde tutmayı abonelik yenileme sayısına göre ölçer.
        - App Store Connect, kullanıcının belirtilen günde uygulamayı açıp açmadığına bakarak elde tutmayı değerlendirir. Aboneliği olmayan bir kullanıcı sayılır, ancak o gün uygulamayı açmayan aboneli kullanıcı sayılmaz.
        - Google Play Console'un "Retained Installers" metriği elde tutmayı, uygulamanın kullanıcının cihazında yüklü kaldığı gün sayısına göre ölçer. Uygulamayı açmayan kullanıcılar da bu metriğe dahil edilir.