· 13 dk · Samet Durgun

Trial ve purchase event'lerim Meta AEM için neden uygun değil?

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ı Signal engineering konusunun altında; hakkımda daha fazlası.

Events Manager’a ulaşan bir event, henüz optimize edebileceğiniz bir event değildir. Meta her iOS event’ini Aggregated Event Measurement için ayrı ayrı uygun veya uygun değil olarak işaretler, ve listelediği nedenler arasında install event’inizden farklı bir entegrasyon üzerinden gönderilen bir event, yolun taşıması gereken eksik veri veya son 30 günde çok az sinyal yer alır. Hangisinin geçerli olduğu yolunuza bağlıdır: RevenueCat’in doğrudan Meta’ya göndermesinin gereksinimleri, RevenueCat’in AppsFlyer’a gönderip AppsFlyer’ın Meta’ya postback olarak ilettiği yolun gereksinimlerinden farklıdır.

Benim hesaplarımda genellikle tek bir sıra sorunu giderir: Events Manager’da AEM’i kurun ve MMP’de probabilistic attribution’ı açın, bir install kampanyası çalıştırın, ve optimizasyonu ancak Events Manager event’in uygun olduğunu gösterdikten sonra trial’a veya purchase’a taşıyın. Bu benim pratiğim, Meta’nın belgelediği bir düzeltme değil; ayrıntılar aşağıdaki kurulum sırası bölümünde.

Kapsam: AEM kullanan ve app event’leri veya value için optimize eden iOS 14+ için Meta app promotion kampanyaları (Meta’nın “maximize number of app events” ve “maximize value of conversions” hedefleri). Baştan sona ayrı tutulan iki yol: RevenueCat’ten doğrudan Meta’ya, ve RevenueCat’ten AppsFlyer’a, oradan Meta’ya. Kurulum sırası bölümü Adjust ve Singular’daki eşleşen ayarları da adlandırıyor. Buradaki hiçbir şey tek bir bölgeye özgü değil. Aşağıdaki her sağlayıcı sayfası 29 Eylül 2026’da kontrol edildi. Meta’nın yardım sayfaları tarih göstermiyor ve haber vermeden değişiyor, bu yüzden harekete geçmeden önce yeniden kontrol edin.

Meta bir event’in uygun olmadığını nerede söylüyor?

Events Manager’da. Meta’nın How to check if your app events are eligible for Aggregated Event Measurement sayfası yolu veriyor: Datasets, dataset’iniz, Settings sekmesi, Setup tasks for iOS app events, ardından “Meta’s attribution for iOS 14+” bölümündeki Check app eligibility. Eligibility sütunu her event’i uygun veya uygun değil olarak işaretler, More details nedenini açıklar, ve pending durumu Meta’nın entegrasyonunuzdan hâlâ bilgi beklediği veya bilgiyi doğruladığı anlamına gelir.

Meta’nın Troubleshoot issues with app eligibility for Aggregated Event Measurement sayfası her mesajı ne anlama gelebileceği ve çözümüyle birlikte listeliyor. Kimse kuruluma dokunmadan önce tam mesajı ve tarihi kaydedin, çünkü o sayfadaki her mesaj farklı bir çözüme işaret ediyor.

Sorun alınma mı, gerekli veri mi, uygunluk mu?

“Event çalışmıyor” ifadesinin arkasında üç farklı soru yatıyor:

  • Alınma. Meta event’i hiç aldı mı? RevenueCat’in Meta Ads sayfası, Events Manager’ın kabul edilen event’leri göstermesinin 24 saate kadar sürebileceğini söylüyor.
  • Gerekli veri. Event, yolunuzun AEM için ihtiyaç duyduğu her şeyi taşıyor mu? Bu yola göre değişir.
  • Optimizasyon uygunluğu. Meta bir kampanyanın onun için optimize etmesine izin verecek mi? RevenueCat’in sayfası, başarılı bir teslimatın yalnızca Meta’nın event’i kabul ettiği anlamına geldiğini ve event’in bir kampanya, hedef veya rapor için uygun olup olmadığına yine de Meta’nın karar verdiğini açıkça söylüyor.

