· 9 dk · Samet Durgun · Platform bilgilerinin kontrolü:

AppLovin uygulamam için incremental mı ve bunu nasıl test ederim?

Ben Samet Durgun, bir fractional Head of UA'yım. Subscription uygulamaları ve mobil oyunlar için paid UA yürütüyorum ve yönettiğim hesaplarda gördüklerimi burada yazıyorum. Bu yazı Fractional Head of UA konusunun altında; hakkımda daha fazlası.

AppLovin uygulamanız için ancak, kapatmanın size başka yerden gelmeyecek install ve gelire mal olacağı kadar incremental’dır. MMP’nizdeki ya da AppLovin dashboard’undaki hiçbir ROAS rakamı bunu söylemez, çünkü o rakamlar nedeni değil, krediyi gösterir. Bunu cevaplayan test geo holdout’tur: AppLovin eşleştirilmiş bölgelerde kapalı, geri kalan her yerde açıktır, ikisi aynı anda. Sonuçlar mağaza ve backend verisinden okunur, güven aralığıyla birlikte incremental ROAS olarak raporlanır. Belirleyici olan, sonucu coğrafyaya göre ölçüp ölçemediğiniz. Ülkeler her uygulamada işe yarar. ABD eyaletleri ve metro bölgeleri ise yalnızca verileriniz ABD’yi bu şekilde bölebiliyorsa işe yarar. Bölemiyorsa cevap, henüz bilmediğinizdir.

Kapsam: bir MMP üzerinden atfedilen AppLovin Ads uygulama kampanyaları (iOS ve Android), tüm bölgeler; AppLovin, Impact, Apple, Google, Meta ve Haus sayfaları 1 Ekim 2026’da kontrol edildi. AppLovin’in destek sayfalarında güncelleme tarihi yok, bu yüzden elinizdeki tek tarih kontrol tarihi.

Bir AppLovin incrementality sonucu yayımlamadım. Aşağıdakiler bir hesapta uygulayacağım yöntem. AppLovin’in kendi dokümantasyonundan ve herkese açık deney araçlarından yola çıkarak kurdum, bir sonuç raporu değil.

AppLovin bir uygulama hesabında ne için kredi alıyor?

Uygulamalarda AppLovin attribution’a tek başına karar vermez. Set up MMP tracking sayfası, AppLovin Ads’te kampanya yürütmek için bir mobile measurement partner (Adjust, AppsFlyer, Kochava, Tenjin, Singular veya Branch) ile tracking yapılandırmanız gerektiğini ve tracking’i herhangi bir kampanya yayına girmeden önce kurmanız gerektiğini söylüyor. AppLovin platformunun adını AppLovin Ads olarak değiştirdi ve onu 22 Haziran 2026’da tüm reklamverenlere açtı; Axon ise AI öneri sisteminin adı olarak kalıyor.

Partner sayfaları ayarları tek tek yazıyor. AppLovin’in AppsFlyer sayfası şunları istiyor: “All media sources, including organic” için install ve uygulama içi event postback’leri, açık install view through attribution, en az 7 günlük bir click through lookback ve en az 24 saatlik bir view through lookback. Adjust sayfası ise tüm attribution kaynaklarından veri, en az 7 günlük bir tıklama penceresi ve en az 24 saatlik bir impression penceresi istiyor.

AppLovin’in yalnızca tıklama saydığı ve bu yüzden temkinli olduğu iddiasını uygulamalara taşımamak gerekir. Bu iddia AppLovin’in Haziran 2026 tarihli Different numbers, one channel: making sense of AppLovin through a measurement lens yazısından geliyor; yazı ağırlıklı olarak e-ticaret ve tüketici markaları için yazılmış ve oradaki platform içi raporlamanın yalnızca click through attribution’ı kapsadığını söylüyor.

