Proje vitrini hazırlanıyorPreparing project showcaseПодготавливаем витрину проекта

Entegrasyonlar

Sunucu taraflı izleme ve Dönüşüm API'si (CAPI): çerez kaybına karşı reklam ölçümü

Sunucu taraflı izleme ve Dönüşüm API'si (CAPI), çerez kaybına rağmen dönüşüm ölçümünü kurtarır. Nasıl çalıştığını ve KOBİ'ler için kurulumunu anlatıyoruz.

Rocketly · 2026-08-04

Bir işletme sahibi, bir yıl önce yürüttüğü Meta ve Google kampanyalarını aynı bütçeyle, aynı teklifle bugün de yürütüyor — ama panolar artık CRM'ine düşen gerçek satışlardan çok daha az dönüşüm gösteriyor. Reklam hesabında bozulan bir şey yok. Bozulan şey ölçüm: reklam platformlarının on yıldır dayandığı tarayıcı temelli izleme, kimin dönüştüğünü görme yeteneğini sessizce kaybediyor.

Bu rehber; raporlanan dönüşümlerin neden azaldığını, sunucu taraflı izlemenin ne olduğunu ve Dönüşüm API'sinin (CAPI) olayları kendi sunucunuzdan doğrudan reklam platformlarına göndererek sinyali nasıl geri kazandırdığını sade bir dille anlatıyor. Konuyu, bünyesinde geliştirici bulundurmayan bir KOBİ için pratik tutacağız: mekanizma, bedeli, kurulum gerçeği ve tüm bunların birinci taraf verinizle nasıl bağlandığı.

1Dönüşüm olayı2Sunucu (server-side)3Conversions API4Reklam platformu

Ölçüm sorunu: Raporlanan dönüşümleriniz neden azalıyor?

Yıllarca reklam platformları dönüşümü bir tarayıcı pikseliyle ölçtü — sayfaya çerez bırakan ve biri sayfayı görüntülediğinde ya da satın aldığında tetiklenen bir kod parçası. Bu model aynı anda birkaç yönden aşınıyor ve bu yönlerin hiçbiri geri dönmeyecek. Tarayıcılar, siteler arası izlemenin dayandığı üçüncü taraf çerezleri giderek engelliyor ya da ömrünü kısaltıyor; Safari'nin Akıllı İzleme Önleme (ITP) özelliği erken ve sertti, diğerleri de peşinden geldi. Ziyaretçilerin azımsanmayacak bir kısmı, pikselin hiç tetiklenmesini engelleyen reklam engelleyici ya da gizlilik odaklı tarayıcılar kullanıyor. KVKK ve GDPR benzeri kurallar altında izleme çerezlerini reddeden biri, tarayıcı etiketi tarafından zaten ölçülmez. Apple'ın uygulama izleme değişiklikleri de platformların iPhone kullanıcılarından aldığı sinyali kesti.

Sonuç, reklamlarınızın çalışmayı bırakması değil — platformun, o reklamların ürettiği sonucun büyük bölümünü artık görememesi. Platformun otomatik teklif sistemi yalnızca görebildiği dönüşümlerden öğrendiği için, ölçümdeki bir kör nokta sessizce optimizasyonda da kör noktaya dönüşür. Gerekli olsa da çerez politikanız ve aydınlatma metniniz bile tarayıcının hiç kaydedemediği olayların payını artırır.

Sunucu taraflı izleme tam olarak nedir?

Sunucu taraflı izleme, ölçüm anını ziyaretçinin tarayıcısından çıkarıp sizin kontrol ettiğiniz bir sunucuya taşır. Tarayıcının engelleyebildiği, bir eklentinin söküp atabildiği, bir çerez kuralının ömrünü kısaltabildiği sayfa içi piksele tek başına güvenmek yerine, dönüşüm olayı bu kesintilerin geçerli olmadığı kendi altyapınızda kaydedilir ve gönderilir.