Tablo, sık görülen belirtileri katmana göre sıralıyor. Yol sütunu önemli: bir yol için belgelenmiş bir gereksinim diğeri hakkında kanıt değildir.

Katman Belirti İncelenecek sistem Gereken kanıt Sonraki adım
Alınma StartTrial veya Subscribe Events Manager’da yok (RevenueCat doğrudan) RevenueCat Customer History, Meta Ads teslimat satırı Request ve Response sekmeleri; Conversions API için fbtrace_id Satır yoksa: gerekli attribute’ları kontrol edin ve eksik teslimat satırı için RevenueCat’in sorun giderme adımlarını izleyin. Kabul edildiyse: Events Manager’a bakmadan önce RevenueCat’in belgelediği 24 saate kadar olan süreyi bekleyin
Alınma Event’ler AppsFlyer’da yok (AppsFlyer yolu) RevenueCat customer attribute’ları $appsflyerId’nin purchase’tan önce ayarlanıp ayarlanmadığı Purchases SDK’sını yapılandırdıktan sonra ve ilk purchase’tan önce ayarlayın
Gerekli veri Meta’ya az sayıda App Store event’i ulaşıyor veya hiç ulaşmıyor (RevenueCat doğrudan) RevenueCat Meta Ads ayarları ve customer attribute’ları $fbAnonId veya gerçek bir IDFA, ATT durumu, “Send events when ATT consent is not authorized” ayarı İzin ayarına kendi gizlilik incelemenizle bilinçli olarak karar verin
Gerekli veri Server to server event’ler uygun değil (AppsFlyer yolu) Ham bir event payload’u Her event’te IP adresi ve IDFV var Purchase’tan önce $ip ve $idfv ayarlanacak şekilde RevenueCat’te cihaz identifier’larını toplayın
Gerekli veri “Contact your mobile measurement partner (MMP) to check eligibility steps for Meta’s attribution for iOS 14+” MMP dashboard’u MMP’nin AEM ayarının açık olup olmadığı Açın; kurulum sırası bölümü bunu MMP’ye göre adlandırıyor
Gerekli veri “IP data version isn’t optimal for setup” Mesajda adı geçen entegrasyon IP’nin eksik mi yoksa tutarsız mı gönderildiği IP’yi tutarlı gönderin; AppsFlyer yolunda IP masking’i kapatın
Gerekli veri “Advertiser Tracking Enabled parameter volume out-of-range” Gelen event’lerdeki ATT durumu Tracking’i etkin olmayan veya IDFA’sı sıfırlanmış event’lerin payı ATT izin oranını kontrol edin; Meta bu mesaj için sizi account manager’ınıza yönlendiriyor
Uygunluk “Different integrations across multiple event types” Events Manager, install event’i ve trial veya purchase event’i Her birini hangi entegrasyonun gönderdiği Install ve optimizasyon event’ini aynı entegrasyon üzerinden gönderin
Uygunluk “Multiple integrations for the same event” Events Manager, Manage event Event’i gönderen her kaynak Event için tek bir entegrasyon seçin; yinelenen client side loglamayı kaldırın
Uygunluk “Not enough signals from last 30 days” Events Manager ve Test Events aracı 30 günlük event sayıları Kurulumu test event’leriyle doğrulayın, ardından yolun ne kadar hacmi geçirdiğine bakın
Uygunluk Pending, “Awaiting or verifying information from your integration” Events Manager Durumun göründüğü tarih Meta’nın söylediği gibi 3 gün içinde yeniden kontrol edin

RevenueCat doğrudan yolu neye ihtiyaç duyuyor?

RevenueCat’in Meta Ads sayfası burada önemli olan dört noktayı ortaya koyuyor.

Meta SDK’sı kalır. RevenueCat, install, activation ve cihaz üzerindeki sinyaller için Meta SDK’sını tutmanızı söylüyor; server to server event’leri install kampanyaları, SKAdNetwork veya AEM için Meta’nın SDK kurulumunun yerini almıyor. Güvenilirlik ve uzun vadeli destek için App Events API yerine Conversions API’yi öneriyor, ve uygulama açık değilken trial conversion’larını ve renewal’ları gönderebildiğini not ediyor.