Bir view through penceresi, AppLovin’in install’dan önceki pencere içinde o cihaza reklam gösterdiğini ve MMP’nin krediyi AppLovin’e verdiğini gösterir. Reklamın install’a neden olduğunu göstermez. Bir playable görüp o akşam uygulamayı zaten arama üzerinden yükleyecek olan biri yine de sayılır. Organic postback’leri de AppLovin’in organic kullanıcılar için kredi aldığı anlamına gelmez; bunlar AppLovin’e her install ve event hakkında veri gönderir, kimin kredi alacağına ise yine MMP karar verir.

Atfedilen gelir, konu incrementality’ye gelmeden önce de yanlış olabilir. Şubat 2026’da yürüttüğüm 27K $’lık Google Ads bid stratejisi testinde hesabın gelir event’i, conversion’ın değeri olmadığında 0 $ yerine 1 $ gönderiyordu. Google’ın raporladığı ROAS baştan sona, en çok da iOS’ta şişti. Bu yüzden bir network’ün neye neden olduğunu test etmeden önce ona ne gönderildiğini kontrol ederdim. Atfedilen rakamlar hiçbir şey bozuk değilken de birbirini tutmaz ve hangi farkların normal olduğunu Google Ads, MMP ve SKAN iOS conversion’larını neden farklı sayar yazısı anlatıyor.

Bir incrementality yüzdesi gerçekte ne anlama geliyor?

Paydaya bağlı. Birbirinden çok farklı iki rakam aynı etiketi taşıyor.

  • Bir baseline üzerindeki lift: deney bölgelerinin, kontrolün onlar için öngördüğünü yüzde kaç aştığı. Baz, AppLovin olmasaydı gerçekleşecek olandır.
  • Atfedilen gelirin incremental payı: AppLovin’e kredi olarak yazılan gelirin, o olmasaydı gerçekleşmeyecek olan yüzdesi. Baz, atfedilen gelirdir.

İkisi de bir maliyet rakamı değil. Bir lift rakamı, incremental geliri onu üreten harcamaya bölene kadar verimlilik hakkında hiçbir şey söylemez. Ben incremental ROAS’ı raporlardım: incremental gelirin deney bölgelerindeki AppLovin harcamasına bölümü, yanında aynı bölgeler ve tarihler için atfedilen ROAS. Incremental, atfedilenin üzerinde de çıkabilir: incelediğim bir hesapta, iOS’ta paid Meta install’ının 100 fazla olduğu günlerde MMP’de yaklaşık 28 organic install daha görünüyordu. Bu, attribution’ın paid’i eksik de sayabildiğini gösteriyor.

Başkasının lift rakamına göre hareket etmeden önce hangi sonucun ölçüldüğünü, ne kadar harcandığını, testin ne kadar sürdüğünü ve aralığın ne kadar geniş olduğunu bilmek isterdim.

AppLovin’i kapatıp açmak bunu neden cevaplamıyor?

Çünkü haftalar da değişiyor. AppLovin’i martta kapatıp nisanda yeniden açmak iki farklı ayı karşılaştırır: mevsimsellik, bir live ops event’i, mağazada öne çıkarılma, bir fiyat testi ve Meta ya da Google’daki değişiklikler aynı karşılaştırmaya girer, paid harcama da sonraki organic install’lara taşar. Google’ın Meridian sayfası Intro to analysis, counterfactual’ı zamana dayalı regresyonla tahmin ediyor; bu da bir test öncesi dönemden ve test döneminden zaman serileri, ayrıca testten önce sabitlenmiş tasarım ve geo ataması gerektiriyor. Kontrol grubu, deney grubuyla aynı anda çalışmak zorunda.

AppLovin için bir geo holdout’u nasıl tasarlardım?

Hem hedefleyebildiğiniz hem ölçebildiğiniz bir geo birimi seçin. AppLovin’in Campaign Management API’si country_code ile hedefliyor. Yalnızca ABD içinde ayrıca region_codes (eyaletler) veya metro_names (metro bölgeleri) kabul ediyor ve bu ikisi birleştirilemiyor. Geo hariç tutma alanı bulamadım, yani holdout bölgesi, hedeflemeden bıraktığınız bir bölgeden ibaret.

