Kampanya ve ilçe kırılımında harcama ile başvuruyu gösteren rapor panosu

Birinci taraf ölçüme geçiş ve sunucudan beslenen pazarlama hunisi

Türkiye genelinde onlarca şehirde çalışan bir platformda ölçümü birinci tarafa taşıdım. Veri artık Google'ın ya da Meta'nın tarayıcıda topladığı kadarla sınırlı değildi, başvuru kaydının üstünde ve kendi altyapımızda birikiyordu. Google'ı, Meta'yı ve TikTok'u sunucudan biz beslemeye başladık, üstüne bir pazarlama hunisi kurduk: her başvuru hangi kampanyadan ve hangi ilçeden geldiğiyle kaydedildi, satış ekibinin onayladığı başvuru platformlara nitelikli sinyal olarak geri gitti.

Müşteri
Adı anılmıyor, lojistik platformu
Rol
Pazarlama yöneticisi
Hizmetler
Ölçümleme ve veri altyapısı
Çalışma Takvimi
Aralık 2025 – Şubat 2026
Araçlar
Hardal, BigQuery, Google Tag Manager, Looker Studio
Kanallar
Meta, Google, TikTok

Tek pano

İlçe kırılımında harcama ve başvuru aynı yerde

Sunucu taraflı

Veri tarayıcıda değil kendi altyapımızda

Onaylı başvuru

Algoritma form dolduranı değil müşteriyi öğrendi

Form terki

Hangi alanda bırakıldığı ölçülür hale geldi

Ne devraldım

Ekim 2024'te işe başladığımda ölçüm altyapısı yoktu diyemem, vardı. Analytics kuruluydu, pikseller kuruluydu, eski bir Tag Manager duruyordu. Sorun şuydu: aynı dönüşüm birden fazla yerden sayılıyordu. İlk iki haftam yalnızca neyin neyi saydığını çözmekle geçti, sonra ölçüm kurulumlarının tamamını sıfırdan yaptım.

İki şey giderek daha çok batıyordu

  • İlçe sorusuna cevabım yoktu. Şirketin sorusu hiçbir zaman "Türkiye'den kaç başvuru geldi" olmadı. Soru şuydu: Pendik'ten kaç başvuru geldi ve Pendik için ne kadar harcadık? Reklam panelleri harcamayı bu kırılımda vermiyor.
  • Veri bizim değildi. Ölçüm, üçüncü taraf araçların tarayıcıda topladığı veriye dayanıyordu. iOS kısıtları ve reklam engelleyiciler o veriyi her yıl biraz daha eksiltiyor.

Kararı ben verdim: birinci taraf, sunucu taraflı ölçüm

2025'in sonunda geçiş kararını verdim ve şirket içinde bunun için bastıran taraf bendim. Meta Conversions API ve Google tarafına sinyal sunucudan giderse tarayıcıdaki kayıplar aradan çıkıyor, optimizasyon daha sağlam veriyle çalışıyor. Birinci taraf ölçümde veri de kendi altyapımızda birikiyor.

Kurulan sistem

Birinci taraf izleme için Hardal'ı kurduk. Hardal, veriyi tarayıcıdan değil sunucudan toplayan bir izleme platformu. Sitedeki her olay Hardal üzerinden toplanıp BigQuery'ye düşüyor, ham tablo beş saatte bir işlenip temizleniyordu: bozuk karakterler, aynı kaynağın farklı yazımları ve eksik kampanya alanları düzeltiliyordu. Google ve Meta'nın harcama verisi de kendi arayüzlerinden çekilip aynı tabloya bağlandı.

Sonuç, Looker Studio'da kampanya ve ilçe kırılımında tek bir panoydu: şu kampanyaya şu kadar harcandı, şu kadar başvuru geldi, başvuranların ne kadarı formu yarıda bıraktı. Her ay elle kurduğum tablonun yerini kendi kendine güncellenen bir pano aldı. Form terki de ölçülür hale geldi: formun hangi alanında bırakıldığı ve son doldurulan alanın hangisi olduğu kayda geçiyordu. Tarayıcı tabanlı kurulumda bu veri hiç yoktu.