Teslimat identifier’lara ve izne bağlı. Conversions API üzerinden giden App Store event’lerinde RevenueCat, yalnızca müşteride $fbAnonId veya $idfa ile birlikte authorized bir ATT durumu varsa, dashboard’daki “Send events when ATT consent is not authorized” ayarı etkin olmadıkça teslimat dener. Boş veya sıfırlanmış IDFA değerlerini eksik sayıyor. IDFV, IP, e-posta ve telefon numarası teslimat için şart koştuğu attribute’lar arasında değil; bunları, mevcutlarsa Meta’nın eşleştirme için kullanabileceği attribute’lar olarak listeliyor. RevenueCat, bunları mümkün olduğunda SDK’sını yapılandırdıktan sonra ve ilk purchase’tan önce ayarlamanızı, ATT izni verildikten sonra da cihaz identifier’larını yeniden toplamanızı istiyor.

RevenueCat, ayarı devre dışı bırakmanın App Store event’leri gönderilmeden önce authorized ATT iznini gerektirdiğini söylüyor. Sayfası yeni bir entegrasyonda ayarın açık mı kapalı mı başladığını açıkça söylemiyor, bu yüzden Meta’nın event sayılarından bir sonuç çıkarmadan önce ayara kendi dashboard’unuzda bakın. Yani ayar devre dışıyken, takibe izin vermeyen kullanıcıların App Store trial ve purchase event’leri bu yolda Meta’ya gönderilmez, ve Meta RevenueCat’in kaydettiğinden daha az event görür. Benim okumam, küçük bir hesapta bunun “Not enough signals from last 30 days” mesajına giden makul yollardan biri olduğu. Ayarı etkinleştirmek bir gizlilik kararıdır, ölçüm ayarı değil.

Subscribe kapsamı geniş. RevenueCat varsayılan olarak Trial Started’ı StartTrial’a, Trial Converted, Initial Purchase ve Renewal’ı ise Subscribe’a eşler. Yenilenmeyen bir purchase fb_mobile_purchase’a gider. Yani Events Manager’daki bir Subscribe sayısı ilk ödemelerle renewal’ları karıştırır. RevenueCat bu event’ler için başka Meta standart event adları seçmenize izin veriyor ve Meta’nın kampanya optimizasyonu için standart event’leri önerdiğini not ediyor. Biri eşlemeyi değiştirdiyse, başka her şeyden önce kampanyanızın hangi event adı için optimize ettiğini kontrol edin.

Event başına tek kaynak, ve entegrasyon sorusu. RevenueCat, Meta SDK’sı ile RevenueCat bir event_id paylaşmadığı için, kendisinin gönderdiği event’ler için client side purchase ve revenue loglamasını kaldırmanızı söylüyor. Meta’nın sorun giderme sayfası burada önemli olan bir kural ekliyor: bir event install event’inizden farklı bir entegrasyon üzerinden geldiğinde app event veya value hedefleri için uygun olmayabilir, ve çözüm ikisi için de aynı entegrasyonu kullanmak. Meta’nın About Partner Integrations for app events sayfası, value optimization önerilerinde Facebook SDK’sını, bir MMP’yi ve Conversions API’yi ayrı kanallar olarak adlandırıyor ve her event’i yalnızca birinden göndermenizi istiyor. Doğrudan yolda install’lar Meta SDK’sından, trial’lar ve ödemeler Conversions API’den geliyor. Burada alıntılanan Meta sayfaları, Meta’nın bu ikiliyi bu kural için iki entegrasyon sayıp saymadığını söylemiyor, bu yüzden varsaymak yerine Events Manager’da her iki event için seçilen entegrasyonu kontrol edin.

AppsFlyer yolu neye ihtiyaç duyuyor?

RevenueCat event’leri AppsFlyer’a gönderiyor, AppsFlyer de bunları Meta’ya postback olarak iletiyor. İki sayfa gereksinimleri belirliyor, ve bunlar birbirinden farklı.