Testin AppLovin’in ölçekleme tavsiyesini bir süreliğine bozduğunu kabul edin. Scale your campaign, desteklediğiniz tüm ülkeleri tek bir global bütçeyle seçmenizi ve kampanya genelinde günde en az 15 ila 20 conversion’a yetecek bir bütçe öneriyor. Bir holdout bölgeleri bilerek çıkarır, bu yüzden deney bölgelerinin o conversion hacmi için yine yeterli bütçeye ihtiyacı var.

Harcamadan önce boyutlandırın. Meta’nın açık kaynak GeoLift Methodology sayfası, tahmin için augmented synthetic control’ü çıkarım için generalized synthetic control ile birleştiriyor ve güç hesaplayıcıları test süresini, yatırımı, hangi pazarların ve kaç tanesinin kullanılacağını öneriyor. AppLovin’in ölçüm yazısı, markalarla yürüttüğü testler için holdout’ların tipik olarak coğrafi kapsamın %20 ila %50’si olduğunu, en az %90 istatistiksel güç için tasarlandığını ve bir test başlamadan önce kampanyaların öğrenme aşamasından çıkıp istikrarlı yayın yapması gerektiğini söylüyor. Bunlar markalar için rakamlar, bir uygulama kuralı değil, ama güç gereksinimi uygulamalara da taşınıyor.

Geri kalan her şeyi sabit tutun. AppLovin’deki goal’ü, target’ı ve creative seti değiştirmeyin ve test sırasında kampanyaları yeniden kurmayın: API goal_type ve roas_day_target değerlerini yalnızca oluşturma sırasında belirliyor. Diğer kanalların bütçelerini, fiyatlandırmayı, promosyonları ve live ops’u deney ve kontrol bölgelerinde aynı tutun, ya da en azından birlikte hareket etmelerini sağlayın.

Optimizasyon penceresini aşacak kadar sürdürün. AppLovin’in Setting up your app campaign sayfası Day 7 ve Day 28 target’ları sunuyor ve daha uzun pencerelerin genellikle en değerli kullanıcıları hedeflediğini (“generally target highest value users”) söylüyor. Kampanya Day 28’e optimize ediyorsa, geliri okumadan önce test sırasında yüklenen cohort’ların iki grupta da aynı yaşa gelmesi gerekir.

Soru Cevabı veren Rakamların geldiği yer Size söyleyemediği
AppLovin ne için kredi aldı? MMP attribution, en az 7 günlük tıklama ve en az 24 saatlik view through pencereleriyle MMP raporları O kullanıcıların zaten gelip gelmeyeceği
Siparişe hangi partner dokundu? Impact Incrementality % Impact’in attribution modeli Nedensel hiçbir şey; kontrol grubu yok
AppLovin neye neden oldu? Geo holdout, bir aralıkla birlikte lift ve incremental ROAS Territory bazında mağaza konsolları, backend geliri Testin dışında kalan bölgelerdeki veya dönemlerdeki etkiler
AppLovin zaman içinde mix genelinde nasıl karşılaştırılıyor? Deneylerle kalibre edilmiş MMM Harcama ve sonuç zaman serileri Nedeni, bir deney onu sabitlemedikçe

Sonuç verisi nereden geliyor?

AppLovin’in dashboard’undan değil, yalnızca MMP’nin atfettiği install’lardan da değil, çünkü test edilen rakamlar bunlar. App Store Connect Analytics uygulama metriklerini territory’ye göre filtrelemenize izin veriyor; Apple bunu müşterinin fatura adresine göre belirliyor. Google Play’in View app statistics sayfası, kullanıcının ülkesi veya bölgesi anlamına gelen country/region’ı bir boyut olarak listeliyor. Gelir, aynı şekilde bölünmüş olarak subscription backend’inizden veya kendi defterinizden gelir.

Mağaza konsollarının hiçbiri ABD eyaletlerini listelemiyor, bu yüzden bir eyalet veya metro testi, eyaleti kaydeden sonuç verisi gerektirir. Tasarımı seçmeden önce bunu doğrulardım, çünkü ABD’nin bölünüp bölünemeyeceğini bu belirler.