En basit haliyle şöyle düşünün: tarayıcı taraflı izleme, müşterinin reklam platformuna "bir şey satın aldım" demesidir — ve bu mesaj yolda kaybolabilir. Sunucu taraflı izleme ise kendi sisteminizin satışı doğrudan, hiçbir tarayıcı ayarının susturamayacağı bir yerden teyit etmesidir. İkisi rakip değildir; en sağlam kurulumlar her ikisini birden çalıştırıp uzlaştırır — Dönüşüm API'sinin tam olarak yapmak için tasarlandığı şey de budur.

Bunu bir kayıt defterine benzetebilirsiniz: tarayıcıdaki piksel, müşterinin masasında duran ve istediği an kapatabileceği bir nottur; sunucu tarafındaki kayıt ise sizin kasanızda durur ve silinip silinmeyeceğine yalnızca sizin sistemleriniz karar verir. İkinci kayıt her zaman daha az kaybolur ve raporunuzun omurgasını da o oluşturur.

Dönüşüm API'si (CAPI): Meta, Google ve TikTok

Dönüşüm API'si (çoğu zaman CAPI olarak kısaltılır), her büyük reklam platformunun olayları yalnızca tarayıcı pikseli üzerinden değil, doğrudan sunucudan sunucuya almak için sunduğu kanaldır. İsim platforma göre değişir ama fikir aynıdır.

  • Meta Dönüşüm API'si: Satın Alma ya da Potansiyel Müşteri gibi olayları doğrudan Meta'ya göndererek Meta reklamlarınızdaki pikseli tamamlar; böylece tarayıcının kaçırdığı dönüşümler yine de sayılır.
  • Google: gelişmiş dönüşümler ve Google Ads API, hash'lenmiş birinci taraf veriyi göndererek Google Ads için dönüşümleri kurtarır; GA4 ise Measurement Protocol üzerinden sunucu taraflı olayları kabul eder.
  • TikTok Events API: TikTok kampanyaları için aynı sunucudan sunucuya yaklaşım.

Her durumda vaat aynıdır: reklam platformuna gerçekte olanın daha eksiksiz ve daha kalıcı bir kaydını vermek; böylece tarayıcı sinyali soldukça ölçüm ve optimizasyon bozulmayı bırakır. Üstelik bu üç platform da aynı mantığı paylaştığı için, birinde kurduğunuz düzeni diğerlerine taşımak sıfırdan başlamak kadar zor değildir.

Kod olmadan nasıl çalışır?

Sunucu taraflı dönüşümleri güvenilir kılan üç fikri anlamak için tek satır kod okumanız gerekmez. Aşağıdaki üç kavram, kurulumu bir ajansa ya da bir araca bıraksanız bile sizin anlamanız gereken tek şeydir.

Olay kimliği ve tekilleştirme

Piksel ve sunucu aynı satın almayı bildirirse, bunun iki kez sayılmasını beklerdiniz. Sayılmaz — çünkü her olay ortak bir olay kimliği (event ID) taşır ve platform bu kimliği kullanarak tarayıcı olayı ile sunucu olayını tek ve aynı şey olarak tanır; hangisi gelirse onu tutar, kopyayı atar. Dolayısıyla iki kanalı birden çalıştırmak, sayıları şişirmeden kapsamı artırır.

Eşleştirme için hash'lenmiş müşteri verisi

Bir dönüşümü doğru reklam tıklamasına bağlamak için platformun olayı bir kişiyle eşleştirmesi gerekir — ama bu, ham kişisel veriyi teslim etmek anlamına gelmez. E-posta ve telefon gibi bilgiler, sisteminizden çıkmadan önce hash'lenir (geri döndürülemez bir dizeye çevrilir); platform, altta yatan e-postayı hiç görmeden hash'i eşleştirir. Bu bir veri boşaltımı değil, gizliliği koruyan bir el sıkışmadır.

Rıza kontrolü elinde tutar