AppsFlyer’ın Meta Ads Aggregate Event Measurement (AEM) for iOS sayfası, server to server gönderilen uygulama içi event’lerde Meta’nın event payload’unda hem IP adresini hem de IDFV’yi şart koştuğunu, bunlar olmadan event’in AEM’de Meta attribution’ı için uygun olmadığını söylüyor. RevenueCat’in AppsFlyer sayfası yalnızca $appsflyerId’yi zorunlu işaretliyor. $idfa, $idfv ve $ip’yi önerilen olarak listeliyor, ve attribute’ları Purchases SDK’sı yapılandırıldıktan sonra ve ilk purchase’tan önce ayarlamanızı istiyor, AppsFlyer ID’si olmadan bazı event’lerin teslim edilemeyebileceği uyarısıyla. RevenueCat’in collectDeviceIdentifiers yardımcısı $idfa, $idfv ve $ip’yi topluyor. Bu yolda “önerilen”i AEM için zorunlu sayın, çünkü AppsFlyer Meta’nın ikisine de ihtiyaç duyduğunu söylüyor.

AppsFlyer’ın uygun olmayan event’ler için sorun giderme checklist’i, kendi sırasıyla ve remarketing kampanyaları için olan adımı dışarıda bırakarak:

  1. Meta Ads entegrasyonunda Advanced Data Sharing açık (Collaborate, Active Integrations, Meta Ads). Kapalıyken yalnızca advertiser ID’si olan kullanıcıların event’leri paylaşılıyor. AppsFlyer’ın özet tablosu bunu app promotion için AEM’i etkinleştiren toggle olarak adlandırıyor, ve aşağıdaki kurulum sırasındaki MMP ayarı bu.
  2. App Settings’te IP masking kapalı. AppsFlyer, IP’si maskelenmiş event’lerin uygun olmadığını söylüyor.
  3. Her server to server event’te IP adresi ve IDFV.
  4. ATT izin oranı gözden geçirilmiş. Meta, eksik veya sıfırlanmış IDFA’lı sınırlı bir event hacmini kabul ediyor.
  5. Postback’ler “Send all (including organic)” olarak eşlenmiş. Meta’nın partner sayfası da aynı tavsiyeyi veriyor.
  6. Event’ler uygun değil olarak kalırsa, Events Manager’da MMP trafiğini tercih edilen bağlantı olarak ayarlayın.

RevenueCat ayrıca çift saymayı önlemek için AppsFlyer SDK’sındaki client side revenue takibini kaldırmanızı istiyor. Benim okumam, aynı event’leri gönderen başka bir kaynak olmadığı sürece, bu yolun install’ları ve trial veya purchase event’lerini tek bir entegrasyona koyabileceği, ki Meta’nın aynı entegrasyon çözümünün istediği de bu.

Meta hâlâ uygulamaları sekiz event’le sınırlıyor mu?

Bir uygulamanın AEM yapılandırması için sekiz event yuvasını ortaya koyan Meta’nın “How to configure app events to use Meta’s Aggregated Event Measurement” sayfası artık Page Not Found döndürüyor (29 Eylül 2026’da kontrol edildi), yani AEM için sekiz app event’ini sıralamanızı söyleyen rehberler Meta’nın artık belgelemediği bir kurulumu anlatıyor. Meta’nın About Meta’s Aggregated Event Measurement sayfası app kampanyalarında güncellemeleri kademeli olarak yaydığını, bunlarla birlikte app promotion kampanyalarını SKAdNetwork için app event’lerini yapılandırmadan çalıştırabildiğinizi, ve optimizasyon için daha fazla app event’inin kullanılabildiğini söylüyor. Meta’nın hâlâ belgelediği event sıralaması SKAdNetwork yapılandırmasına ait: About value sets sayfası orada 1 ile 63 arasında priority ID’leri tarif ediyor, ve AEM üzerinden gönderilen event’ler için value set’leri etkinleştirmeniz gerekmediğini söylüyor. Meta’nın sorun giderme sayfasındaki mesajların hiçbiri yuva sırasıyla ilgili değil, bu yüzden bir teşhisi buna harcamayın.

