Signal engineering nedir, ve ATT sonrası neyi düzeltir?

Muhtemelen buradasınız çünkü

Bunların hiçbiri medya satın alma sorunu değil. Sinyal sorunları, ve çoğu düzeltilebilir.

• Meta bir ROAS raporluyor, RevenueCat onun yarısını raporluyor, ve finans ikisine de inanmıyor. Hiçbir zaman uyuşmayacaklar, ve ekipte kimse nedenini söyleyemiyor.
• SKAN conversion value'larınız çoğu kampanyada boş dönüyor ve kimse nedenini bilmiyor.
• Meta sorunsuz ölçekleniyor. Google ve TikTok aynı kreatifte tıkanıyor.
• Value optimization'a geçtiniz ve daha kötüye gitti.
• Trial başlangıçları ucuz ve ücretli dönüşümler hiç gelmiyor.
• Uygulamada üç SDK var. Conversion value'nun sahibinin hangisi olduğunu kimse söyleyemiyor.

Signal engineering neyi düzeltir

Beş katman, kurduğum sırayla.

• Event katmanı. Uygulamanız için tek bir kanonik event taksonomisi, Meta standart event'lerine, Google dönüşüm event'lerine, TikTok event'lerine ve MMP'nize açıkça eşlenmiş. Trial başlangıcı, ilk ödeme, yenileme, iptal, iade. Her biri bir value, bir para birimi ve bir ID ile.
• Sunucu taraflı gönderim. Meta'nın uygulama event'leri için Conversions API'si, TikTok'un Events API'si ve Google'ın uygulama dönüşüm kurulumu, MMP'niz ya da Firebase üzerinden, abonelik backend'inize bağlanmış, böylece yenilemeler, iadeler ve trial dönüşümleri uygulama kapalıyken bile platformlara ulaşır. Event ID ile tekilleştirilmiş, böylece hiçbir şey iki kez sayılmaz.
• iOS conversion value şeması. Apple'ın geri göndermenize izin verdiği o küçük value, takibi reddeden kullanıcılar için aldığınız tek post install sinyal. Onu funnel'ınıza ve hacminize göre tasarlıyorum, böylece kampanyalar hiçbir şey döndürmek yerine Apple'ın gizlilik eşiklerini aşıyor. Sahibi tek bir SDK. İki SDK yazdığında son çağrı kazanır, ve şu anda bu genelde bir kaza.
• Bidding için value sinyalleri. Satın alma value'su, marj ya da tahmini LTV, Meta dahil her platforma gönderilir, ve ancak value'nun kullanıcıların sonradan ödediğiyle gerçekten korele olduğunu kontrol ettikten sonra. Kötü bir value algoritmaya yanlış kullanıcıları daha hızlı satın almayı öğretir.
• Uzlaştırma görünümü. Platform, MMP, RevenueCat ve mağaza ödeme rakamlarının aylık tek bir karşılaştırması, beklenen farklar yazılı olarak, böylece rakamlar bir dahaki sefer uyuşmadığında yapısal mı yoksa bug mı olduğunu beş dakikada bilirsiniz.

ATT sonrası neyi düzeltemez, ve bunu neden söylüyorum

iOS 14.5'ten beri App Tracking Transparency'yi reddeden kullanıcılar kullanıcı seviyesinde attribute edilemiyor. Apple'ın SKAdNetwork'ü ve AdAttributionKit, cihaz tanımlayıcısı olmayan gecikmeli, toplu postback'ler döndürüyor, ve düşük hacimli kampanyalarda detayı bilerek saklıyor. Hiçbir Conversions API entegrasyonu, hiçbir MMP özelliği ve hiçbir attribution kurtarma aracı bunu değiştirmiyor. Meta bu event'leri Aggregated Event Measurement üzerinden yönlendiriyor. Google modelliyor. TikTok modelliyor.

Bu yüzden deterministik attribution vaat etmiyorum. Vaat ettiğim, kontrol edebildiğiniz sinyallerin doğru olması, platformların optimize etmek için mümkün olan en iyi girdiyi alması, ve hangi farkların normal olduğunu bilmeniz. Platform ROAS'ı ile abonelik geliri iş bittikten sonra da uyuşmayacak. Açıklayabildiğiniz nedenlerle uyuşmayacaklar. Bir tedarikçi size aksini söylüyorsa, kullanıcı ID'sinin nereden geldiğini sorun.

iOS'ta hangi sistem neyi raporluyor?

Aynı iOS kampanyalarından gelen install'ları ve dönüşümleri beş ayrı sistem sayıyor, ve uyuşmadıklarında hiçbiri yanlış olmak zorunda değil. Farklı şeyleri, farklı pencerelerde, farklı gecikmelerle sayıyorlar. Tablo her sağlayıcının kendi dokümantasyonuna dayanıyor, 29 Eylül 2026'da kontrol edildi.