Sunucu taraflı olmak, rızaya rağmen izleme yapmak demek değildir. Doğru bir kurulum ziyaretçinin tercihine yine saygı gösterir — reddeden biri için olaylar ya hiç gönderilmez ya da kişisel tanımlayıcılar olmadan gönderilir — dolayısıyla sunucuya geçmek, kuralların dışına çıkmadan doğruluğu artırır.

Sunucu taraflı izleme, gizlilik kurallarının etrafından dolaşan bir açık kapı değildir; doğru yapıldığında, zaten ölçmeye hakkınız olan dönüşümlerin daha dürüst bir sayımıdır.

Ne kazanırsınız: Optimizasyon ve atıf

Kazanç, daha büyük görünen gösteriş metrikleri değildir. Daha eksiksiz ve daha kararlı bir veri kümesidir ve ölçümün altındaki her şey onunla birlikte iyileşir.

Daha iyi veri önce atıfı (attribution) düzeltir — hangi kampanya ve kanalın gerçek satış ürettiğini, yarısı boş bir tablodan tahmin etmek yerine nihayet görebilirsiniz. Platform teklif sistemleri beslediğiniz dönüşümlerden öğrendiği için, daha dolu bir sinyal optimizasyonu doğrudan keskinleştirir: Performance Max ve Advantage+ gibi otomatik kampanyalar, ancak üzerinde eğitildikleri dönüşüm verisi kadar akıllıdır. Onları sinyalden yoksun bırakırsanız yanlış kişilere doğru optimize ederler; temiz olaylarla beslerseniz gerçekten satın alan müşterilerden daha fazlasını bulurlar. Bu fark bütçe dağıtımında da kendini gösterir: gerçekten satış getiren kanala daha güvenle yatırım yapar, yalnızca kolay ölçüldüğü için iyi görünen kanala aldanmazsınız.

Dönüşüm verinizi reklam platformlarına eksiksiz taşıyın

Rocketly, CRM'inizdeki temiz dönüşüm ve birinci taraf veriyi Meta, Google ve TikTok tarafına beslemeyi tek yerden yönetmenizi sağlar

Ücretsiz Deneyin

Bedeli ve kurulum gerçeği

Bunların hiçbiri bedava değildir ve aksini iddia etmek dürüstlük olmaz. Sunucu taraflı izleme, sitenize bir piksel yapıştırmaktan daha fazla altyapı ister.

  • Gönderecek bir yere ihtiyacınız var: sunucu taraflı bir etiket yöneticisi (örneğin sunucu taraflı bir Google Tag Manager kapsayıcısı), bir platform entegrasyonu ya da bağlantıyı sizin yerinize kuran bir araç.
  • Veri yönetişimi daha çok önem kazanır: artık müşteri verisini kendi sistemlerinizden geçiriyorsunuz; neyin toplandığı, hash'lendiği, saklandığı ve paylaşıldığı konusunda bilinçli olmanız gerekir.
  • Rıza ve KVKK uyumu sizin sorumluluğunuzdadır: olay artık bir sunucudan çıkıyor diye ziyaretçinin tercihine uyma yükümlülüğü ortadan kalkmaz.

Bir KOBİ için dürüst çıkarım şu: bunu elle nadiren kurarsınız. Ya kutudan çıktığı haliyle sunucu taraflı entegrasyon sunan bir platform kullanırsınız ya da diğer araçlarınızı zaten birbirine bağlayan aynı tür bağlantı mantığından geçirirsiniz — CRM'in devreye girdiği yer de burasıdır.

Birinci taraf veriyle bağlantısı

Sunucu taraflı izlemenin yakıtı birinci taraf veridir: müşterilerinizin sizinle doğrudan ve izne dayalı paylaştığı bilgiler — e-posta, telefon, sipariş geçmişi. Birinci taraf veri stratejiniz ne kadar sağlamsa, hash'lenmiş eşleştirme o kadar iyi çalışır ve platform dönüşümü doğru tıklamaya o kadar isabetli bağlar. Reklam engelleyicilerin ve çerez kurallarının en çok zayıflattığı şey bu eşleşmedir; birinci taraf veri ise tam burada devreye girip boşluğu doldurur.

