Meta Pixel ve Conversions API Farkı: Doğru Dönüşüm Ölçümü
YellowStar Design · 1 Kasım 2026 · 10 dakika okuma
Meta Pixel tarayıcı tarafındaki olayları, Conversions API ise sunucu veya bağlı platformlardan gelen olayları Meta’ya iletmek için kullanılır. Birbirlerinin basit birer yedeği gibi düşünülmemelidirler. Birlikte kullanıldıklarında aynı gerçek işlem iki kanaldan gelebilir; bu nedenle olay tanımı, izin yönetimi, doğru veri kaynağı ve çift sayımı önleyen eşleştirme birlikte tasarlanmalıdır. CAPI kurmak bütün satışları görme veya reklam maliyetini kesin düşürme garantisi değildir.
Bu rehber, reklam veren işletmelerin teknik kurulum teklifini değerlendirebilmesi için hazırlanmıştır. Çalışan bir entegrasyon kodu veya herkese uygulanacak tek bir kurulum reçetesi değildir. Mevcut sitenin ve reklam hesabının değerlendirilmesi için Meta reklam hesabı denetimini, kampanya yönetimi için Adana Meta reklam yönetimi hizmetini inceleyebilirsiniz.
Bu rehberde: Meta Pixel ile Conversions API arasındaki temel fark · Kurulumdan önce olay sözlüğü hazırlayın · Aynı işlem neden iki dönüşüm olarak sayılabilir? · Hizmet işletmesinde doğru form ölçümü nasıl tasarlanır? · E-ticarette sipariş, ödeme ve iade ayrımı · Sunucu tarafı ölçüm kullanıcı tercihini geçersiz kılmaz · Hazır entegrasyon mu, özel sunucu bağlantısı mı? · Yayına almadan önce uygulanacak test matrisi · Events Manager'da görünen olay neden tek başına yeterli değil? · Meta, GA4 ve CRM neden aynı sayıyı göstermeyebilir? · Kurulum teklifinde hangi teslimleri istemelisiniz?
Meta Pixel ile Conversions API arasındaki temel fark
Tarayıcı tarafında bir etiket, kullanıcının sayfada yaptığı eylemlerle ilgili olayları iletebilir. Sunucu tarafında ise uygulamanın veya bağlı sistemin doğruladığı bir işlem temel alınabilir. Örneğin bir form düğmesine basılması tarayıcıda gözlenebilirken, başvurunun veritabanına başarıyla kaydedildiği bilgisi uygulama tarafında doğrulanır. İkisi farklı aşamaları temsil eder.
Meta’nın Conversions API genel açıklaması, web sitesi, uygulama, CRM ve diğer kaynaklardan pazarlama olaylarının Meta sistemlerine bağlanmasını ele alır. Hangi entegrasyonun uygun olduğu mevcut altyapıya bağlıdır. Hazır platform bağlantısı, yönetilen çözüm veya doğrudan entegrasyon arasında seçim yapılırken bakım sorumluluğu da değerlendirilmelidir.
| Konu | Meta Pixel | Conversions API |
|---|---|---|
| Çalışma tarafı | Tarayıcıdaki kurulum ve olay tetikleyicileri | Sunucu veya bağlı platformun olay iletimi |
| İşlem bilgisi | Sayfa ve kullanıcı arayüzündeki davranışlar | Kaynak sistemin doğruladığı işlem ve durum bilgileri |
| Başlıca denetim | Doğru sayfa, doğru tetikleyici, tekrar çalışan etiketler | Doğru kayıt durumu, güvenli bağlantı, gecikme ve yeniden gönderim |
| Birlikte kullanım | Aynı işlem için eşleştirme kimliği üretimi | Aynı işlem kimliğinin ilgili olayla korunması |
| Gizlilik | İzin ve veri kapsamı kontrolü gerekir. | İzin ve veri kapsamı kontrolü yine gerekir. |
| Tek başına kanıtlamadığı şey | Başvurunun veya satışın işletmede tamamlandığı | Gönderilen olayın kaliteli talep veya kesin reklam katkısı olduğu |
Kurulumdan önce olay sözlüğü hazırlayın
İlk toplantıda “Pixel var mı?” sorusundan önce “neyi başarı sayıyoruz?” sorusu cevaplanmalıdır. E-ticarette ürün görüntüleme, sepete ekleme, ödeme başlatma ve tamamlanmış sipariş farklı aşamalardır. Hizmet işletmesinde iletişim sayfası ziyareti, WhatsApp bağlantısına tıklama, başarılı form kaydı ve satış ekibinin nitelikli bulduğu talep ayrı sonuçlardır.
Her olay için tetikleyici, veri kaynağı, sorumlu kişi ve hariç tutulacak durumlar yazılmalıdır. Bu belge yalnızca geliştirici için değildir; reklam yöneticisinin raporu doğru yorumlamasını da sağlar. Örneğin “Lead” olayı düğme tıklamasında gönderiliyorsa raporda görünen değer, kaydedilmiş başvuru sayısı olarak sunulmamalıdır. Etiketin adı işin gerçek sonucunu değiştirmez.
- Olay: Hangi kullanıcı işlemi veya işletme sonucu ölçülüyor?
- Başarı koşulu: Hangi teknik yanıt ya da kayıt bu sonucu doğruluyor?
- Kaynak: Tarayıcı, uygulama, CRM veya entegrasyonlardan hangisi yetkili kaynak?
- Kimlik: Aynı işlemin tekrarını nasıl ayırıyoruz?
- Veri sınırı: Hangi alanlar gerekli, hangileri kesinlikle gönderilmeyecek?
- Test: Hatalı, tekrar eden ve izin verilmeyen akışta beklenen sonuç ne?
Aynı işlem neden iki dönüşüm olarak sayılabilir?
Bir işlem hem tarayıcıdan hem sunucudan iletilirse sistemin bunların aynı olayı anlattığını anlayabilmesi gerekir. Meta’nın çift olayları birleştirme belgesinde önerilen yaklaşım, eşleşen olay adı ile eşleşen olay kimliğidir. Pixel tarafındaki eventID ile sunucu tarafındaki event_id, aynı gerçek işlem için aynı değeri taşımalıdır. Ayrı işlemler için gelişigüzel aynı kimliği tekrar kullanmak da doğru değildir.
Temsili örnek: Bir teklif başvurusu başarıyla kaydedildiğinde sistemin ürettiği işlem kimliğini talep-ornek-001 olarak düşünelim. Tarayıcıdaki başarı olayı ve sunucudaki ilgili olay bu başvuruyu aynı kimlikle temsil eder. İki taraf birbirinden bağımsız rastgele kimlik üretirse aynı başvurunun ilişkisi kaybolabilir. Bu örnek gerçek müşteri verisi değildir ve doğrudan çalıştırılacak entegrasyon kodu içermez.
Çift sayım yalnızca iki farklı kanal arasında oluşmaz. Aynı etiketin hem tema hem eklenti hem de etiket yöneticisinde bulunması, düğmenin birden fazla dinleyiciyle izlenmesi veya teşekkür sayfasının her yenilenmesinde yeniden olay gönderilmesi de incelenmelidir. Sorunu yalnızca CAPI alanına bakarak aramak eksik bir denetim olur.
Hizmet işletmesinde doğru form ölçümü nasıl tasarlanır?
Önce formun işletme açısından tamamlanma anı tanımlanır. Kullanıcı gerekli alanları doldurduğunda ve sunucu geçerli kaydı kabul ettiğinde başvuru oluşmuş olabilir. Buna rağmen bildirim e-postası ulaşmamış veya CRM aktarımı başarısız olmuş olabilir. Bu nedenle kayıt, bildirim ve ölçüm üç ayrı kontrol noktasıdır; birinin çalışması diğerlerinin çalıştığını kanıtlamaz.
Önerdiğimiz akış, önce doğrulanabilir başvuru kaydını esas alır. Kullanıcıya gösterilen başarı mesajı bu kayıtla ilişkili olmalıdır. Reklam ölçümüne giden olay ise izin ve veri işleme kuralları çerçevesinde aynı başarıya bağlanır. Kullanıcı hatalı e-posta yazdığında, zorunlu alanı boş bıraktığında veya sunucu hata verdiğinde başarı olayı oluşmamalıdır.
WhatsApp ve telefon bağlantıları farklı değerlendirilir. Bir bağlantıya tıklanması, görüşmenin gerçekleştiği veya satışa dönüştüğü anlamına gelmez. Bu sinyaller ayrı isim ve açıklamayla raporlanabilir. İşletmenin sonradan doğruladığı nitelikli taleplerle ilişki kurulacaksa bunun veri kaynağı, izin kapsamı ve operasyon sorumlusu ayrıca tasarlanmalıdır.
E-ticarette sipariş, ödeme ve iade ayrımı
E-ticaret kurulumunda “satın alma” olayının ne zaman oluştuğunu açıkça sorun. Sepet oluşturulması, ödeme ekranına geçiş, ödeme sağlayıcısının onayı ve siparişin işletmede kabulü aynı aşamalar değildir. Ödeme başarısızken satın alma olayı gönderen kurulum, reklam raporunu olduğundan iyi gösterebilir. Tekrar yüklenen sonuç sayfası da aynı siparişi yeniden üretmemelidir.
Değer ve para birimi tanımı tutarlı olmalıdır. Rapordaki değerin vergi, kargo veya indirimleri nasıl ele aldığı belgelenmeden finans tablosuyla birebir karşılaştırma yapılmamalıdır. İptal ve iadelerin hangi raporda işlendiği ayrıca açıklanmalıdır. Reklam panelindeki dönüşüm değeri, işletmenin kesinleşmiş net geliriyle aynı ölçü olmayabilir.
Denetimde birkaç kontrollü senaryo üzerinden işlem izi tutulabilir: başarılı sipariş, başarısız ödeme, yeniden deneme ve aynı onay ekranına dönüş. Bu senaryoların gerçek para hareketi doğurup doğurmadığı önceden belirlenmelidir. Canlı ödeme testi, harcama yetkisi ve ilgili tarafların onayı olmadan başlatılmamalıdır.
Sunucu tarafı ölçüm kullanıcı tercihini geçersiz kılmaz
CAPI, tarayıcı kısıtlarını veya kullanıcı tercihlerini aşmak için sınırsız veri toplama izni değildir. Teknik tasarımda hangi verinin hangi amaçla işleneceği, izin durumunun nerede değerlendirileceği ve izin verilmeyen akışta hangi gönderimlerin duracağı açık olmalıdır. Uygulanacak hukuki çerçeve ve metinler yetkin danışmanla değerlendirilmelidir; bu yazı hukuki görüş yerine geçmez.
Formdaki serbest metinleri, sağlık veya ödeme ayrıntılarını, parolaları ve gereksiz kişisel bilgileri reklam olaylarına taşımayın. URL parametreleri de gözden geçirilmelidir; bazı formlar veya uygulamalar kişisel bilgiyi adrese ekleyebilir. Bir alanı teknik olarak gönderebiliyor olmak, göndermenin uygun olduğu anlamına gelmez.
Veriyi hash’lemek de tek başına bütün gizlilik sorunlarını çözmez. Veri minimizasyonu, erişim sınırı, saklama süresi ve güvenli anahtar yönetimi ayrıca ele alınır. Erişim anahtarı herkese açık sayfa kodunda, ekran görüntüsünde veya paylaşılan raporda bulunmamalıdır. Yeni ajansla çalışma halinde teknik erişimlerin nasıl yönetileceği Meta hesap devri kontrol listesiyle birlikte düşünülmelidir.
Hazır entegrasyon mu, özel sunucu bağlantısı mı?
İşletmenin platformu güvenilir ve güncel bir hazır bağlantı sunuyorsa önce onun kapsamı değerlendirilir. Küçük bir ihtiyaç için ağır özel kod geliştirmek bakım yükünü artırabilir. Ancak hazır bağlantının hangi olayları hangi koşullarda gönderdiği belirsizse, yalnızca kurulum ekranında “bağlandı” yazması yeterli değildir. Olay tanımı ve test imkânı aranmalıdır.
Özel entegrasyon, daha fazla kontrol sağlayabilir ama sorumluluk da getirir: sürüm takibi, hata yönetimi, gecikmeler, tekrar gönderimler, gizli anahtarların korunması ve çalışan bağlantının izlenmesi. Teklifte sadece ilk kurulum değil, sonraki bakımın kime ait olduğu da bulunmalıdır. Bir eklenti güncellemesinden sonra tetikleyici değişirse bunu kimin fark edeceği belirlenmelidir.
Mevcut Pixel, veri kümesi ve reklam hesabı sahipliği net değilse önce bu yapı düzeltilir. Yanlış veri kaynağına yeni bağlantı eklemek karmaşayı büyütebilir. Meta domain doğrulaması da ayrı bir varlık kontrolüdür; alan adının doğrulanmış olması, dönüşüm olaylarının doğru çalıştığını tek başına göstermez.
Yayına almadan önce uygulanacak test matrisi
Aşağıdaki liste bir kabul testi taslağıdır. Test alıcısı, ortam, veri türü ve olası bildirimler işletme tarafından onaylanmalıdır. Gerçek müşterilere mesaj gönderilmemeli, üretim raporları gelişigüzel denemelerle kirletilmemelidir. Test olaylarıyla gerçek talep raporunun nasıl ayrılacağı önceden belirlenmelidir.
| Senaryo | Beklenen iş sonucu | Kontrol |
|---|---|---|
| Geçerli form gönderimi | Tek bir başarılı kayıt | Başarı olayı doğru kayıtla eşleşiyor. |
| Eksik veya hatalı alan | Başarılı başvuru yok | Başarı dönüşümü gönderilmiyor. |
| Sunucu hatası | İşlem tamamlanmamış | Buton tıklaması başarı yerine sayılmıyor. |
| Teşekkür sayfasını yenileme | Yeni başvuru yok | Aynı kayıt yeni dönüşüm olarak üretilmiyor. |
| İki kanaldan aynı işlem | Tek gerçek sonuç | Olay adı ve kimliği uyumlu, çift sayım kontrol edilmiş. |
| İzin verilmeyen akış | Tercih korunuyor | Tanımlanan gönderim sınırları her iki tarafta uygulanıyor. |
| Bildirim teslim hatası | Kayıt var, bildirim eksik olabilir | Ölçüm ile operasyon teslimi ayrı raporlanıyor. |
| Yanlış kaynak kimliği | Kurulum kabul edilmez | Site, veri kümesi ve reklam hesabı eşleşmesi düzeltiliyor. |
Events Manager'da görünen olay neden tek başına yeterli değil?
Meta’nın kurulum doğrulama belgesi; olayların alınmasını, gecikmeyi, çift kayıtların birleştirilmesini ve eşleşme kalitesini ayrı kontrol başlıkları olarak ele alır. Bu başlıklar tek bir “olay geldi” ekranına indirgenmemelidir. İlgili veri kaynağının kimliği ve bağlantı yöntemi de kayda alınmalıdır.
Bizim önerimiz, kontrollü bir işlemi uçtan uca izlemektir: uygulamadaki kayıt, uygun ölçüm olayı ve ilgili rapordaki karşılığı. Teknik kabul raporunda gerçek işlemle ilişki kurulamazsa, rastgele görünen bir olay yanlış güven yaratabilir. Eşleşme kalitesi puanı, talebin satışa uygunluğunu ölçmez; bu iki değerlendirme ayrı raporlanmalıdır.
Olayın platforma ulaşması ile belirli bir reklamın o sonuca katkı olarak yazılması da farklıdır. İlişkilendirme ayarları, rapor dönemi ve veri işleme süreçleri sonuçları etkileyebilir. Teknik gönderim denetimiyle reklam performansı değerlendirmesini birbirine karıştırmamak gerekir.
Meta, GA4 ve CRM neden aynı sayıyı göstermeyebilir?
Farklı araçlar aynı soruya cevap vermeyebilir. Bir araç olayları, diğeri oturumları, işletme sistemi ise benzersiz başvuru kayıtlarını gösterebilir. Tarih aralığı, saat dilimi, izin kapsamı, ilişkilendirme yaklaşımı ve filtreler eşitlenmeden toplamların farklı olması otomatik olarak arıza sayılmaz. Önce ölçülerin tanımlarını yan yana yazın.
Öte yandan farkı yalnızca “platformlar zaten farklı” diyerek geçiştirmeyin. Hatalı tetikleyici, eksik sunucu iletimi veya çift kurulum gerçek sorundur. İncelemeye tek bir kontrollü işlemden başlamak, büyük toplamlar üzerinde tahmin yürütmekten daha açıklayıcıdır. Sonra aynı tanımlı olaylar uygun rapor döneminde karşılaştırılır.
Hizmet satışında işletme için asıl sorulardan biri, başvuruların ne kadarının uygun müşteri olduğudur. Reklam panelindeki dönüşüm sayısını nitelikli talep, görüşme ve kazanılan iş kayıtlarıyla ayrı aşamalarda değerlendirin. Bu aşamalar arasında ilişki kurulacaksa kişisel veri güvenliği ve erişim yetkileri korunmalıdır.
Kurulum teklifinde hangi teslimleri istemelisiniz?
- Mevcut etiket, veri kaynağı ve entegrasyon envanteri.
- Olay sözlüğü: başarı tanımı, tetikleyici ve hariç tutulan durumlar.
- İzin ve veri alanı sınırlarının teknik uygulama açıklaması.
- Aynı işlem için kimlik üretme ve çift sayımı önleme yaklaşımı.
- Kontrollü test senaryoları, tarihli sonuçlar ve açık hatalar.
- Kayıt, bildirim ve ölçüm teslimatının ayrı kontrolü.
- Bakım sorumlusu, değişiklik günlüğü ve erişim devri planı.
- Kurulum sonrası hangi göstergelerin hangi aralıkta izleneceği.
Doğru hedef yalnızca “CAPI kuruldu” demek değildir. İşletmenin kabul ettiği olayın, izin verilen kapsamda, doğru kaynağa ve gereksiz tekrar olmadan iletildiğini gösterebilmektir. Sonrasında reklam sonuçları yeterli veri ve tutarlı dönemlerle değerlendirilir; kurulumun tek başına satış artışı sağladığı varsayılmaz.
Sık Sorulan Sorular
Conversions API kurunca Meta Pixel kaldırılmalı mı?
Otomatik olarak değil. Birlikte kullanım mümkün olabilir; hangi olayların hangi kanaldan gönderileceği ve aynı işlemin nasıl eşleştirileceği belirlenmelidir. Mevcut kurulum incelenmeden etiket silinmemelidir.
CAPI bütün kayıp dönüşümleri kesin olarak geri getirir mi?
Hayır. Veri kaynağı, izinler, olay tanımı ve entegrasyon kalitesi sonucu etkiler. Eksiksiz ölçüm veya belirli oranda performans artışı garantisi verilmemelidir.
WhatsApp düğmesine tıklama gerçek müşteri talebi midir?
Bu bir etkileşim sinyalidir. Mesajın gönderildiğini, görüşmenin başladığını veya satış gerçekleştiğini tek başına kanıtlamaz. Raporlarda doğrulanmış talep ve satıştan ayrı adlandırılmalıdır.
Olay sayısı birden arttıysa kurulum başarılı mı demektir?
Önce çift gönderim, değişen olay tanımı ve test trafiği kontrol edilmelidir. Daha fazla olay her zaman daha fazla gerçek sonuç anlamına gelmez. İşletme kayıtlarıyla kontrollü eşleştirme gerekir.
Eşleşme kalitesi yüksekse reklamlar kesin iyi çalışır mı?
Hayır. Teknik eşleşme göstergesi teklifin, kreatifin, hedef kitlenin veya satış sürecinin kalitesini ölçmez. Reklam performansı ve nitelikli talep sonuçları ayrıca değerlendirilmelidir.
Küçük bir hizmet işletmesinde nereden başlanmalı?
Önce gerçek başarı koşulu ve mevcut form akışı netleştirilmelidir. Kayıt, bildirim ve ölçüm kontrol edildikten sonra ihtiyaçla uyumlu entegrasyon seçilir. Gereksiz karmaşık kurulumdan kaçınılır.
Sunucu tarafı ölçümde izin kontrolü gereksiz olur mu?
Hayır. Kullanıcı tercihi ve veri işleme sınırları sunucu tarafında da dikkate alınmalıdır. Teknik gönderim yöntemi, gerekli izin ve gizlilik değerlendirmelerinin yerini tutmaz.
Denetim için erişim anahtarını göndermeli miyim?
Hayır. İlk değerlendirmede site adresi, kullanılan platform ve ölçülmek istenen sonuç yeterlidir. Gizli anahtarlar, parolalar ve müşteri kayıtları mesajla paylaşılmamalıdır.
Önce gerçek dönüşümü tanımlayalım
Sitenizde hangi işlemin müşteri talebi sayıldığını, şu anda nerede kaydedildiğini ve hangi reklam hesabına raporlandığını birlikte netleştirebiliriz. Ölçüm ve hesap denetimi kapsamını inceleyin veya dönüşüm ölçümü için teklif talebi oluşturun.