Bir düzeltmeden sonra ne kadar beklemeliyim?

Tek bir şeyi değiştirin, tarihi yazın, ardından geçerli olan pencereyi bekleyin:

  • Kabul edilen event’lerin Events Manager’da görünmesi 24 saate kadar sürebilir (RevenueCat).
  • Seçilen entegrasyondaki bir değişikliğin yansıması, Meta’nın Choose a single integration for app events in Meta Events Manager if you send events from multiple integrations sayfasına göre 24 saate kadar sürebilir.
  • Beklemedeki bir event: 3 gün içinde yeniden kontrol edin (Meta).
  • Bir mesajı çözmek için bir entegrasyon seçtikten sonra: yeniden kontrol için 7 güne kadar, ve bu sürede kampanya düzenlemeleri kullanılamayabilir (Meta).
  • AppsFlyer’ın checklist’inden sonra: Meta’nın uygunluğu yansıtması için 2 ila 3 güne kadar (AppsFlyer).

Bir pencerenin içinde iki değişiklik yaparsanız, hangisinin işe yaradığını söyleyemezsiniz.

Hangi kurulum sırası genellikle sorunu giderir?

Benim hesaplarımda bu sıra genellikle uygun olmayan bir trial veya purchase event’ini düzeltiyor, ve yeni bir uygulamada bunu ilk install kampanyasından önce kuruyorum. Meta’nın sorun giderme sayfası çözümleri arasında bir install kampanyası listelemiyor, bu yüzden üçüncü adımı Meta’nın talimatı olarak değil, benim deneyimim olarak okuyun.

  1. İlk install kampanyasından önce Events Manager’da AEM’i kurun. Dataset’in Settings sekmesini açıyorum, Setup tasks for iOS app events’e gidiyorum ve “Meta’s attribution for iOS 14+” bölümünü tamamlıyorum, sorduğunda Meta’nın şartlarını kabul ederek. Kontrol ettiğim Meta sayfaları uygulamalar için ayrı bir AEM toggle’ı veya şartlar adımı belgelemiyor: About Meta’s Aggregated Event Measurement app kampanyası güncellemelerini almak için bir işlem gerekmediğini, ancak uygulamanızı uygun hale getirmek için işlem yapmanız gerekebileceğini söylüyor. Events Manager size bir istem gösteriyorsa kabul edin; göstermiyorsa devam edin.
  2. MMP’de probabilistic attribution’ı ve AEM ayarını açın. Meta’nın Recommendations for setting up Meta Aggregated Event Measurement with a mobile measurement partner sayfası, MMP dashboard’unuzda bulunan her AEM toggle’ını veya ayarını açmanızı, app promotion ile retargeting için ayrı ayarlar gerekip gerekmediğini kontrol etmenizi istiyor, ve IP paylaşımını kısıtlamanın veya izin vermeyen kullanıcılar için veri paylaşımını sınırlamanın toggle açık olsa bile sorun çıkarabileceği konusunda uyarıyor. Meta’nın sayfası probabilistic attribution’dan söz etmiyor; onu açmak benim pratiğim. Ayarların adı MMP’ye göre değişir:
    • AppsFlyer: Meta Ads entegrasyonunda Advanced Data Sharing. AppsFlyer’ın özet tablosu bunun app promotion için AEM’i etkinleştirdiğini söylüyor, advertiser ID’si olmayan kullanıcıların event’leri ve geçerli oldukları yerlerde deterministik olmayan claim’ler dahil. Probabilistic toggle App Settings’te duruyor, ve AppsFlyer’ın sayfası ona iki ad veriyor: tabloda “Enable view-through attribution via probabilistic modeling” ve metinde “Enable view-through attribution via campaign measurement modeling”. View through claim’lerini kapsıyor, ve onu da açıyorum.
    • Adjust: Meta kurulum sayfası entegrasyonun AEM install kampanyalarını otomatik desteklediğini, ve probabilistic modeling’in uygulama seviyesinde kapatmış olsanız bile tüm AEM install kampanyası link’leri için varsayılan olarak açık olduğunu söylüyor. Yine de bir link’in attribution ayarlarından değiştirilebiliyor, bu yüzden orada kimsenin kapatmadığını kontrol edin. “Enable AEM for MAE” toggle’ı install’lar için değil, retargeting kampanyaları için.
    • Singular: Facebook partner yapılandırmasında “Include Advanced AEM Attributions”, varsayılan olarak işaretli. Meta integration sayfası, varsayılan yapılandırmanın ATT izni vermemiş kullanıcıların event’lerini zaten gönderdiğini söylüyor.
    • RevenueCat doğrudan: yolda hiçbir MMP yok. En yakın ayar yukarıda ele alınan “Send events when ATT consent is not authorized”, ve o bir gizlilik kararı.
  3. Önce bir install kampanyası çalıştırın. Install için optimize eden bir app promotion kampanyası başlatıyorum, ve Meta’dan trial’lar veya purchase’lar için optimize etmesini ancak bundan sonra istiyorum. Neden işe yaradığına dair okumam: install kampanyası Meta’dan daha nadir bir event için optimize etmesi istenmeden önce ona install’ları ve o kullanıcılardan sonraki event’leri veriyor. Meta’nın sayfası bunu söylemeden buna yaklaşıyor: “Integration quality issue” için verdiği nedenlerden biri “We’ve received a low number of install events”, ve çözümü bir install kampanyası çalıştırmak değil, tüm conversion event’lerini göndermek.
  4. Uygun göründüğünde optimizasyon event’ini taşıyın. Kampanyayı trial veya purchase için maximize number of app events ya da maximize value of conversions hedefine geçirmeden önce, yukarıda anlatıldığı gibi Eligibility sütununu kontrol edin.