İşte tam burada CRM'iniz bir ölçüm varlığına dönüşür. Çevrimiçi pikselin hiç göremediği olaylar — telefonda kapanan bir satış, WhatsApp'tan gelen bir sipariş, mağazada tamamlanan bir işlem — CRM'inizde durur. Bu çevrimdışı dönüşümleri geri besleyerek reklam platformlarına kampanyaların gerçekte ürettiği geliri öğretirsiniz; yoksa bu gelir ölçümün tamamen dışında kalırdı.

Geliştirici olmadan nasıl başlanır?

KOBİ için doğru başlangıç, kusursuz bir kurulum değil, işe yarayan mütevazı bir kurulumdur. Sırayla ilerleyin:

  • Tek platformla başlayın: en çok harcadığınız kanalın (çoğu zaman Meta ya da Google) Dönüşüm API'sini önce ona bağlayın.
  • Tekilleştirmeyi doğrulayın: piksel ve sunucu olaylarının aynı olay kimliğini paylaştığından emin olun ki dönüşümler iki kez sayılmasın.
  • Hazır entegrasyonu tercih edin: sıfırdan kod yazmak yerine CRM'inizin ya da mağaza altyapınızın sunduğu yerleşik bağlantıyı kullanın.

Sonra genişletin: ikinci bir platform ekleyin, çevrimdışı dönüşümleri katın, rıza sinyallerini bağlayın. Amaç mükemmellik değil, tarayıcının tek başına veremeyeceği daha dürüst bir tablodur. Küçük ama doğru kurulmuş bir sistem, hiç hayata geçmemiş kusursuz bir plandan her zaman daha fazlasını ölçer.

Sıkça sorulan sorular

Dönüşüm API'si pikselin yerini alır mı?

Hayır. En iyi sonuç ikisini birlikte çalıştırmaktan gelir: piksel tarayıcı tarafını, CAPI sunucu tarafını yakalar ve ortak olay kimliği sayesinde platform ikisini tek dönüşüm olarak birleştirir.

Sunucu taraflı izleme KVKK'ya aykırı mı?

Kendiliğinden değil. Doğru kurulumda ziyaretçinin rızasına uyulur ve kişisel veriler hash'lenerek gönderilir. Uyum, verinin nereden gönderildiğinden değil, uyguladığınız kurallardan gelir.

Bunun için geliştirici gerekir mi?

Genelde hayır. Çoğu reklam platformu, CRM ve mağaza altyapısı hazır entegrasyonlar sunar; sunucu taraflı etiket yöneticileri de kod yazmadan kurulabilir.

Hash'lenmiş veri ne demek, güvenli mi?

Hash'leme, e-posta ya da telefonu geri döndürülemez bir dizeye çevirir. Platform yalnızca bu dizeyi eşleştirir, ham bilgiyi görmez; bu yüzden eşleştirme gizliliği koruyacak şekilde yapılır.

Dönüşümler bir gecede mi artar?

Anında değil. Kaçırılan olaylar yeniden görünür hâle geldikçe rapor birkaç gün içinde toparlanır; asıl kazanç, zamanla optimizasyonun daha temiz sinyalle keskinleşmesidir.

Sunucu taraflı izleme ve Dönüşüm API'si, çerez sonrası dünyada moda bir terim değil; reklamlarınızın ürettiğini görmeye devam etmenin giderek zorunlu hâle gelen yoludur. Rocketly gibi, gelen kutunuzun, müşteri kayıtlarınızın ve pazarlama merkezinizin tek yerde durduğu bir CRM, bu temiz dönüşüm ve birinci taraf veriyi reklam platformlarına beslemeyi ayrı bir mühendislik projesine değil, zaten kullandığınız sistemin bir parçasına dönüştürür.