Google'ın iOS tarafı sizden de iş istiyor. Integrated Conversion Measurement için Google şunları sıralıyor: install için aktif bir iOS App kampanyası, MMP'nizin first_open ve install sonrası event'lerinin Google Ads'e aktarılması, event verisiyle cihaz üzerinde ölçüm, ve güncel bir MMP SDK'sı. Event verisiyle cihaz üzerinde ölçüm için iOS 12 veya üstü, 11.14.0 sürümünden itibaren Google Analytics for Firebase SDK'sı ve Google Ads'e bağlı bir Analytics mülkü gerekiyor, ve Google bunun AEA, Birleşik Krallık ve İsviçre'deki kullanıcılar için etkin olmayacağını söylüyor. Yani Google Ads, MMP ve SKAN yapıları gereği uyuşmuyor, ve Google'ın kendi önerisi ICM'yi kurduysanız ICM görünümünü, kurmadıysanız Google Ads'i ya da SKAN'ı okumak. Her entegrasyon yolu için ICM kurulumu ve Google Ads, MMP ve SKAN'ı nasıl uzlaştırdığım ayrı birer yazıda anlatılıyor.

Bazı farkların tanımlarla hiç ilgisi yok. Yönettiğim bir Google hesabında revenue event'i, bir dönüşümün value'su olmadığında $0 yerine $1 gönderiyordu, bu da Google'ın raporladığı ROAS'ı her yerde, en çok da iOS'ta şişirdi. Bu, bid stratejisi testimi yaptığım hesap, ve uzlaştırma görünümü tam da bu tür bug'ları yakalamak için var.

iOS'taki Meta kampanyalarında SKAN 4 ve AdAttributionKit nasıl çalışır?

Neyin geri döneceğine Apple karar veriyor: kazanan reklam başına en fazla üç gecikmeli postback, her birinde uygulamanızın cihazda yazdığı bir conversion value, ve kampanya küçüldükçe daha az detay. Meta'da her iOS uygulama tanıtım reklam seti, optimizasyon event'inizin hangisine uygun olduğuna göre ya bu SKAdNetwork attribution'ını ya da Meta'nın kendi Aggregated Event Measurement'ını kullanıyor.

SKAN 4 ve AdAttributionKit'in ikisi de üç postback penceresi döndürüyor, ve yalnızca ilki fine bir value taşıyabiliyor. Bir kampanya kalabalığı koruyamayacak kadar küçük olduğunda Apple coarse'a ya da hiçbir şeye düşüyor. 7 günlük bir trial'ın ilk ödemesi 7. ya da 8. güne, yani ikinci ya da üçüncü pencereye, coarse bir value olarak düşer, günler sonra. Şemanın bir şablondan kopyalanmayıp funnel'ınıza ve hacminize göre tasarlanması gerekmesinin, ve çok fazla geo ve kreatif bölünmesinin her kampanyayı aynı anda eşiğin altına itmesinin nedeni bu. Her trial süresinin hangi pencereye düştüğü ve değeri kimin yazdığı, SKAN'ın ücretsiz trial sonrasındaki ödemeyi ölçüp ölçemeyeceğini anlatan yazıda.

Meta için CAPI'yi ve event mapping'i kim düzeltebilir?

Uygulama SDK'sından ve MMP'den abonelik backend'ine ve Events Manager'a kadar tüm event yolunun sahibi olan biri, çünkü Meta'daki sinyal bug'larının çoğu bunlardan ikisinin kesiştiği yerde duruyor. Retainer'da bu kişi benim; SDK ve sunucu işi için ağımdan bir attribution mühendisi, sizin tarafınızda da değişiklik çıkarabilecek bir geliştirici oluyor.

Uygulama event'leri için Conversions API, SDK'nın ya da MMP'nin cihazdan gönderdiği event'lerin aynısını sunucunuzdan gönderir, ve Meta bunları event ID ile tekilleştirir. İşi bütünlük ve value: yenilemeler, iadeler ve uygulama kapalıyken gerçekleşen dönüşümler, her biri bir value ve bir para birimiyle. Takibi reddeden kullanıcılar için attribution'ı geri getirmez; o event'ler hâlâ Aggregated Event Measurement üzerinden akar. Yapmaya değer, bir geçici çözüm değil. Bir event Meta'ya ulaştığı halde AEM için uygun değil diye işaretleniyorsa, her yol için kontroller trial ve purchase event'lerinin Meta AEM için neden uygun olmadığını anlatan yazıda.

pLTV ve value optimization