Sonucu nasıl okurum?

Dört rakam raporlardım: incremental install’lar, incremental gelir, incremental ROAS ve onun güven aralığı, aynı bölgeler ve tarihler için atfedilen ROAS’ın yanında. Meridian’ın analizi de aynı biçimde raporluyor: lift, yüzde lift, güven aralıkları, p değerleri ve dolar başına incremental conversion; sonuç gelir olduğunda bunu incremental ROAS ile eş tutuyor.

Anlamlı çıkmayan bir sonuç genellikle sıfır değil, sonuçsuzdur: aralık, testin ne büyüklükte bir etkiyi kaçırmış olabileceğini gösterir. Aralık genişse sonraki adım hüküm vermek değil, daha uzun veya daha büyük bir test yapmaktır. Darsa, incremental ROAS’ın atfedilen ROAS’a oranını AppLovin’in target’ları üzerinde bir çalışma katsayısı olarak kullanırdım, yalnızca o bölgeler ve o dönem için. AppLovin’in ölçüm yazısı incrementality testini belirli bir ana ait deney olarak anlatıyor: holdout büyüklüğü, bütçe seviyesi, test süresi, geo bileşimi ve kampanya istikrarı birbirini etkiliyor. Bunlar değiştiğinde yeniden test ederdim.

MMM ve lift çalışmaları nereye oturuyor?

MMM, bir deney onu sabitlediğinde işe yarar. Meridian’ın Calibrate treatment priors sayfası, deneylerin ve MMM’lerin çoğu zaman farklı estimand’ları olduğunu söylüyor: MMM’in counterfactual’ı sıfır harcamadır, bazı deneyler ise belirli bir pencerede, bölgede ve kurulumda, azaltılmış harcamaya karşı ölçer. Bir deneyi prior’a çevirecek tek bir formül olmadığını, CalibrationBuilder’ının ise eski deneylere belirsizlik eklediğini ve harcama ölçeğine göre düzeltme yaptığını söylüyor. Arkasında deney olmayan bir MMM, AppLovin’in etkisine dair bir tahmin verir, onun bir testini değil.

Bulduğum yayımlanmış AppLovin lift sonuçları markalarla ilgili. Haus’un Is AppLovin More Than a Hype Channel? Lessons From Haus Incrementality Tests yazısı Ocak 2025’ten Mart 2026’ya kadarki geo holdout’ları kapsıyor. İçindeki reklamverenler DTC ve omnichannel markalar, bu yüzden yararlı bir bağlam ama uygulamalar veya oyunlar hakkında pek az şey söylüyor. Bir network sizin için bir lift testi yürütmeyi teklif ederse, test başlamadan önce tasarımı, sonuç kaynağını ve aralığı isteyin. Bir network’ün ekibi yalnızca o network’ü görür, mix genelindeki kararın sahibi olamamasının nedeni de bu. Bunu soft launch sonrasında bir mobil oyunun UA’sını kim yönetmeli yazısı anlatıyor.

Impact’in Incrementality %’si neden lift değil, modellenmiş kredi?

Bu, bir partner veya affiliate kanalı AppLovin’in yanında durup aynı kullanıcıları claim ettiğinde gündeme geliyor. Impact’in Incrementality FAQ sayfası Incrementality %’yi, modelden gelen toplam kesirli kredinin partner’ın yer aldığı toplam siparişe bölümü olarak tanımlıyor. Model, ilk ve son etkileşimlere en çok ağırlığı veren, 7 günlük time decay’li bir “U-Shaped Time Decay Attribution Model”. Aynı sayfa, yüksek bir Incrementality %’nin partner’ın “real additional value” sağladığı anlamına geldiğini söylüyor.