İki sınır. More details eksik bir alanı veya bölünmüş bir entegrasyonu adlandırıyorsa, o çözüm önce gelir: bir install kampanyası eksik bir IDFV eklemez, bir IP’nin maskesini kaldırmaz veya bir event’i install’ın entegrasyonuna taşımaz, daha fazla bütçe de yapmaz. Yol temizse ve event fazla nadirse, mesele bir subscription uygulamasının hangi event için optimize etmesi gerektiği sorusuna dönüşür.

Takibi reddeden kullanıcılar için IP ve IDFV göndermek izinli mi?

Bu sizin hukuki kararınız, ve buradaki hiçbir şey hukuki tavsiye değildir. Apple’ın User privacy and data use sayfası, IDFV’nin bir kullanıcıyı diğer şirketlerin uygulamaları ve web siteleri genelinde takip etmek için başka verilerle birleştirilemeyeceğini söylüyor, ve geçerli yasalara uymayı size bırakıyor. AppsFlyer, Advanced Data Sharing’i açmadan önce bunun platform politikalarınıza ve düzenlemelere uygun olduğunu doğrulamanızı istiyor.

Meta desteğine başvurmadan önce hangi kanıtları toplamalıyım?

Meta’nın sorun giderme sayfası birkaç mesajı Meta account manager’ınıza yönlendiriyor, AppsFlyer de her destek talebinde uygun olmayan event’lerin ekran görüntüsünü istiyor. Şunlarla gelin:

  1. Eligibility sütununun tarihli bir ekran görüntüsü ve More details mesajının tamamı.
  2. Dataset ID’si, app ID’si ve her event adı, gönderildiği gibi, standart mı özel mi olduğu not edilerek.
  3. Install event’i ile trial veya purchase event’i için seçilen entegrasyon, ve her birini gönderen tüm kaynakların listesi.
  4. RevenueCat doğrudan için: yakın tarihli bir test müşterisinin teslimat satırı, Request, Response ve fbtrace_id ile.
  5. AppsFlyer yolu için: IP ve IDFV’nin var olduğunu gösteren, bilgileri gizlenmiş bir server to server event, ayrıca Advanced Data Sharing, IP masking ve postback ayarları.
  6. Son 30 gündeki ATT izin payı.
  7. Yapılan her değişikliğin tarihiyle birlikte kaydı ve her birinden sonra ne kadar beklediğiniz.