Bir model, her yeni kullanıcının value'sunu ilk bir iki günün davranışından tahmin eder. O rakam platforma satın alma value'su olarak gider, ya da iOS'ta conversion value'nun içine sıkıştırılır. Platform sonra yüksek value tahminlerinize benzeyen kullanıcılar için bid verir. Hangi event'in ve hangi bidding modunun hangi uygulamaya uyduğu $1.2M'lık Meta harcamasından yazıldı.

Videa'da o katman, özel bir CAPI purchase sinyali ve bidding içinde tahmini LTV, D0 ROAS'ı %20'den rekor haftada %43'e taşıyan şeydi. $606K'lık bir test, gün sıfır value'nun D28 ROAS'ı cost per purchase'tan daha iyi tahmin ettiğine karar verdi.

Hangi event'e göre optimize etmelisiniz?

Bir hesap daha derine geçmeden önce sırayla sorduğum üç soru bunlar. Install'dan yukarıya doğru merdivenin tamamı bir abonelik uygulamasının hangi event'e göre optimize etmesi gerektiği yazısında.

1. Ücretli event'ler hacminizde platformun öğrenme eşiğini aşıyor mu? Meta'nın rehberi, son önemli düzenlemeden sonraki haftada reklam seti başına yaklaşık 50 sonuç. Aşmıyorsa trial başlangıcı artı bir aktivasyon event'ine göre optimize edin. Aşıyorsa 2. soruya geçin.
2. Trial'dan ücretliye geçiş sağlıklı mı? Değilse trial başlangıcı artı bir aktivasyon event'inde kalın. Satın almaya geçmeden önce iki koşulun da sağlanması gerekiyor. Sağlıklıysa satın almaya geçin ve 3. soruya gidin.
3. Göndereceğiniz value, kullanıcıların sonradan ödediğiyle korele mi? Değilse satın almada kalın. Koreleyse value'yu gönderin. Tahmini LTV'nin üç şeye daha ihtiyacı var: tahminin gerçekten olgunlaşmış kohortlara göre kalibre edilmiş olması, yeterli hacim, ve platformun bunu attribution penceresi kapanmadan alması. Erken açıldığında, büyük bir güvenle yanlış kullanıcılara doğru optimize eder.

Platform ROAS'ını abonelik geliriyle uzlaştırmak, ülkeler genelinde

Platformlar attribute edilmiş ve modellenmiş dönüşümleri kendi pencerelerinin içinde, brüt fiyattan, tıklama tarihinde sayar. RevenueCat makbuzları işlem tarihinde, iadeler düşülmüş olarak, tek bir para biriminde sayar. Mağaza ödemeleri mali takvimde, komisyon ve yerel vergi düşülmüş olarak gelir. Bunlar yapısal farklar, ve beklenirler. Bir aydan diğerine büyüklüğü değişen bir farkın arkasında genelde bir bug vardır: çift sayılmış bir satın alma event'i, bir para birimi uyuşmazlığı, bir platforma ulaşıp diğerine ulaşmayan bir value.

Çok ülkeli ROAS buna kohort olgunluğunu ekler. Kullanıcıları yıllık ödeyen bir ülke, aylık satan bir ülkeye göre 7. günde daha kötü, 90. günde daha iyi görünür, bu yüzden hangi ülkenin bütçe alacağına karar vermeden önce kohortları eşit yaşta, tek bir para biriminde, komisyon düşülmüş olarak karşılaştırıyorum. $383K'lık denetim bunun gerçek bir hesapta nasıl göründüğü, ve bir ROAS'ın anlam kazanması için kaç satın alma gerektiği her kesit için tabanı belirliyor.

İş nasıl yürüyor

Signal engineering retainer'ın bir parçası, ve önce geliyor. Okuma growth audit ile başlıyor: her platformun şu anda ne aldığı, neye doğru optimize ettiği, ve beklenen sapma yazılı olarak dört yönlü karşılaştırma. Okumadan sonra bazı ekipler düzeltmeleri önceliklendirilmiş listeden, her madde için tahmin edilmiş mühendislik eforuyla kendileri uyguluyor. Bazıları hesapları yürütmemi istiyor. İkisi de uygun.

SDK işi ve sunucularınızda çalışan her şey için ağımdan bir attribution mühendisi getiriyorum. Katmanı ben tasarlıyor ve sahipleniyorum; mühendislik elleri uzmanlar. Çalışma süresince değişiklik çıkarabilecek bir geliştiriciye, ve Events Manager'a, MMP'ye, RevenueCat'e ya da abonelik backend'inize, ve reklam hesaplarına okuma erişimine ihtiyacınız var.

Retainer'dan daha erken bir aşamadaysanız ve çalışma olmadan teşhisi istiyorsanız, ücretli 90 dakikalık bir seans kurulumunuzu ve neyin hangi sırayla düzeltileceğini kapsıyor. Tanışma görüşmesiyle aynı takvim üzerinden alınıyor.

Sık sorulan sorular