Karışıklık bu ifadeyle başlıyor. Skor, bir partner’ın Impact’in gördüğü yollardaki konumunu gösteriyor, o olmasaydı ne olacağını değil. Incrementality by Partner Report rolleri % Introduce, % Influence, % Close ve % Solo olarak ayırıyor, Adjusted CPA’yı toplam action maliyetinin incremental action’lara bölümü, Adjusted ROAS’ı ise incremental gelirin toplam action maliyetine bölümü olarak tanımlıyor ve en az 30 günlük veri öneriyor. Bu incremental girdiler modellenmiş kredinin kendisi, dolayısıyla düzeltilmiş rakamlar da modellenmiş. Incrementality Dashboard Explained sayfası, özelliğin belirli edition’lar veya add on’lar gerektirdiğini söylüyor. Bir partner için nedensellik sorusunu da aynı holdout mantığı cevaplar.

Bu soru benim işimin neresinde?

Meta’nın yanında AppLovin’de reklam alımı yapan bir oyun için, ikisinin birbirine nasıl oturduğunu mobil oyunlar için kullanıcı kazanımı sayfası anlatıyor. Growth audit her network’e ne gönderildiğini okur. Attribution’ın bir soruyu çözemediği ve önce testin gerektiği durumları da söyler, örneğin AppLovin’in incremental olup olmadığı sorusunda. Onu her harcama seviyesinde tek başına alabilirsiniz.

Kaynaklar

Hepsi 1 Ekim 2026’da kontrol edildi.

Sık sorulan sorular

AppLovin uygulama kampanyalarında view through install'ları sayıyor mu?

Uygulama kampanyalarında attribution MMP'niz üzerinden yürür ve AppLovin'in kurulum sayfaları view through pencereleri ister. AppsFlyer sayfası install view through attribution'ın açık olmasını, en az 24 saatlik bir view through lookback'i ve onun yanında en az 7 günlük bir click through lookback'i ister. Adjust sayfası en az 24 saatlik bir impression penceresi ister. AppLovin'in yalnızca tıklama raporladığı ifadesi, ağırlıklı olarak e-ticaret ve tüketici markaları için yazılmış Haziran 2026 tarihli ölçüm yazısından geliyor ve AppLovin'in kendi platform içi raporlamasını anlatıyor.

AppLovin'i kapatıp yeniden açmak incremental olup olmadığını kanıtlar mı?

Tek başına hayır. Önce ve sonra karşılaştırması, kanalı o haftalarda değişen her şeyle karıştırır: mevsimsellik, live ops event'leri, mağazada öne çıkarılma, diğer kanallar ve önceki harcamanın sonraya taşan etkisi. AppLovin'i takvimden ayıran şey geo holdout: AppLovin'siz bölgeler, AppLovin'li bölgelerle aynı haftalarda ölçülür ve testten önceki haftalara oturtulmuş bir modelle karşılaştırılır.

MMM, AppLovin'in uygulamam için işe yarayıp yaramadığını söyleyebilir mi?

Cevabı destekleyebilir, kesinleştiremez. Google'ın Meridian dokümantasyonu incrementality deneylerini modelin prior'larını belirlemek için belki de en güçlü temel sayıyor ve deneylerle MMM'in ROI'yi çoğu zaman farklı tanımladığı konusunda uyarıyor: MMM'in counterfactual'ı sıfır harcamadır, bir test ise kendi zaman penceresinde, bölgelerinde ve kampanya ayarlarında azaltılmış harcamayla kıyaslayabilir. Arkasında deney olmayan bir model, AppLovin'in etkisine dair bir tahmindir, kanıt değil.

Impact'in Incrementality %'si bir lift testi sonucu mu?

Hayır. Impact bunu, U biçimli, time decay'li attribution modelinden gelen toplam kesirli kredinin, partner'ın yer aldığı toplam siparişe bölümü olarak tanımlıyor; en çok ağırlığı ilk ve son temaslar alıyor. Bir partner'ın conversion yolunda nerede durduğunu gösteriyor. Maruz kalan kullanıcıları bir kontrol grubuyla karşılaştırmıyor, bu yüzden partner olmasaydı ne olacağını size söyleyemez.