Meta için CAPI ve event eşlemesini kim düzeltebilir?

Bu, signal engineering kapsamında üstlendiğim iş: her event’i purchase’tan Events Manager’a kadar izlemek, hangi entegrasyonun ona sahip olacağına karar vermek, ve kimse bid’lere veya bütçelere dokunmadan önce yolun eksik bıraktığını düzeltmek.

Bir uygulamanın Meta’daki ilk install kampanyasından önce Events Manager’da AEM’i kuruyorum, Meta’nın şartlarını sorduğu yerde kabul ediyorum, ve MMP’de varsa AEM ayarıyla birlikte probabilistic attribution’ı açıyorum. Install kampanyası ancak ondan sonra yayına girer, ve Events Manager trial veya purchase’ı uygun olarak işaretledikten sonra optimizasyon event’i o olur.

Kaynaklar

Her sayfa 29 Eylül 2026’da açılıp kontrol edildi.

Sık sorulan sorular

RevenueCat'ten bir purchase göndermek onu Meta AEM için uygun yapar mı?

Hayır. RevenueCat'in Meta Ads sayfası, başarılı bir teslimatın Meta'nın event'i kabul ettiği anlamına geldiğini, Meta'nın ise event'in bir kampanya, optimizasyon hedefi veya rapor için uygun olmadığına yine de karar verebileceğini söylüyor. Alınma ile uygunluk ayrı kontrollerdir.

Server to server event'ler Meta AEM için IP adresine ve IDFV'ye ihtiyaç duyar mı?

AppsFlyer yolunda evet: AppsFlyer, Meta'nın server to server gönderilen uygulama içi event'lerin payload'unda ikisini de şart koştuğunu ve bunlar olmadan event'lerin AEM'de Meta attribution'ı için uygun olmadığını belgeliyor. RevenueCat'in doğrudan Meta entegrasyonu teslimat için IDFV veya IP şart koşmuyor, mevcutlarsa eşleştirme için kullanıyor, yani gereksinim her kurulum için değil, yola aittir.

Meta, bir düzeltmeden sonra AEM uygunluğunu ne kadar sürede güncelliyor?

Düzeltmeye bağlı. AppsFlyer, kendi checklist'i tamamlandıktan sonra 2 ila 3 güne kadar diyor. Meta, beklemedeki bir event'in 3 gün içinde yeniden kontrol edilmesi gerektiğini, bir entegrasyon seçtikten sonra yeniden kontrolün 7 güne kadar sürebileceğini ve bu sürede kampanya düzenlemelerinin kullanılamayabileceğini söylüyor.

Meta hâlâ iOS uygulamalarını sekiz AEM event'iyle sınırlıyor mu?

Sekiz event yuvasını ortaya koyan Meta'nın AEM için app event'lerinin yapılandırılmasına dair sayfası Page Not Found döndürüyor (29 Eylül 2026'da kontrol edildi), yani AEM için sekiz app event'ini sıralamanızı söyleyen rehberler Meta'nın artık belgelemediği bir kurulumu anlatıyor. Meta'nın hâlâ belgelediği event sıralaması SKAdNetwork yapılandırmasına ait, ve AEM uygunluk mesajlarından hiçbiri yuva sırasıyla ilgili değil.

Bir install kampanyası veya daha fazla bütçe event'lerimi uygun hale getirir mi?

Deneyimlerime göre bir install kampanyası genellikle sorunu giderir, iki kurulum adımından sonra çalıştırıldığında: Events Manager'da AEM kurulumu, Meta'nın şartları sorduğu yerde kabul edilmiş halde, ve MMP'de probabilistic attribution ile birlikte varsa AEM ayarı açık. Events Manager event'in uygun olduğunu gösterdikten sonra optimizasyonu trial'a veya purchase'a taşırım. Bu benim pratiğim, Meta'nın talimatı değil: sorun giderme sayfası çözümleri arasında hiçbir harcama seviyesi ve hiçbir install kampanyası sıralamıyor. Tek başına daha fazla bütçe eksik bir alan eklemez ve bir event'i install'ın entegrasyonuna taşımaz.