Altyapı oturduktan sonra çıkan ikinci problem

İşletme başvurusu toplamak için açtığımız kampanyalara, sahada çalışmak isteyen personel adayları başvuruyordu. Formun içine uyarı yazdık, kreatifte koca harflerle işletme dedik, durmadı. Sorun metinde değildi: Meta'nın gördüğü şey olayın tetiklendiğiydi, dolduranın gerçekten işletme olup olmadığı sinyalin içinde yoktu.

Çözüm, sinyalin kendisini değiştirmekti. Meta'ya artık form dolduran herkes gitmiyordu.

Yolda ne bozuldu

Pano bir ara parayı çift saydı. Bir kampanyanın gerçek harcaması ile panodaki rakam arasında üç kat fark vardı. BigQuery'de satır satır iz sürdüm, aynı reklam seti ve aynı gün için birden fazla satır üretildiğini gördüm. Sorunu sorgu çıktılarıyla kanıtlayıp geliştiriciye ilettim, düzeltmeyi yine sorguyla doğruladım. Pazarlamacının SQL bilmesi burada işe yaradı, çünkü kendi panomdaki rakamın nereden geldiğini kendim gösterebildim.

Performance Max dönüşüm şişiriyordu. Google'ın görüntüleme sonrası saydığı dönüşümler, gerçek başvurunun yaklaşık 2,8 katına çıkıyordu. Bunu sunucudan gelen gerçek başvuru sayısıyla kıyaslayarak gördüm. Çözüm yukarıdakiyle aynı oldu: algoritmaya yalnızca onaylanmış başvuruyu beslemek.

Sonuç

  • İlçe kırılımında harcama ve başvuru tek panoda toplandı, rapor elle kurulmuyor.
  • Başvuru ile işe giriş eşleştirildi, hangi kampanyadan gelen adayın işe başladığı haftalık takip edilir hale geldi.
  • Reklam algoritmaları form dolduran için değil, onaylanmış başvuru için optimize oldu.
  • Form terki ölçülür oldu. Formun nerede bırakıldığı görülebildiği için sayfa değişiklikleri tahminle değil veriyle yapıldı.
  • Sistemin taşıdığı hacim: aylık binlerle ifade edilen personel başvurusu ve yüzlerle ifade edilen işletme başvurusu.
  • 2026'nın ilk çeyreğinde pazarlama ekibinin yönetimini devraldım.

Not: neyin ölçüldüğü, neyin ölçülmediği

Başvurunun geldiği ilçe gerçek veridir, kullanıcının kendi kaydından gelir. Başvurunun hangi kampanyadan geldiği de gerçektir, kaynaktan veritabanına taşınır. Reklamın gösterildiği coğrafya ise reklam ağının bildirdiği kadardır, onu ben ölçmüyorum.

Sık Sorulan Sorular

Sunucu taraflı ölçüme geçmek ne kadar sürer?

Kurulumun kendisi birkaç hafta sürüyor. Ama veri akmaya başladıktan sonra bir süre daha takip etmek gerekiyor, ilk günlerde çıkan hataları görüp düzeltmek lazım.

Bu kurulum için geliştirici desteği şart mı?

Site tarafında kod değişikliği gerekiyor, o yüzden bir geliştiriciyle çalışmak gerekiyor. Neyin nereye konacağını ben çıkarıyorum, uygulamayı birlikte yürütüyoruz.

Aynı sistem küçük bir işte de kurulur mu?

Kurulur ama her işte gerekli değil. Ayda birkaç yüz başvuru alan bir işte tarayıcı tabanlı ölçüm de iş görür. Fark, hacim büyüdükçe ve satış birden çok kanaldan geldikçe açılıyor.
Bu yazıyı paylaş
X (Twitter)LinkedInWhatsApp
Yazar

Talha Çaydere

Pazarlama ve marka danışmanı. Markaların konumlanması, stratejisi ve büyümesi üzerine çalışıyor; pazarlamaya tüketici psikolojisi ve sosyoloji penceresinden bakıyor.